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+unsubscr...@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.
