Pull Request Overview

This PR introduces a formal definition for "transparent elements" and updates accessibility parent/child relationship definitions to use this new terminology instead of the previous ad-hoc references to generic or none/presentation roles. The change clarifies which elements should be ignored when determining accessibility tree relationships.

• Adds a formal definition of "transparent elements" that includes both presentation/none roles and generic elements without accessibility-relevant attributes
• Updates all references to accessibility parent/child relationships to use the new transparent element definition
• Adds live region roles/attributes as an example of semantics that cause accessibility events

_{Tip: Customize your code reviews with copilot-instructions.md.Create the file orlearn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card.Take the survey.}

This looks great! And I think it is clear.

About whether or not this change is normative -- I'm not sure. In some respects, I think this "transparent" definition is what the "accessible children" work was originally trying to achieve, a case was just missed.

But this change in definition does change "Authors MUST statements", like:Authors MUST only add child element with allowed roles.. Because it changesauthor MUST statements we should have ACT review.

But it doesn't effect browser implementations right, because we don't specify how to exposes roles outside of their required context?

This is so great,@smhigley. 🤩 Very helpful to have a clear term — dad joke intended. 🤓

I would like to discuss an alternative to this addition. I suspect adding another definition is not as helpful. Instead, I would

• add the information on when generics are excluded to Section 7.1
• reduce the list for accessibility tree "candidates" to just 2 - DOM descendants and aria-own (descendants)
• add more notes as needed
• remove the extraneous stuff in the definition of accessibility parent

The Interop Accessibility Investigation has had Tree Walker investigation on the list for two or three years now, because once this is testable in WebDriver, we know there are going to be major differences between implementations.

A key details I brought up in 2023 is that each implementation starts with different trees:

• Gecko starts with the DOM tree
• WebKit starts with the Layout tree
• Chromium was originally WebKit, and so started with Layout, but has moved to a hybrid model somewhere between the others

As such there are known and unknown places where important and potentially not-easily-reconcilable differences are left undefined and left up to the implementation.

• relationships between elements and nearby CSS generated content (pseudo elements)
• style or other changes that result in new in-betweener layout elements such as extra scroll views due to CSSoverflow which can change on the fly based on layout changes like newly loaded content or the browser window changing size.
• other style properties and emerging featuers, like responsive layouts via media queries, and newer display values that may result in new layout objects or hierarchical ordering differences

As such, the investigations have purposefully avoided testing or defining these relationships. The 2026 investigation is obviously furthest along.

Tree Walker investigation using GetAccessibilityProperties

• Author investigation tests for which parts of the Tree or Subtrees might be standardized in 2026 or later?
  • Purposefully write failing tests (tentative) that expose the areas where the internal accessibility tree differ between engines
  • File AOM or ARIA issues if it appears are some tree relationships that might be standardized as part of a 2027 Investigation

Citation:web-platform-tests/interop-accessibility#202 (comment) is a carryover every year, but this may be the year we can finally ship tests and investigate further.

Sorry to throw a wrench in after you've spent some time on this already, but I'm hopeful that the list above makes it clear why I can't support specifying accessibility parent/child definitions prior to these testability prerequisites.

Thanks to@smhigley for discussing this PR F2F. I still wished we could do better than Section 7 does right now (see also James Craig's recent review) but that's for another time.