Should this Intent be considered as including ariaOwnsElements <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/aria_relationship_attributes.idl;l=17;drc=3746ad65cf4dcd5217ed68c6a72aa6bf0f05ea0b>? That was split off into a separate flag from the other properties here <https://chromium-review.googlesource.com/c/chromium/src/+/5752663> and it doesn't look like https://github.com/w3c/aria/issues/2266 has come to any definite conclusion yet.
I think the other properties are in a good state and I'm excited to see them ship. It would be great to clarify what the plan is for ariaOwnsElements as it's not yet clear to me that that one is ready. -- Dan Clark On Tuesday, February 4, 2025 at 3:10:04 AM UTC-8 Daniel Bratell wrote: > LGTM1 > > /Daniel > On 2025-02-04 06:40, Alice Boxhall wrote: > > After many delays, I think this is finally ready for another look. > > On Thursday, February 1, 2024 at 4:47:45 PM UTC+11 dom...@chromium.org > wrote: > > Very exciting to see this! > > On Thu, Feb 1, 2024 at 12:10 AM alice <al...@igalia.com> 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 > > > 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? > > > This has now been merged. > > > > > 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 > <https://bugs.chromium.org/p/chromium/issues/detail?id=1518693> which > seems to state that the ElementInternals support is currently not working.) > > > I had originally intended this to be only element reflection, but the > AriaMixin properties on ElementInternals are now mapped through to > accessibility APIs as well, so I think they should be in scope. > > > > 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? > > > I don’t know of any further TAG review specific to this API. > > > > However, I think this qualifies for an exception > <https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/>, > under "already specified and accepted by the relevant standardization > body", and "has already shipped in at least one other browser" > > > Phew! > > > > > > 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. > > > From what I understand, WPT allows some testing of accessibility tree > mappings these days, via WebDriver hooks. For example: > > - These tests appear to test the computed role > <https://github.com/web-platform-tests/wpt/tree/master/wai-aria/role> > - These tests appear to test the computed accessible name > <https://github.com/web-platform-tests/wpt/tree/master/accname> > > 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 > <https://bugs.chromium.org/p/chromium/issues/detail?id=1518693>. > > > 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. > > > There is now a feature flag, “EnableAriaElementReflection”. > > > > > > 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? > > > I think https://github.com/whatwg/html/issues/8545 has more or less been > overtaken by events, given this API has been shipping in WebKit for some > time. Given the only viable solution proposed was to change the API to use > ObservableArray, this would obviously be a breaking change to a shipping > API at this point. > > I believe the WebKit implementation adopts Anne's proposal in > https://github.com/whatwg/html/issues/8544 that elements referred to from > ElementInternals don't need to be subject to the same Shadow DOM validation > rules. > > > > 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 > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/865bf3bd2e6a58da9fc3424ed957ceee%40igalia.com > . > > -- > 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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdb2a75c-5e7c-4475-b0a9-39870757ec62n%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdb2a75c-5e7c-4475-b0a9-39870757ec62n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3a1e3c7f-9bbf-4d35-8184-60d4b6bb4606n%40chromium.org.
