Re: [blink-dev] Intent to Ship: Element Reflection
On Thursday, February 1, 2024 at 6:52:13 AM UTC+11 vmp...@google.com wrote: On Wed, Jan 31, 2024 at 10:10 AM alice wrote: 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. 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. 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. 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.) 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 -- You received this message because you are subscribed to the Google Groups "blink-dev" gr
Re: [blink-dev] Intent to Ship: Element Reflection
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: https://web-platform-tests.org/writing-tests/testdriver.html#accessibility 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: https://github.com/web-platform-tests/wpt/pull/43773 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. Best regards, Philip On Wed, Jan 31, 2024 at 4:10 PM alice wrote: 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. 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 -- 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