Reflecting IDREF/IDREF list ARIA attributes to element references

[alice]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Reflecting IDREF/IDREF list ARIA attributes to element references
• Specification or proposal URL:
  • https://whatpr.org/html/3917/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
  • https://w3c.github.io/aria/#AriaAttributes
  • https://github.com/WICG/aom/blob/gh-pages/explainer.md#reflecting-element-references
• Mozillians who can provide input (optional): Anne van Kesteren; Jamie Teh

Other information

This will allow ARIA relationship attributes to be set more easily via JavaScript, and in particular will allow setting ARIA relationship attributes which work across Shadow DOM boundaries (with limitations).

el.ariaDescribedByElements = [labelElement1, labelElement2];
el.ariaActiveDescendantElement = ownedElement1;

This is currently being implemented in Blink.

We are planning to ship this alongside Default Accessibility Semantics for Custom Elements.

[dbaron]

cc @annevk @jcsteh.

[annevk]

In general we've been supportive of this as similar to #201 it helps with accessibility of web components, but it's not entirely clear what the design should be around tree mutation. Alice filed whatwg/html#4925 to track that.

[alice]

Greetings from 2024. This is now shipping in Safari, and I'm planning to propose shipping it in Blink. The spec text has been stabilised and merged: https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element

I realise this is still under discussion at Mozilla, but would it be possible to get an update here about the state of those discussions?

Thanks!

[jcsteh]

Overall, we're supportive of this.

As we've discussed, @alice, I still think it's unfortunate that we're going to need two (hopefully not more) very different concepts to express ARIA relationships across shadow DOM boundaries. That complicates things across the board; browser implementations, authors understanding which to choose when, etc. There's also no way we can do element reflection (currently the proposed solution for referring out of a shadow root from inside of it) declaratively, and declarative seems to be a priority for some.

That said, I'm mindful of the need to (finally) make progress on a solution to a significant gap confronting authors right now. We haven't managed to come up with a single concept that solves all the things, and even if we did, it'd probably be super complex and unwieldy, which is perhaps just as much of a problem. Also, we need this for ElementInternals, plus PopoverTargetElement is already implemented across three browser engines which provides the groundwork for element reflection. So, despite my reservations, I think doing this is the most pragmatic path.

Thanks @alice for taking the time to discuss this with me in December. That helped me greatly in beginning to figure out a path forward here.

[martinthomson]

@jcsteh do you think that you could draft a position for us and suggest a choice of position? I can't really work out whether you might prefer positive or neutral in this case, though with your reservations, I'm guessing that neutral is safer.