[Popup] Define accessibility mappings for popup and its primitives

[melanierichards]

Typically, when new primitives/elements are added to the platform, stakeholders of web plat accessibility will work with the editors of the HTML AAM to define accessibility mappings. This step should come a little later in the process when the design of said primitives is more formalized. Tracking this need here, as there has been express author interest in this.

In scope for this new mapping definition, currently:

• popup element
• popup attribute
• anchor attribute
• delegatesfocus attribute
• Possibly something like an initiallyopen attribute (refer to [Popup] Do we need the "open" content attribute? #311)

[mfreed7]

See many good/related comments on MicrosoftEdge/MSEdgeExplainers#434

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[mfreed7]

So the explainer currently says this about accessibility mappings:

When the triggerpopup attribute is applied to an activating element, the UA may automatically map this attribute to an appropriate aria-* attribute, such as aria-haspopup, aria-describedby or aria-expanded. There will need to be further discussion with the ARIA working group to determine the exact ARIA semantics, if any, are necessary.

When this issue was opened, we were considering a new element, <popup>, and we've now switched to "just" a content attribute, <div popup=popup>. As such, the explainer doesn't say much about accessibility mappings for the popup itself, because those mappings come from the element wearing the popup attribute.

Can we a) confirm that the above paragraph is still completely correct, and b) talk in more detail about the correct behavior in the presence of the togglepopup, showpopup, and hidepopup "triggering" attributes? Very naively, it would seem that we should cause the triggering element (e.g. a <button>) to sprout aria-haspopup=true when one of the above three triggering attributes points to a valid popup element, if aria-haspopup isn't already present on the <button>. Is that correct? Is there more to do? @scottaohara

[scottaohara]

a) yes, the element that has the popup attribute will be the element to convey the necessary role, and since popup is no longer an element, if someone needed to create a custom component (e.g., with a div or custom-element) then an ARIA role could be assigned as necessary.

if there are any other accessibility semantics that the popup attribute itself would communicate, w3c/aria#1697 is the issue I opened with ARIA to define those. I have thoughts, if you need something sooner than later.

Regarding the trigger element, this is where the type of popup will be important. Because a default popup may need aria-haspopup or aria-expanded (there is discussion going on in ARIA concerning the actual usefulness of the aria-haspopup attribute and a bunch of baggage associated with it that I won't bore you with right now.

If a popup=hint then it would be assumed that an aria-describedby association would be created with the tooltip popup - no need for an aria-expanded or aria-haspopup.

If it's an async popup, e.g., a toast notification popup - then we likely wouldn't want any mapping for the attribute as the live region announcement (or ideally exposed via a notification api - w3c/aria#832) of the popup's contents would be the audio cue of the popup... popping up.

Please let me know if you have more questions / feel free to reach out and we can discuss these further if need be, especially if you are blocked on anything.

[mfreed7]

a) yes, the element that has the popup attribute will be the element to convey the necessary role, and since popup is no longer an element, if someone needed to create a custom component (e.g., with a div or custom-element) then an ARIA role could be assigned as necessary.

if there are any other accessibility semantics that the popup attribute itself would communicate, w3c/aria#1697 is the issue I opened with ARIA to define those. I have thoughts, if you need something sooner than later.

Ok great, thanks for confirming. If there are conclusions that come out of w3c/aria#1697 for the popup itself, definitely @mention me so I can implement them.

Regarding the trigger element, this is where the type of popup will be important. Because a default popup may need aria-haspopup or aria-expanded (there is discussion going on in ARIA concerning the actual usefulness of the aria-haspopup attribute and a bunch of baggage associated with it that I won't bore you with right now.

If a popup=hint then it would be assumed that an aria-describedby association would be created with the tooltip popup - no need for an aria-expanded or aria-haspopup.

If it's an async popup, e.g., a toast notification popup - then we likely wouldn't want any mapping for the attribute as the live region announcement (or ideally exposed via a notification api - w3c/aria#832) of the popup's contents would be the audio cue of the popup... popping up.

Ok, to be sure I understood this correctly, for the trigger element:

• Let's call the element (likely a popup) pointed to by the triggering attribute (e.g. togglepopup) the "target".
• If the target isn't a valid popup, do nothing.
• If the target has popup=popup, then set aria-haspopup=true on the trigger element. Also set aria-expanded to true if/when the target popup is showing, and false when it is hidden.
• If the target has popup=hint, then set aria-describedby to the target.
• If the target has popup=async, then do nothing.
• In all of the above cases, when I say "set aria-*", I mean in the accessibility tree only. I do not mean the element should sprout content attributes.

Any mistakes there?

[scottaohara]

re bullet 3 i would actually say at this point aria-expanded=false when the popup is not shown, and aria-expanded=true when it is. I really don't know at this point whether ARIA will be using aria-haspopup going forward or deprecating that attribute. i'll re-sync with a few people on that, but in the meantime the conversation was going towards using aria-expanded instead. but there are some bugs with aria-haspopup when used on a button... it always makes the button expose as a 'menu button' with a 'menu popup' - regardless of the haspopup value... so hence my caginess on you actually implementing that feature at this time.

it's safe for something like a combobox with listbox popup, but just rubbish for buttons at this point. :(

[scottaohara]

another thought that came to mind concerning the hint popup is how presently a title attribute can provide certain elements its accessible name if other preferred methods of naming are not provided.

e.g., <button title=foo></button> would produce the title tooltip, and the name of the button would be 'foo'.

A hint popup should probably also contribute to the name of the element if the element is otherwise not named.

[scottaohara]

some additional accessibility related todos:

1. When a generic element is specified to be a popup, we would remap that element to be exposed as the following (to be defined in HTML-AAM):
   • If popup=hint, map to role=tooltip
   • Otherwise, map to role=group
   • TODO: do async popups need special consideration?
2. For use cases where authors may use a hint popup as a way to expose the label for a link (e.g., a link visually represented by an icon alone), we would also want to ensure that the hint popup could participate in the accName calculation for such elements exactly the way the title attribute would (the title is used as the name when there is no other naming markup, otherwise it is used as a description).
3. Nice to have (not a blocker, to be discussed): a hint for users when an element will auto dismiss from tabbing out of it (aka light dismiss) when potentially unexpected. For example, a <dialog> can get this behavior using popup=popup. It may be helpful to provide additional information to the AT indicating that light dismiss behavior is present, so that the AT can optionally provide that as a hint, possibly by changing the announcement from "dialog" to "dialog popup" in this case. Other examples could be "article popup" or "note popup". Can be decided in the related ARIA issue Consider mechanism to inform user that a type of role is a 'popup' w3c/aria#1697, although HTML-AAM would also need to be updated.

cc @aleventhal @mfreed7

edit: co-authored by @aleventhal

[scottaohara]

Additional items that came out of meeting with @aleventhal @mfreed7 today regarding popup=async:

• general use case for popup=async has revolved around needing this for toasts. Are there other legitimate use cases for this?
• if a popup=async is used on an element with an implicit role of generic, then its role should be modified to that of a modeless dialog.
• popup=async elements should be accessible/included in the listing of items that F6 key should cycle through. Other popups would not need to be in the F6 order.
• if an element with popup=async has a subtree with no accessible content (e.g., the popup is used as a visual effect, or has no other accessible content at all (empty), then consider treating it as a role=none. It probably should not be in the F6 order if it is exposed as presentational, i.e., ignored by the a11y tree.

[aleventhal]

"No accessible content" — would need a definition.
We might want to treat it as aria-hidden="true" as opposed to role="none".

[aleventhal]

More thoughts on a11y semantics for async popups:

• Consider putting in landmark cycle, along with non-modal dialogs (there's an ongoing discussion about this)
• Consider using role=alertdialog rather than role=dialog.
• Consider automatically adding aria-live="polite" and letting author override. Potentially helpful, but also potentially too verbose at times.
• Consider a mechanism to expose that it is a popup, since the role could be anything (perhaps object attribute ispopup:true for platforms that support object attributes).
• Consider firing dialog start event (exists only in MSAA)

F6 for navigation will be helpful. Another thing to consider is whether the Escape key can close it, as it could in a non-modal dialog. It doesn't seem like that's a possibility here, since we don't know if the author wants the user to be allowed to close it.

[scottaohara]

Another thing to consider is whether the Escape key can close it, as it could in a non-modal dialog. It doesn't seem like that's a possibility here, since we don't know if the author wants the user to be allowed to close it.

this seems like a reasonable feature so long as the popup can receive focus / contains an element that can receive focus. i'm not sure if this is something that authors would always want, but so long as there is a way to override that would seem fine to me? also, maybe makes sense to have this rule apply to popup=hint as well, since, if that can have a focusable element it too should be able to be dismissed via esc.

Regarding making popup=async have live region semantics by default... whether that be alertdialog or aria-live=polite - agreed... i'm concerned with the amount of chatter this would cause, as well as the potential of individual popups that fire at the same time overwriting each other, or them just not announcing at all per present AT issues with live regions that get injected into web pages. there could be multiple popup=async on page load, which could also be overwhelming if they were all announced at once. definitely lots to think about here still

[mfreed7]

Ok, per the resolution on 495 today, all of this great a11y discussion needs to be moved to the ARIA working group, to determine how to handle the popup attribute correctly.

As such, I'd like to close this issue. So as to avoid losing the context from this discussion, please link back to this issue from the ARIA issue, once it's been opened. Thanks!