[TPAC Prep] Cross Root Aria

[Westbrook]

This problem space is expertly described by Alice Boxhall in this blog post.

There are a number of open proposals in this area as of today:

• Import/Export IDs: Content attribute to import/export IDs across shadow boundaries WICG/aom#169
• Cross Root Delegation and Reflection: https://github.com/leobalter/cross-root-aria-delegation
• Semantic Delegates: https://github.com/alice/aom/blob/gh-pages/semantic-delegate.md
• Encapsulation preserving IDL references: Encapsulation-preserving IDL Element reference attributes  WICG/aom#195
• Element Handles: RFC: Element Handles for Cross-root ARIA WICG/aom#200
• and more, many striking nuanced grounds in between and around the above proposals

Borrowing from Ben Howell's Element Handle RFC, the complexity of the problem that we're trying to solve looks a bit like this:

<x-label id="x-label">
  #shadowRoot
  | <label for="">Example Label</label>
</x-label>
<x-combobox id="x-combobox-1">
  #shadowRoot
  | <x-input>
  |   #shadowRoot
  |   | <input
  |   |   role="combobox"
  |   |   aria-expanded="true"
  |   | />
  | </x-input>
  | <button aria-label="Open" aria-expanded="true">v</button>
  |
  | <x-listbox id="x-listbox-1">
  |   #shadowRoot
  |   | <div role="listbox">
  |   |   <div role="option">Option 1</div>
  |   |   <div role="option">Option 2</div>
  |   |   <div role="option">Option 3</div>
  |   | </div>
  | </x-listbox>
</x-combobox>

How do you associate all of the elements within the above example accessibly in the presence of shadow DOM boundaries?

The majority of the proposals above are restricted by the "bottleneck effect":

The main limitation of these APIs is that they can only allow expressing relationships to one element or set of elements for each attribute in each direction. Effectively, it makes the shadow root a bottleneck for these types of relationships.
-Alice Boxhall

When there are multiple associations of a type outside or inside of the shadow boundary to be made, completing the accessibility contract defeats many of the most clever proposals. Currently, the Element Handles proposal seems to be the only proposal with an active supporter that overcomes this situation. I can't speak for Ben specifically borrowing from the Import/Export IDs proposal or not, but it would be disrespectful not to point out some of the similarities in the proposals, and the ability of Import/Export IDs to also address the bottleneck effect. However, it is currently unclear to active participants in the conversation why/how it was originally dropped as a proposal and without an active owner of the proposal is not currently being reviewed as a viable alternative.

With the capabilities unlocked by the Element Handles API, the above DOM would become fully accessible via the following edits:

<x-label id="x-label" importhandles="label-for: x-combobox-1::handle(the-input)">
  #shadowRoot
  | <label for=":host::handle(label-for)">Example Label</label>
</x-label>
<x-combobox id="x-combobox-1">
  #shadowRoot
  | <x-input 
  |   exporthandles="the-input"
  |   importhandles="my-activedescendant: x-listbox-1::handle(active), my-listbox: x-listbox-1::handle(the-listbox)">
  |   #shadowRoot
  |   | <input
  |   |   role="combobox"
  |   |   handle="the-input"
  |   |   aria-controls=":host::handle(my-listbox)"
  |   |   aria-activedescendant=":host::handle(my-activedescendant)"
  |   |   aria-expanded="true"
  |   | />
  | </x-input>
  | <button aria-label="Open" aria-expanded="true">v</button>
  |
  | <x-listbox id="x-listbox-1">
  |   #shadowRoot
  |   | <div role="listbox" handle="the-listbox">
  |   |   <div role="option" handle="opt1 active">Option 1</div>
  |   |   <div role="option" handle="opt2">Option 2</div>
  |   |   <div role="option" handle="opt3">Option 3</div>
  |   | </div>
  | </x-listbox>
</x-combobox>

There are active questions about the naming and verbosity of this proposal that could be actively addressed by broader web developer participation in the discussion. This could also be visited more productively in light of a prototype, either behind a flag or via a polyfill of sorts. The pursuit of this path was a takeaway from a recent AOM Working Group meeting.

Sometimes the bottleneck is the right thing...

While the bottleneck effect can negatively effect complex contexts like the above example, it may be that a proposal that is specifically bound by this reality would be beneficial in parallel with something like the above. Take the following example:

<div role="radiogroup">
  <x-button>
    #shadowRoot
    | <button role="radio"></button>
  </x-button>
  <x-button>
    #shadowRoot
    | <button role="radio"></button>
  </x-button>
  <x-button>
    #shadowRoot
    | <button role="radio"></button>
  </x-button>
</div>

In this example, the <x-button> element is wrapping a native <button> element for lack of a more clear path by which to achieve the native functionality of this element (see Customized Built-ins and Alternatives for more information here). These "button" elements are gathered in a <div> that holds the radiogroup role. To appropriately fulfill the accessibility contract of the role, the "radio items" within this group need to be direct children of the container. How is this relationship to be achieved while still encapsulating custom functionality, styling, and DOM content in the child elements?

To date, web developers would need to hoist all of the functionality of the <button> element into the <x-button> themselves; pointer, keyboard, focus, etc. etc. all manually.

Would an API like Semantic Delegates allow for not only the accessibility data applied to the <x-button> to be passed to the <button> in its shadow root, but ALSO allow for the child association that the role="radiogroup" element is attempting to make with its direct child (the <x-button> element) be completed? In this way the <x-button> would effectively be the <button> without the disconnect from the parent context that occurs when the shadow boundary is applied.

Then we could complete the accessibility contract in the above example via the following code (wavey hands for actual final APIs):

<div role="radiogroup">
  <x-button role="radio">
    #shadowRoot shadowrootsemanticdelegate="button"
    | <button id="button"></button>
  </x-button>
  <x-button role="radio">
    #shadowRoot shadowrootsemanticdelegate="button"
    | <button role="radio" id="button"></button>
  </x-button>
  <x-button>
    #shadowRoot shadowrootsemanticdelegate="button"
    | <button id="button"></button>
  </x-button>
</div>

Next steps

The various proposals sit awaiting critical mass. Various approaches have gained excitement from individual implementors that may be leading to in-browser prototypes. However, the biggest signal that would benefit the process at this point to excitement gathering in the web developer community around specific proposals.

Let's answer the questions:

• What would you like to see in making the various options listed herein more applicable to the application that you are developing?
• Could you see using one of the APIs over others for the situations you work in?
• Are there specific issues you face as a developer that are not yet addressed by the available proposals?

[nolanlawson]

the "radio items" within this group need to be direct children of the container

I've only experimented with "polyfilling" cross-root ARIA, but I had assumed that putting CSS display: contents on the host could be used to solve this. On NVDA and VoiceOver at least (last I checked), this solves the problem of a listbox with options that should be direct children. However, looking at MDN, apparently this behavior of display: contents is a browser bug per the CSS spec, so maybe it's not great to rely on.

In general, though, isn't this a problem with ARIA/AOM more generally and not specific to shadow roots? You could have the same problem if you wanted to (for whatever reason) wrap your options/radios in <div>s.

Are there specific issues you face as a developer that are not yet addressed by the available proposals?

Besides seeing browser vendors commit to a specific spec (either Ben's or Alice's, or ideally both since they're somewhat orthogonal), I'd also like to see the browser vendors make progress on ARIAMixin, in particular:

• String reflection (e.g. ariaLabel, role), which is currently implemented in Chromium and Webkit but not Firefox.
• Element reflection (e.g. ariaLabelledByElements, ariaActiveDescendantElement), which is currently implemented in WebKit but still behind a flag in Chromium and not Firefox.

To me, ARIAMixin is kind of "table stakes" for cross-root ARIA. It solves at least some problems with ARIA references crossing shadow boundaries (for references pointing to shadow-including ancestors, at least), and it could be used as a foundation to build a decent polyfill for cross-root ARIA.

[Westbrook]

You could have the same problem if you wanted to (for whatever reason) wrap your options/radios in

s.

You definitely have the same issue here, but a DOM structure isn't forced on you in that case. If you choose to use a

and it doesn't work, your bad. If you use a web platform primitive (shadow DOM) and it doesn't work, the web platform's bad. Right?

While I think there is a lot of room for the platform to better understand itself and connect DOM nodes in an ancestry rather than in a nuclear family in accessible and functional manners, even if we were able to get that added to the platform, I cannot see the same API being applicable cross shadow boundaries. Maybe I'm shortsighted?

Great call on the reflection work. I'll find a spot for that, either here or in the report as it is coming together!