You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Core-AAM guidelines on constructing the accessibility tree should be written to clarify that they operate on the "flattened tree" (a term which seems to be no longer defined in the WHATWG DOM standard, but meaning the hierarchy of elements that are used as the input to rendering, regardless of their official DOM parent-child relationships).
A more complicated issue is how to handle IDREFs in ARIA attributes. IDs are not unique across shadow trees, and you can't easily query shadow tree IDs from the main document.
The SVG-AAM currently contains the following guidelines about ARIA IDREFs in the context of SVG use shadow trees:
SVG user agents MUST process the element instances
generated for the use-element shadow tree
as if those elements were children of the use element itself,
with the following conditions:
When processing WAI-ARIA attributes on elements within a shadow tree,
the user agent MUST first attempt to match any IDREF values against other elements in the same shadow tree,
before searching for a match in the host's node tree.
If shadow trees are nested,
the user agent MUST recursively search from the current shadow tree
to the tree containing its host use element,
until the document tree is reached.
In all other cases, when matching IDREF values in WAI-ARIA attributes,
the user agent MUST NOT consider elements in the shadow tree
of a use element.
I would prefer to harmonize this guidance with general rules for ARIA and shadow DOM (and there is an issue in the SVG-AAM to that effect).
The text was updated successfully, but these errors were encountered:
Is this a platform-specific mapping issue, or a platform-agnostic issue? If the latter, I think the change should be done in the ARIA spec; not the Core AAM spec.
Related aside: I realize that the Core AAM currently has content about what gets included in the accessibility tree. There have been discussions about moving that to the ARIA spec and removing it from Core AAM because AAMs are about platform mappings/exposure. I personally think such a move is desired, with the Core AAM only containing things related to platform-specific inclusion/exclusion.
I don't think there would be anything platform-specific. This is about mapping the DOM tree(s) to the accessibility tree, and mapping IDRefs to accessible nodes. Once the accessibility tree is constructed, I think the normal platform mappings could apply (although any APIs/ATs that rely on actual DOM access may have issues).
If all the accessibility tree sections get moved into the main ARIA spec, then this issue should move along with them.
If you think this issue would get more attention in the main repo, feel free to move it in advance of re-organizing the specs. But for now, the text that needs modifying is in Core-AAM.
The DOM tree as implemented in the latest browsers is considerably more complex than it was a few years ago.
The Core-AAM guidelines on constructing the accessibility tree should be written to clarify that they operate on the "flattened tree" (a term which seems to be no longer defined in the WHATWG DOM standard, but meaning the hierarchy of elements that are used as the input to rendering, regardless of their official DOM parent-child relationships).
A more complicated issue is how to handle IDREFs in ARIA attributes. IDs are not unique across shadow trees, and you can't easily query shadow tree IDs from the main document.
The SVG-AAM currently contains the following guidelines about ARIA IDREFs in the context of SVG
use
shadow trees:I would prefer to harmonize this guidance with general rules for ARIA and shadow DOM (and there is an issue in the SVG-AAM to that effect).
The text was updated successfully, but these errors were encountered: