Is the accessibility tree built on the DOM tree, or the flat tree (incl. shadow DOMs)?

[Jym77]

Describe your concern

The spec is a bit unclear on how content in the shadow DOM or slots should be handled when building the accessibility tree, notably impacting the "allowed children". Browsers are currently (April 2024) implementing this differently.

<div id="list-host"><li>One</li><li>Two</li><li>Three</li></div>

<script>
  const listHost = document.getElementById('list-host');
  const listRoot = listHost.attachShadow({mode: 'open'});
  listRoot.innerHTML = "<ul><slot></slot></ul>"
</script>

This builds a DOM tree, with shadow included, looking like:

#shadow-tree
  <ul>
    <slot>
<li> // slotted
<li> // slotted
<li> // slotted

And a flat tree (i.e. result of flattening the shadow trees and slotting the elements) looking like:

<ul>
  <li>
  <li>
  <li>

Chrome builds that and then gives the <li> elements a role of listitem, i.e. look for a parent <ul> in the flat tree.

On the other hand, Firefox turns the DOM tree into an accessibility tree like:

list
  generic // first <li>
  generic
  generic

I.e., it gives the <li> a role of generic, likely looking for a parent <ul> in the DOM tree only.

ARIA 1.3 has an accessibility tree Section where the text and examples in the relationship Subsection feel pretty much geared for "DOM tree", without mentioning shadow DOM. So it sounds from it like an "accessibility child" cannot cross shadow boundaries 🤔

We recently had a discussion in name computation to include shadow and slotted descendants. I think it would make sense to have the similar move for the accessibility tree.

Link to the version of the specification or documentation you were looking at at.

Link to documentation: the editors draft

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?
Yes.

[spectranaut]

Discussed briefly in triage today: https://www.w3.org/2024/05/02-aria-minutes.html#t01

[scottaohara]

@Jym77 i don't think this is actually an issue with Shadow DOM specifically, but an oddity with how Firefox is determining whether an li is a generic or not.

e.g., declaring the two following examples in markup (so not using shadow dom at all) both li's are generic.

<ul>
  <div>
    <li>...</li> <!-- returned as generic -->
  </div>
</ul>

<ul>
  <slot>
    <li>...</li> <!-- returned as generic -->
  </slot>
</ul>

unless there are other examples you're seeing that go beyond this specific issue, this might actually be resolved with implementations changing to account for intervening generics between a list container and the listitem children - w3c/html-aam#540

[Jym77]

@scottaohara Good point.

I think the underlying question of building the accessibility tree from DOM or flat tree still exists, but I agree this precise case is probably only FF not skipping generic for the role of <li> elements.

The fact that the <li> are direct children of the <ul> in the flat tree but not in the DOM tree does trigger that problem, though. But I agree that skipping over the generic <slot> would avoid that.