Add transparent generic definition and update accessibility parent and child defs#2599
Add transparent generic definition and update accessibility parent and child defs#2599
Conversation
…d child to reference it
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
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
Comments suppressed due to low confidence (2)
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn 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.
jnurthen
requested review from
adampage,
cookiecrook,
jnurthen and
spectranaut
| <ul> | ||
| <li>Elements that are currently focused, even if the element or one of its ancestor elements has its <sref>aria-hidden</sref> attribute set to <code>true</code>.</li> | ||
| <li>Elements that are a valid target of an <pref>aria-activedescendant</pref> attribute.</li> | ||
| <li>Elements that have <a>live region</a> roles or attributes.</li> |
There was a problem hiding this comment.
This addition is editorial, since the section already specifies elements that can fire an accessibility API event. I thought it should be added explicitly since it was the original example that kicked this off (and is probably the other most common attribute authors use that would trigger an a11y event)
spectranaut
left a comment
spectranaut
left a comment
There was a problem hiding this comment.
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 changes author 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?
Co-authored-by: Valerie Young <spectranaut@igalia.com> Co-authored-by: Adam Page <adamfpage@gmail.com>
|
@spectranaut thanks for the review! For this:
That's also my understanding, it doesn't affect browser implementations b/c we don't specify how to expose the intervening generics, and also this should bring the spec in line with the current behavior (i.e. aria-live on an intervening generic didn't work). |
spectranaut
moved this to Reviewed, need PR checklist item
in ARIA Editorial (Spec Prose Updates) PR Tracking
|
🚀 Deployed on https://deploy-preview-2599--wai-aria.netlify.app |
Co-authored-by: Peter Krautzberger <p.krautzberger@gmail.com>
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
smhigley
force-pushed
the
transparent-generic
branch
from
4d60517 to
f88ce37
Compare
This comment was marked as outdated.
This comment was marked as outdated.
spectranaut
requested review from
benbeaudry
and removed request for
benbeaudry
|
The ARIA Working Group just discussed The full IRC log of that discussion<Zakim> agendum 4 -- -> Add transparent generic definition and update accessibility parent and child defs https://github.com//pull/2599 -- taken up [from agendabot]<cyns> spectranaut_ this is just trying to make the spec more clear, no change to browsers <cyns> sarah change to spec to align with what browsers already do <cyns> spectranaut_: what browser input is needed? <cyns> @sarah: jcraig and (I think someone from Chrome) didn't want a must for removing things from teh a11y tree, and this should only define parent-child relationships. Moving to 7.1 would do that, so need input from browsers <benbeaudry> q+ <cyns> pk: seems like spec and user agent sides are at odds. I find the definition and the whole section confusing. we could aknowldege that UA might leave nodes in, but the spec should be more clear to explain what parent-child relationships should be. Can we do that without forcing UA to do somehting they don't want to? <spectranaut_> q+ <cyns> pk: almost seems contradictory, one section says to remove intermediate nodes, but this section assumes they're still there <cyns> sarah: may well be confusing! <cyns> pk: definition of accessibility object doens't align with other definitions <spectranaut_> ack benbeaudry <cyns> benbeaudry: sarah can you remember who from Chromium objected? pls tag me so I can review more deeply <cyns> sarah: I remember james craig, I think someoen from Chrome too <cyns> pk: gecko includes them <cyns> sarah: some browsers have the nodes, but they don't interfere with the tree. I remember from testing that browsers all handle it fine, but there can still be interviening generics <spectranaut_> q? <cyns> pk: want to meet up to hammer this out? <cyns> sarah: yes <cyns> spectranaut: I think what peter is saying that it should be clear for developers reading it, because browser behavior is not going to change. It makes sense to me because I worked on child nodes before, but good argument that it's confusing. maybe something like generics shouldn't be included in a11y tree, but browsers can leave them <cyns> pk: spec should be talking about aria layer, not OS a11y tree <cyns> spectranaut: developers will see the computed roles in browser dev tools, need to let them know to expect that. Does Ben need to review this? <cyns> sarah: I wanted to check my understanding that we don't want a browsers must, would still like that input, but don't need full review <Daniel> q+ <spectranaut_> ack spectranaut_ <spectranaut_> ack Daniel <cyns> daniel: we should clarify what counts as editorial. Does this modify a user agents must? <cyns> sarah: Peter's comment suggested a new browsers must, but it's not curernlty in the PR <cyns> zakim, next item |
There was a problem hiding this comment.
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 CSS
overflowwhich 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.
|
As an example:
<main>
<!-- start of in-betweener scroll view -->
<div role="group" style="overflow:scroll;">
contents
</div>
<!-- end of in-betweener scroll view -->
</mainIs the div a accessibility child of main? It may be in Windows. It would be unexpected for it to be in Mac, since the generated scroll view is a layout object (for example, in native AppKit view) that is the child of main and parent of the div. But even on the Mac platform, Safari and Firefox may disagree due to the implementation details. And that extra AX tree element scroll view may not conform to the ARIA definitions of "transparent" or "generic", even if we are able to agree on a definition for DOM elements. That's just one example why I think we need to tread cautiously in anything that seems close to defining a formalized accessibility tree in the browser. We have to ease up against the borders of platform-specific API differences. We'll get there, but not IMO until more reliable test methods become available. |
|
@cookiecrook I think you're interpreting this the same way Peter did, which is to read it as a general definition of how to calculate a full tree. In reality, this currently only pertains to specific role hierarchical requirements defined in the spec, such as CSS pseudo elements would never come up because they (currently) cannot have a role. For things like |
🚀 Netlify Preview:
🔄 this PR updates the following sspecs:
Closes #2423
Updates the accessibility parent/child relationships to reference "transparent" elements rather than simply generics or
role="none/presentation". Transparent is defined based on the language in the previous section (including elements in the a11y tree), and I added an explicit reference to live regions in the examples of semantics that cause an accessibility event.Test, Documentation and Implementation tracking
Once this PR has been reviewed and has consensus from the working group, tests should be written and issues should be opened on browsers. Add N/A and check when not applicable.
Preview | Diff