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.