search

WICG / aom

Accessibility Object Model
http://wicg.github.io/aom/
Other
569 stars 59 forks source link

RFC: Exporting IDs from shadow roots for cross-root ARIA #204

Closed behowell closed 1 year ago

behowell commented 1 year ago

Note: This is a rewrite of my earlier RFC: Element Handles for Cross-root ARIA, based on discussions with @alice. This proposal is similar, but uses the element's ID as the public name, rather than inventing a new concept like a handle.

Exported IDs are a way to refer to elements inside a shadow tree from an ID reference attribute like aria-labelledby or for, while preserving shadow DOM encapsulation. There is a new attribute exportid to mark an element as having its ID exported from the shadow root, and a new syntax to refer to the element from outside the shadow root: for="host::id(child)". For example, to apply a label to an element inside a shadow tree:

<label for="x-input-1::id(input-2)">Example Label</label>
<x-input id="x-input-1">
  #shadowRoot
  | <input id="input-2" exportid />
</x-input>

There is also a new attribute useids to allow referring to elements outside of the shadow tree. More details are in the RFC.

The full proposal is in this PR, and you can see a formatted version here:

📜 Exporting IDs from shadow roots for cross-root ARIA

I'd really appreciate any feedback and comments! You can leave comments directly on the .md file in this PR.

Special thanks to @alice for the detailed feedback on the previous proposal, which has led to this proposal. Also, thanks to @nolanlawson, @Westbrook, and @EisenbergEffect for feedback on the previous proposal.

behowell commented 1 year ago

Please see the discussion on the previous proposal #200 for more background.

behowell commented 1 year ago

Thank you -- I've merged this draft of the explainer. If anyone has further comments or suggestions, please log an issue or PR. Thanks!

nolanlawson commented 1 year ago

Apologies for not taking a look earlier. I've read through the current spec, and everything looks great to me. Reusing id makes sense, since otherwise id is only meaningful inside of the shadow root, so component authors are free to rename it as they wish. The concepts of "forwarding," "using," and "exporting" also make sense (although forwardids seems most analogous to exportparts, but the names can always be bikeshedded later).

To me, this proposal ticks all the boxes while handling various edge cases (declarative format, no bottleneck effect, can rename IDs pointing in or out), so I'd really love to see browser vendors start to take a stab at it. Amazing work!!

alice commented 1 year ago

although forwardids seems most analogous to exportparts, but the names can always be bikeshedded later

Yeah, it's tricky to name because exportids is much too close to exportid, and reexportids was ... a bit of a mouthful :)

I think if we wanted to name it exportids (and useids to be importids, say), we'd need to come up with a different name for exportid, which is another whole can of worms.