Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add guidance on handling shadow DOM content #4

Open
AmeliaBR opened this issue Mar 8, 2018 · 2 comments
Open

Add guidance on handling shadow DOM content #4

AmeliaBR opened this issue Mar 8, 2018 · 2 comments

Comments

@AmeliaBR
Copy link

AmeliaBR commented Mar 8, 2018

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:

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).

@joanmarie
Copy link
Contributor

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.

@AmeliaBR
Copy link
Author

AmeliaBR commented Jun 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants