Popups and a11y

[scottaohara]

NOTE: this discussion has moved back to a google doc: https://docs.google.com/document/d/1umackdZ9wZsr0cJtM6IfpFLN0RJKCypdYiRe_nJuk8c/edit#heading=h.7fodzd7pkxs0

Presently there are three values for the popup attribute, representing three types of behaviors.

• auto
• hint
• manual

The differences of each are defined in the popup attribute explainer.

There are a number of open issues for popup in the Open UI GitHub repo.

This discussion thread will allow the ARIA WG a place to comment on topics concerning popup - which may well spill over into related topics such as:

• Clarify usage of aria-haspopup
• Consider mechanism to inform user that a type of role is a 'popup'
• Clarify the use of role=tooltip

[scottaohara]

Hint popups and keyboard / touch navigation

There are still open questions on if hint popups will be opened via hover/focus of a popup trigger. There are a number of things that need to be worked out here due to the popup attribute being proposed as a global attribute.

For instance, how would one access a hint popup if it were invoked via a non-interactive element? This is presently an issue with the title attribute as well.

There have been many discussions around this topic - largely recorded in openui/open-ui#526

Presently hover behavior is likely being punted to version 2 of the popup API. Which gives more time to consider what to do here.

There is still the question of how does one access the hint popup with touch, even when used on interactive elements. Even if there were, say a long press to expose this content, how would users even be aware there was content to expose via this touch method? E.g., it could be programmatically exposed, but what visual cue might there be, if any?

[scottaohara]

Related issues:

• [popup] hint - how to provide keyboard access for non-focusable elements openui/open-ui#530

[aleventhal]

Regarding the visual cue. Technically there isn't one for title now, but it's usually pretty obvious. I guess it's the author's responsibility to make something look like it has some extra info.

[aleventhal]

Moved the discussion back to a Google Doc that contains consensus between Scott and I, as well as TBD items:
https://docs.google.com/document/d/1GM4TnA_6tox1DcTu1PfqeZya7FnI3cPFmwth_K8o_SI/edit#

[scottaohara]

thank you aaron.

[scottaohara]

popup=hint and tooltips

The primary use case for popup=hint was to facilitate the creation of tooltips.

There's a case to be made that if an HTML element has an association to a popup=hint, then this would serve as a signal to browsers that there should be a description/hint association between the invoking element and the hint popup.

Additionally, if the element that has the popup=hint applied to it is a generic element, then there is a case to be made that this should serve as a trigger for a "minimum role" to be exposed. This concept has been discussed before regarding contenteditable and tabindex being applied to generic elements as well. This concept will be relevant to all popup types.

Finally, and related to the ARIA issue: #979 - is providing additional clarity to the tooltip role. What may be most pressing here is that developers/designers often want to put interactive content within tooltips. The ARIA spec does not actually say anything preventing this - though many a11y practitioners assume interactive content within a tooltip is not allowed, paralleling HTML's title attribute tooltip.

[aleventhal]

Regarding minimum role, I'll add a separate discussion for that.

[scottaohara]

Popup anchoring and reading order

One benefit to the popup attribute is that the content it is applied to will be presented in the top layer of the browser, allowing the popup content to escape elements which have an overflow, or conflicting z-index elements.

A way that developers mitigate such issues now is they render popups at the bottom of the DOM, and then position them in the correct visual location using JS and CSS. However, this rarely mitigates the issue that these two elements, which have a strong visual association, are nowhere near each other in the DOM flow. Someone using a screen reader, for instance, may easily find themselves leaving the boundaries of one of these popups, and being located at the bottom of the web page - no where near the trigger that invoked the popup. Or, if focus was not moved to the popup when it was invoked, then if using scan/reading mode, one will likely not find the popup.

Again, the popup attribute will help mitigate this issue so long as developers follow the guidance to ensure that the popup is the element that comes next in the DOM order after the element that invoked it.

But, this does not ensure that all developers will follow this guidance. For instance, if a single popup is used for multiple triggering elements (e.g., a single <div popup=hint> whose content updates depending on the element that invokes it. Or, a number menus with common actions being reused for various invoking button elements. Is there something that could be done here - (thinking aria-owns for an element containing the element that invokes the popup - or maybe/possibly/probablynot squeezing something useful out of aria-flowto? Maybe another way to use aria-controls or aria-details?)

[aleventhal]

A related issue is that keyboard navigation needs to move from the triggering element into the popup, even if they are not next to each other in the DOM.

Regarding reading order, I believe we should reuse aria-details when the popup is not the next item in the DOM. We're already working with AT developers to ensure that there are appropriate announcements and commands to move back and forth when aria-details is used.

I see problems with the other solutions mentioned:

• aria-owns or manipulating AX tree order: a solution based on this will be difficult to implement without creating new rounds of bugs (I have mental scars to prove this)
• aria-controls: this would also be expensive to implement because of all the ATs that would need to update, when they could already leverage aria-details.
• aria-flowto: just 'no' :)

[scottaohara]

Other related concepts to this include the proposed anchor attribute which could allow for a reverse association with a popup element and where it is "anchored" in the DOM.

[aleventhal]

Do we have a link this proposal?

[scottaohara]

referenced in the popup explainer: https://open-ui.org/components/popup.research.explainer#anchoring

[scottaohara]

Manual Popups

The primary popup=manual use case was to allow for "toast" notifications. Unlike other types of popups, there could be multiple popup=manual elements open on the page at a single time.

IMO, this seems like a version of modeless dialogs which are rendered in the top layer, rather than necessarily something that could/should have aria-live announcements associated with it (though such announcements would be necessary if used as a toast/notification... but is that functionality really a part of the popup=manual? Or does it come from populating the popup into a live region area?)

Such popups would benefit from many of the open discussions / requests to allow for modeless dialogs to be easily accessed via special keyboard commands. (e.g., ctrl + f6)

[aleventhal]

IMO we should at least announce their presence by default (and ATs should probably provide instructions for navigating to them). To make sure they are announced, we can use either via aria-live equivalence or via alert events/semantics. We will need to expose another platform API property on them to indicate that they are a popup so that ATs can determine what instructions to provide (E.g. an ispopup object attribute in IA2/ATK). The user might hear something like "Popup opened, A service agent would like to chat with you, press F6 to navigate to this popup".

We would need to decide if it's necessary or advisable to allow authors to turn off the automatic announcements.

[scottaohara]

a counter point to that is that <div popup=manual> could be used to take items that are generally put in arbitrary places in the dom, or at the bottom of the DOM for z-index positioning purposes, and instead include them in locations that are more easily discoverable for people using keyboard/AT.

take the feedback and chat persistent controls on https://www.homedepot.com/ (i'd say try to navigate to them with keyboard, but the website has focus traps and they're located at the very bottom of the DOM - so don't frustrate yourself :))

Those controls could instead be placed inside of a <div popup=manual> and they could be then be place in the DOM - for instance - after "help" in the primary navigation, or at least somewhere in the global header of the site. There wouldn't be a need for any sort of live region announcement here, and it'd get pretty old to hear that live chat and feedback are available on every page of the website.

Similarly, another generic use case for popup=manual would be other sticky/float-y badges like this recaptcha info widget:

I'm in favor of AT being aware that there are popups on a page, and even allowing users to be informed that there are popups that could be navigated to - depending on if the user wants to hear this or not. But I maintain my concerns about this having any sort of default live region behavior.

[aleventhal]

Maybe they should be treated as live regions when a user action is what caused them to be shown?
The browser has this information.

So if the popup is show from loading the page, or a timer, it wouldn't be treated like a live region.
If the popup is shown because the user clicks on something or presses a key.
It's a heuristic but the author can override the behavior. Just an idea.

[scottaohara]

Attributes for button elements

There are a number of additional attributes that will accompany popup

popuptoggletarget, popupshowtarget and popuphidetarget.

These attributes are to be supported on elements that expose a button role - e.g., input type=button, <button> and the like.

The popuptoggletarget attribute should probably make a button be exposed as if it had an aria-expanded=true|false set to it, to match the current state of the popup.

I'm not convinced popupshowtarget or popuphidetarget would need to expose the expanded states, as it is not expected for a "close" button to be announced as "expanded", for example. That is, so long as focus is automatically moved to the popup when popupshowtarget is used - as the change in focus would be sufficient to indicate the expanded state, and any change in state to the invoking element wouldn't be noticed by AT since focus moved from it.

[aleventhal]

I'll counter — I think we want the aria-expanded on the button.

I'm not convinced popupshowtarget or popuphidetarget would need to expose the expanded states, as it is not expected for a "close" button to be announced as "expanded", for example.

Can you provide the markup you're imagining here? Is this where a close button would close its ancestor popup by using popuphidetarget?

That is, so long as focus is automatically moved to the popup when popupshowtarget is used - as the change in focus would be sufficient to indicate the expanded state, and any change in state to the invoking element wouldn't be noticed by AT since focus moved from it.

The user may leave the popup and explore in the virtual buffer. Having the aria-expanded state definitely won't hurt.

[scottaohara]

Fair point about popupshowtarget being accessed by someone leaving the popup using scan mode, and furthermore I retract my position on this exposing the expanded state here would also align with other discussions about the redundancy aria-expanded and aria-haspopup have, and where aria-expanded state allows someone to know that something will appear when interacting with the control - and then when the element is invoked, the element can inform the user it is a popup.

Re: markup example

<button popupshowtarget=d>Edit</button>

<dialog id=d popup>
  <h2>Edit whatever</h2> <button popuphidetarget=d>Close</button>
  <!-- edit-y things -->
</dialog>

generally would not expect a close button to announce it is in the expanded state... someone is already inside the popup. they know it's expanded.

[aleventhal]

That dialog example -- I didn't even know it was possible.
I would say that:

• If there is no popupshowtarget on the element, then aria-expanded should not be exposed for it.
• Another rule that would also work here would be that aria-expanded isn't used when the target to show/hide is an ancestor

[scottaohara]

Focus behavior for different popups

There is an open question about how focus should be handled when invoking the different popup types, and depending on the attribute used on the invoking button element.

Re: attributes for button elements popuptoggletarget and popupshowtarget can each be used to invoke a popup.

Depending on the type of popup that is invoked, focus may make sense to stay on the invoking element, or it may make sense to move to the rendered popup.

E.g., a <button role=combobox ...> may well use aria-activedescendant to indicate which element in the invoked popup is "focused" rather than necessitating focus move to the content s of the popup. So in this case, it would make sense for focus to remain on the button and that the popuptoggletarget is likely the attribute to use there.

But, a button that invokes a modeless dialog popup likely should use the popupshowtarget attribute and focus SHOULD move to the first focusable element of this popup.

defaultopen

What should happen with focus is a popup has the defaultopen attribute specified? It is not allowed on a popup=hint, and the primary use case would be for a popup=manual... but does that mean focus should move to it by default? Probably not.... especially because there can be multiple popup=manual elements that could be open by default.

[aleventhal]

Depending on the type of popup that is invoked, focus may make sense to stay on the invoking element, or it may make sense to move to the rendered popup.

E.g., a <button role=combobox ...> may well use aria-activedescendant to indicate which element in the invoked popup is "focused" rather than necessitating focus move to the content of the popup. So in this case, it would make sense for focus to remain on the button and that the popuptoggletarget is likely the attribute to use there.

In line with "make simple things easy, and make difficult things possible", and the fact that there is new cleaner markup for this use case, I think we should make the author keep focus on the trigger to do this. IMO it's almost the right thing to do to move focus into the popup if it has a focusable child. Another signal is whether the user pressed a key to trigger it.

Also, in the activedescendant case the items in the popup aren't necessarily keyboard focusable. When there's nothing keyboard focusable inside the popup, we could keep focus where it was.

So, four potential signals that we need to evaluate:

• Was a key pressed to open it?
• Was it opened with popuptoggletarget vs. popupshowtarget?
• Is there a keyboard focusable descendant inside the popup ?
• Is there an element with autofocus inside the popup?
• Did the author do something to turn this feature off? E.g. something like cancelling an event or maybe we would need to add an attribute like autofocusoff :/

But, a button that invokes a modeless dialog popup likely should use the popupshowtarget attribute and focus SHOULD move to the first focusable element of this popup.

defaultopen

What should happen with focus is a popup has the defaultopen attribute specified?

I only think focus should move automatically for popup=auto

[scottaohara]

Good points here.

I only think focus should move automatically for popup=auto

I can get behind that so long as there's an easy way for authors to prevent auto-focusing when necessary. Even if this was a JS-only mechanism, since for as much as these features are to negate the amount of JS people need to write, people should not expect to never have to write JS if they need to build custom things.

[aleventhal]

There needs to be some role to keep the popup from bleeding into the rest of the page. This is a problem across all popup types, e.g. <table popup=xyz> does not need a role change, but <div popup=xyz does>.

These are possibilities for the minimum role:

• popup=hint -> role=tooltip
• popup=auto -> role=group
• popup=manual -> role=group (we could consider alert/alertdialog but then I think this might cause the popup to not be announced if a different role was selected).

[scottaohara]

i agree with the concept of a minimum role - it's a concept that is important beyond just popup and it would help at least alleviate some troubles with global attributes important for accessibility that already exist that can be used on generic elements.