On 2025-02-07 10:58, Chris Harrelson wrote: > Hi Alice, > > Could you update the chromestatus entry [8]'s overview to explicitly > list out all of the changes to web API IDLs, and any other details > needed to understand what is proposed for shipping? I'm getting a bit > confused about the status.
Definitely happy to update Chromestatus, but I'm a little lost as to where in that entry these specifics should go. I can answer your question (and Dan's) here, hopefully, in the meantime: What is in scope are the ARIAMixin attributes (https://w3c.github.io/aria/#ARIAMixin) with a type of `Element?` or `FrozenArray<Element>?`, other than `ariaOwnsElements`, on both `Element` and `ElementInternals`. The relevant code for the IDL changes is all in third_party/blink/renderer/core/dom/aria_relationship_attributes.idl, which I can also paste below (other than the comment-only lines): [ RuntimeEnabled=AOMAriaRelationshipProperties ] interface mixin AriaRelationshipAttributes { [CEReactions, Reflect=aria_activedescendant, Measure] attribute Element? ariaActiveDescendantElement; [CEReactions, Measure] attribute FrozenArray<Element>? ariaControlsElements; [CEReactions, Measure] attribute FrozenArray<Element>? ariaDescribedByElements; [CEReactions, Measure] attribute FrozenArray<Element>? ariaDetailsElements; [CEReactions, Measure] attribute FrozenArray<Element>? ariaErrorMessageElements; [CEReactions, Measure] attribute FrozenArray<Element>? ariaFlowToElements; [CEReactions, Measure] attribute FrozenArray<Element>? ariaLabelledByElements; [CEReactions, Measure, RuntimeEnabled=AOMAriaRelationshipPropertiesAriaOwns] attribute FrozenArray<Element>? ariaOwnsElements; }; Element includes AriaRelationshipAttributes; ElementInternals includes AriaRelationshipAttributes; > On Wed, Feb 5, 2025 at 7:03 PM 'Dan Clark' via blink-dev > <blink-dev@chromium.org> wrote: > >> Should this Intent be considered as including ariaOwnsElements [1]? >> That was split off into a separate flag from the other properties >> here [2] 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. To your question specifically: yes, I forgot to mention ariaOwnsElements earlier so I appreciate the prompt! `ariaOwnsElements` does indeed need more work, specifically around testing exhaustively enough that we can be sure we haven't inadvertently introduced any new potential crash conditions. I put `ariaOwnsElements` behind a separate flag after this discussion with Aaron: https://issues.chromium.org/issues/41469336#comment25 >> On Thursday, February 1, 2024 at 4:47:45 PM UTC+11 >> dom...@chromium.org wrote: >> 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 [5] >> * These tests appear to test the computed accessible name [6] >> >> 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 [3]. I forgot to answer this in my earlier email too, but I did add more WPT tests covering the computed accessible name: https://github.com/web-platform-tests/wpt/tree/master/html/dom/aria-element-reflection-labelledby.html and https://github.com/web-platform-tests/wpt/blob/master/custom-elements/element-internals-aria-element-reflection.html#L110 Thanks, Alice -- 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/6f2caad673997591fb8a53b28314a535%40igalia.com.
