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)
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 <[email protected]> Co-authored-by: Adam Page <[email protected]>
|
@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
5 participants
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