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+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
<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/a042fd76-2800-43aa-80f1-c32d6b9d2954%40gmail.com.
