Intent to Ship: Element Reflection

409 views
Skip to first unread message

alice

unread,
Jan 31, 2024, 10:10:09 AMJan 31
to blin...@chromium.org
Contact emails
al...@igalia.com, mere...@chromium.org

Explainer
https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references

Specification
https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
https://w3c.github.io/aria/#ARIAMixin

Summary
This feature allows for ARIA relationship attributes to be reflected in
IDL as element references rather than DOMStrings.

Note: This intent specifically concerns the ARIA attributes using
Element Reflection, i.e. the attributes in the ARIAMixin interface with
a type of Element or FrozenArray<Element>. popoverTargetElement, which
also uses Element Reflection, is already shipping in Blink and WebKit.

Blink component
Blink>DOM

TAG review
https://github.com/w3ctag/design-reviews/issues/134

TAG review status
Issues addressed

Risks

Interoperability and Compatibility

Gecko: Under consideration
https://github.com/mozilla/standards-positions/issues/200
https://bugzilla.mozilla.org/show_bug.cgi?id=1769586

WebKit: Shipped/Shipping
(https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151)
Mentioned in STP release notes:
https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
Was shipped in Safari 16.4 but wasn't mentioned in release notes there.

Web developers: Requested by Web Component authors in particular as a
means to implement ARIA relationships for elements inside of Shadow DOM.

Activation
This feature is not completely polyfillable; ID references across shadow
root boundaries are not possible to implement on top of existing APIs.

WebView application risks
None

Debuggability
Developers can use console.log to access the value for IDL attributes
set via this API, and the Accessibility pane to confirm that the
attributes are correctly reflected in the accessibility tree.

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests?
https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
the reflection part of the API works correctly.
WPT doesn't yet offer a way to test the relevant accessibility tree
mappings.

Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

Tracking bug
https://crbug.com/981423

Measurement
Per-attribute UseCounters:
V8Element_AriaActiveDescendantElement_AttributeGetter
V8Element_AriaActiveDescendantElement_AttributeSetter
V8Element_AriaControlsElements_AttributeGetter
V8Element_AriaControlsElements_AttributeSetter (etc)

V8ElementInternals_AriaActiveDescendantElement_AttributeGetter
V8ElementInternals_AriaActiveDescendantElement_AttributeSetter
V8ElementInternals_AriaControlsElements_AttributeGetter
V8ElementInternals_AriaControlsElements_AttributeSetter (etc)

Estimated milestones
123 or 124

Anticipated spec changes
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6244885579431936

Links to previous Intent discussions
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ

Philip Jägenstedt

unread,
Jan 31, 2024, 12:01:32 PMJan 31
to alice, blin...@chromium.org
Hi Alice,

For testing of these in WPT, do you have some details on what's missing? It's already possible to get the accessible name and role for an element:

I suspect that won't help, but there's an experimental/tentative API being proposed for testdriver.js here:

Would that allow this feature to be tested more fully?

Best regards,
Philip

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/865bf3bd2e6a58da9fc3424ed957ceee%40igalia.com.

Vladimir Levin

unread,
Jan 31, 2024, 2:52:13 PMJan 31
to alice, blin...@chromium.org
I wonder if you had any feedback from framework authors that use VDOM. For context, we were considering using element references for a different feature, and couldn't overcome the fact that when frameworks change DOM, sometimes Nodes and Elements are removed or reused for a different purpose than when initially constructed (ie the element that used to represent the first item in the list is now used to represent the third item in the list).

I realize that this is asking a question very late in the design process, but I'm just curious if that's a case that you considered and if so how you reasoned about it.

Alice Boxhall

unread,
Jan 31, 2024, 5:57:57 PMJan 31
to blink-dev, Philip Jägenstedt, blin...@chromium.org, Alice Boxhall
On Thursday, February 1, 2024 at 4:01:32 AM UTC+11 Philip Jägenstedt wrote:
Hi Alice,

For testing of these in WPT, do you have some details on what's missing? It's already possible to get the accessible name and role for an element:

These attributes affect relationships between elements, which project into the accessibility tree in various ways. `aria-labelledby` does affect the accessible name, so we could write a test for that (which would actually go some way to demonstrating that these attributes affect the accessibility tree in general), but the remaining attributes affect things like accessible description computation (`aria-describedby`), accessibility tree structure (`aria-owns`), which element appears to have focus (`aria-activedescendant`), or how some assistive technology should provide hints to the user (`aria-flowto`, `aria-details`, `aria-owns`, `aria-errormessage`).
 
I suspect that won't help, but there's an experimental/tentative API being proposed for testdriver.js here:

Would that allow this feature to be tested more fully?

That would allow checking how tree structure is affected, so we could test at least one more attribute! I can't tell what other properties will be exposed in the tree, so I'm not sure about the rest.

Alice Boxhall

unread,
Jan 31, 2024, 6:14:43 PMJan 31
to blink-dev, vmp...@google.com, blin...@chromium.org, Alice Boxhall
To be honest, no, we didn't take VDOM into account. 

I'd be curious to hear what specific cases you were running into difficulty with, but it does seem like these paradigms are fundamentally at odds with one another - if elements are unpredictably destroyed and recreated, then it seems like using the string ID-based version is going to be a better fit. This API is, at least, designed to work with using the `setAttribute()` version, in that setting the content attribute will cause any value set via the IDL attribute to be discarded (and vice-versa).

(VDOM has always made me anxious for similar reasons - if elements are unpredictably moved or destroyed, what happens if an assistive technology was visiting those nodes in the accessibility tree when that happens? But I have essentially no experience actually using it, so presumably that can be managed in practice.)

Elsa Vega-Martinez

unread,
Jan 31, 2024, 6:54:34 PMJan 31
to Alice Boxhall, blink-dev, vmp...@google.com
Hello Alice,

I have no clue what you are talking about. This is all  technology and I have no clue of what it is, ma’am, so if you can explain this in plain English, I would appreciate it. 

Just for your information someone is emailing all of you and it is not me. Our you a Technology company are you guys hackers or are you guys helpers because I am absolutely actually I’m scared to see all this technology talk. Are you people tracking me I see there’s a thread and a lot of other things but I do not understand it. I’m sorry, but I do need an explanation because I am going to be turning in my phone to the police department because I am being stuck and I don’t know if it’s you people or somebody else so please if you can be kind and call me, I would appreciate it. 

Thank you,
Elsa




Vladimir Levin

unread,
Jan 31, 2024, 7:16:29 PMJan 31
to Alice Boxhall, blink-dev
The main use case for us was just matching elements automatically across DOM mutations with a caveat that we were using CSS, not attributes. We couldn't really get a sense of how stable our proposals were because of the VDOM type of reordering. It might be worthwhile for us to revisit that plan. I agree with you that I think your case is a lot better, since it affects attributes being set, instead of being some ephemeral state that the browser keeps track of. 
 

(VDOM has always made me anxious for similar reasons - if elements are unpredictably moved or destroyed, what happens if an assistive technology was visiting those nodes in the accessibility tree when that happens? But I have essentially no experience actually using it, so presumably that can be managed in practice.)

I also agree with this sentiment. It seems like we want to rely on the persistence of elements and their identity, but at the same time there are a lot of optimized frameworks that are fast because they don't.

Elsa Vega-Martinez

unread,
Jan 31, 2024, 7:19:11 PMJan 31
to Vladimir Levin, Alice Boxhall, blink-dev
Look I don’t know what you guys are talking about. This is gonna be the last time I’m asking you give me a call right now or I am delivering this to the police department. I’m not playing around anymore I do not know who you people are. I don’t know if you guys are tracking something selling something delivering something you don’t even know who I am ANNA and I somebody is sending you these messages and it’s not me and I’m giving you my phone number area code 559-871-6945. 

Domenic Denicola

unread,
Feb 1, 2024, 12:47:45 AMFeb 1
to alice, blin...@chromium.org
Very exciting to see this!

On Thu, Feb 1, 2024 at 12:10 AM alice <al...@igalia.com> wrote:
These specs are incompatible with each other, because https://github.com/w3c/aria/pull/1876 has not yet been merged. Do you think it'll be possible to get that merged soon?
 


Summary
This feature allows for ARIA relationship attributes to be reflected in
IDL as element references rather than DOMStrings.

Note: This intent specifically concerns the ARIA attributes using
Element Reflection, i.e. the attributes in the ARIAMixin interface with
a type of Element or FrozenArray<Element>. popoverTargetElement, which
also uses Element Reflection, is already shipping in Blink and WebKit.

Can you confirm whether the scope of this intent is element reflection only? Or does it include ElementInternals support as well?

(Coincidentally, I saw you filed this bug which seems to state that the ElementInternals support is currently not working.)
 

Blink component
Blink>DOM

TAG review
https://github.com/w3ctag/design-reviews/issues/134

TAG review status
Issues addressed

This tag review seems to be for AOM in general, as of its 2018 shape. I'm not sure there's been a lot of discussion as to where it ended up, with element reflection. Do you know of any TAG review or comments on the latest API?

However, I think this qualifies for an exception, under "already specified and accepted by the relevant standardization body", and "has already shipped in at least one other browser"
From what I understand, WPT allows some testing of accessibility tree mappings these days, via WebDriver hooks. For example:
IIUC, the above test shows that content attributes (like <div role="region">) are reflected correctly in the accessibility tree. Would it be possible to add similar tests for the corresponding JavaScript code? Maybe that's not possible for most of the complex element relationships that this I2S is about, but I think you should be able to use element reflection to influence accessible name computation, at least? I don't think they need to be exhaustive, but just some tests to catch issues like the above-mentioned bug.


Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

I believe the recent guidance is that all new features should be guarded by a base::Feature flag, which then generates a Finch feature automatically.
 

Requires code in //chrome?
False

Tracking bug
https://crbug.com/981423

Measurement
Per-attribute UseCounters:
V8Element_AriaActiveDescendantElement_AttributeGetter
V8Element_AriaActiveDescendantElement_AttributeSetter
V8Element_AriaControlsElements_AttributeGetter
V8Element_AriaControlsElements_AttributeSetter (etc)

V8ElementInternals_AriaActiveDescendantElement_AttributeGetter
V8ElementInternals_AriaActiveDescendantElement_AttributeSetter
V8ElementInternals_AriaControlsElements_AttributeGetter
V8ElementInternals_AriaControlsElements_AttributeSetter (etc)

Estimated milestones
123 or 124

Anticipated spec changes
None

https://github.com/whatwg/html/pull/8496 contains a consolidated list of spec issues related to this area. The ones that seem relevant to this intent are https://github.com/whatwg/html/issues/8545 and https://github.com/whatwg/html/issues/8544. Can you tell us whether the spec changes that might come out of those issues, could have back-compat concerns?

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6244885579431936

Links to previous Intent discussions
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ

Reply all
Reply to author
Forward
0 new messages