Update required owned elements and required context role#1454
Conversation
scottaohara
left a comment
There was a problem hiding this comment.
since this is still a draft, just a few comments/suggestions. hope they're helpful
|
I updated the PR based on the comments, updated all references to "required owned elements"/"required context role", and moved the |
| <p>If it is necessary to make multiple additions, modifications, or removals within a container element that is already either partially or fully rendered, authors MAY set <code>aria-busy</code> to <code>true</code> on the container element before the first change, and then set it to <code>false</code> when the last change is complete. For example, if multiple changes to a <a>live region</a> should be spoken as a single unit of speech, authors MAY set <code>aria-busy</code> to <code>true</code> while the changes are being made and then set it to <code>false</code> when the changes are complete and ready to be spoken.</p> | ||
| <p>If an element with role <rref>feed</rref> is marked busy, assistive technologies MAY defer rendering changes that occur inside the <code>feed</code> with the exception of user-initiated changes that occur inside the <rref>article</rref> that the user is reading during the busy period.</p> | ||
| <p>If changes to a rendered <rref>widget</rref> would create a state where the <rref>widget</rref> is missing <a href="#mustContain">required owned elements</a> during script execution, authors MUST set <code>aria-busy</code> to <code>true</code> on the <rref>widget</rref> during the update process. For example, if a rendered tree grid required a set of simultaneous updates to multiple discontiguous branches, an alternative to replacing the complete tree element with a single update would be to mark the tree busy while each of the branches are modified.</p> | ||
| <p>If changes to a rendered <rref>widget</rref> would create a state where the <rref>widget</rref> is modifying <a href="#mustContain">allowed child roles</a> during script execution, authors MAY set <code>aria-busy</code> to <code>true</code> on the <rref>widget</rref> during the update process. For example, if a rendered tree grid required a set of simultaneous updates to multiple discontiguous branches, an alternative to replacing the complete tree element with a single update would be to mark the tree busy while each of the branches are modified.</p> |
There was a problem hiding this comment.
Can we just remove this. Does setting aria-busy in this state actually do anything?
There was a problem hiding this comment.
I'm happy to remove it, I just didn't want to muddy this PR with other changes if they'd be controversial 😅
|
Please also move the new terms to index.html. The content of terms.html has been moved there. You'll need to pull the changes from main though to pick this up. |
2480d3c to
5607c6c
Compare
|
All the previous comments should be addressed. @scottaohara / @aleventhal, how does it look now? |
|
also pinging @jcsteh because for some reason github isn't letting me add him to the reviewers ¯_(ツ)_/¯ |
| <p class="note">An element with a <a href="#subclassroles">subclass role</a> of the 'required owned element' does not fulfill this requirement. For example, the <rref>listbox</rref> role requires ownership of an element using the <rref>option</rref> or <rref>group</rref> role. Although the <rref>group</rref> role is the superclass of <rref>row</rref>, adding an <a>owned</a> element with a role of <rref>row</rref> will not fulfill the requirement that <rref>listbox</rref> owns an <rref>option</rref> or a <rref>group</rref>.</p> | ||
| <h3>Allowed Child Roles</h3> | ||
| <p>Any <a>element</a> that is a direct <a>child</a> of the element with this <a>role</a>. For example, an element with the role <rref>list</rref> may own elements with the role <rref>listitem</rref>, but not elements with the role <rref>option</rref>.</p> | ||
| <p>To determine whether an element is the direct <a>child</a> of a role, <a>user agents</a> MUST ignore any elements with the role <rref>generic</rref> or <rref>presentation</rref>.</p> |
There was a problem hiding this comment.
It's definitely good that we're clarifying what happens concerning generics here. That will clear up implementer confusion like this.
Again, this is clear if you read the definition of "child", but I wonder whether this could be misconstrued as discussing siblings rather than intervening (depth-wise) elements. Perhaps we could clarify this by saying "intervening elements" here?
Also, I assume this isn't a statement about whether intervening generics get exposed in the a11y tree or not, but rather, only a statement about what is considered valid (thus impacting implicit posinset/setsize calculation, etc.)? Pruning intervening generics would be a much bigger change for implementers which would need further discussion.
There was a problem hiding this comment.
I updated to "intervening elements" -- thanks for the suggestion, I like that better :).
And yup! This is guidance on allowed role structure, and isn't prescriptive of API mappings. The only change is implementers would officially need to support e.g. listbox > generic > option (which most already do), but could do so with or without pruning the generic.
4dc74da to
b210f3c
Compare
|
Just want to ping @jcsteh, @scottaohara, and @aleventhal on this to see if the updates have addressed past comments as desired :) |
scottaohara
left a comment
There was a problem hiding this comment.
wrote these review comments some time ago... sorry for the delay.
|
should also resolve #1486 |
|
Oh right what was I thinking, we even talked about this. I just got so wrapped up in the "rewrite" and new terms I forgot about this key change XD Do you want to do that here, or in a follow up issue? If a follow issue, please make one, otherwise, you can add a validator test here. |
Co-authored-by: Adam Page <adamfpage@gmail.com>
|
@spectranaut issue is made! #1917 |
spectranaut
left a comment
There was a problem hiding this comment.
I spoke too soon once again! The new CI check caught an errant "may", we need to fix that THEN I think it is ready for merge
Co-authored-by: Valerie Young <spectranaut@igalia.com>
jnurthen
left a comment
There was a problem hiding this comment.
I think a #mustContain was missed
Co-authored-by: James Nurthen <jnurthen@users.noreply.github.com>
SHA: 232ae78 Reason: push, by spectranaut Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Updates "Required Owned Elements" to "Allowed Child Elements", and "Required Context Role" to "Required Parent Role", with added definitions for parent, child, controlled element, and controlling element.
ARIA 1.2 added "Required Owned Elements" restrictions for several roles, and ARIA 1.3 clarified them as "Allowed Child Elements" — see w3c/aria#1454. The check now flags as non-conforming any element that violates one of the following: • role="rowgroup" must contain only role="row" • role="group" inside role="menu" or role="menubar" must contain only role="menuitem", role="menuitemcheckbox", or role="menuitemradio" • role="group" inside role="tree" must contain only role="treeitem" Fixes #2078
Resolves #1033
Updates "Required Owned Elements" to "Allowed Child Elements", and "Required Context Role" to "Required Parent Role", with added definitions for parent, child, controlled element, and controlling element.
I did some support tests for having intermediate elements in composite widgets, and secondary actions in composite widgets, here: https://cdpn.io/smhigley/debug/vYgLZgK
This is still a POC, so I didn't update all the references to required owned elements/context role. Hopefully that makes it a bit easier to see the relevant diffs for discussion.
Should also resolve #1486
PR merge check list
Preview | Diff
Preview | Diff