[Popup] aria live, controls/expanded, etc?

[getify]

Is it expected a popup will automatically behave as if it's an aria-live element (in terms of its showing being announced by the SR)? If so, is it polite or assertive? Or will we still have to add that to the markup?

Will it (and its associated anchor) automatically have the controls / expanded duality and toggling behavior that is typical of A11y-aware menus/etc? Or will we still have to manage those bits in code?

Speaking of A11y and SRs, how quickly would we expect SRs to pick up on this new element and treat it well, versus having to shim expected behaviors with all those aforementioned various workarounds? Is advance outreach work with SRs being considered to make sure they are "ready" for this element and that they are interested in supporting it?

[aardrian]

These are not specifically responses to @getify, but my effort to attenuate these good questions based on what I know of SRs and browsers.

Is it expected a popup will automatically behave as if it's an aria-live element (in terms of its showing being announced by the SR)? If so, is it polite or assertive? Or will we still have to add that to the markup?

Wading in to say I hope not. Per the explainer it "can contain arbitrary content". Live regions do not announce the structure that authors will use in that container (headings, lists, etc). That means making it a live region will result in a verbose flat announcement that will still require a user to wade into the container.

Will it (and its associated anchor) automatically have the controls / expanded duality and toggling behavior that is typical of A11y-aware menus/etc? Or will we still have to manage those bits in code?

The explainer shows aria-controls is in place, which is good. The catch is that no screen reader exposes it today (JAWS removed support in its April 2019 release owing to mis-use).

The aria-expanded attribute is generally reserved for disclosure-like controls (which I currently think <popup> more closely resembles) so some evaluation of how browsers will expose that to AT in conjunction with aria-haspopup needs to be done.

Building on this, aria-haspopup is shown in the explainer. Since aria-haspopup requires the role of the container be one of menu, listbox, tree, grid, or dialog, and that role must be the value of aria-haspopup under ARIA 1.1, we likely would not see that until ARIA 1.3 (1.2 is in WD).

Speaking of A11y and SRs, how quickly would we expect SRs to pick up on this new element and treat it well, versus having to shim expected behaviors with all those aforementioned various workarounds? Is advance outreach work with SRs being considered to make sure they are "ready" for this element and that they are interested in supporting it?

For the first question, I believe as long as this proposal leans on existing patterns exposed via ARIA and known to browsers (such as disclosure widgets or dialogs), then the browsers can expose it in their accessibility APIs without impact to screen readers. The proposed built-in behaviors here seem to be the unique aspect and those would fall to browsers to implement. In short, if done carefully, screen readers and other assistive technology may need to do little to nothing.

[melanierichards]

Great questions, thanks!

• We would not treat <popup> as a live region by default, so authors would need to add that if it's appropriate for your specific use case.
• Default semantics equivalent to aria-controls / aria-expanded / aria-haspopup are something we'd like to think through more, especially as we consider (per areas of future exploration) declarative invocation of the popup. The context can have some bearing on the right approach, so just want to make sure we've thought through it fully.
• Agreed that for SR adoption, we'd lean primarily on existing patterns and the onus is on the browser/web platform to communicate those patterns properly to the accessibility APIs that ATs consume. Those mappings would be documented and standardized in the HTML AAM. There may be potential to expose something new, but I would expect those to be enhancements to the user experience rather than required for core functionality.

[aardrian]

Steve Faulkner has done some testing on aria-haspopup: hasPopup hasPoop

In short, current support is spotty. It looks like browsers and screen readers need to build much better support before relying on existing AAPI hooks for aria-haspopup can work.

[melanierichards]

Thanks again all for the discussion here! Working on porting popup issues over to Open UI for incubation, so a quick FYI that we will track the need to define accessibility mappings for popup and its primitives at openui/open-ui#329!