Repository navigation
Conversation
* Remove redundant "so this fails the rule". * More polishing of example descriptions * Another instance * Remove isolated parenthetical sentence. * A couple more instances of "so this [...]"
* s/button/link in Failed Example 3 * Add a missing space in Failed Example 4
✅ Deploy Preview for act-rules ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
shunguoy
changed the title
Co-authored-by: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com>
Co-authored-by: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com>
Co-authored-by: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com>
Co-authored-by: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com>
Co-authored-by: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com>
|
|
||
| #### Passed Example 12 | ||
|
|
||
| This element with the `menu` role has no accessibility child. Note because the element also has an `aria-busy` attribute set to `true`, it also passes ARIA 1.2. |
There was a problem hiding this comment.
This is still a failure of the expectation. As it's written in the spec today, I don't think this is valid either:
If changes to a rendered widget would create a state where the widget is modifying Allowed Accessibility Child Roles during script execution, authors MAY set aria-busy to true on the widget 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.
E.g. you can set aria-busy if you're making multiple changes to the descendants and want those communicated as one change. There's nothing here about allowing other content while aria-busy is set. I this continues to be an error. Loading is a status message after all, which screen readers have to announce, but putting aria-busy on it actually may prevent the announcement.
There was a problem hiding this comment.
based on the spec, the aria-busy="true" can be used in a menu role to signal loading of the menu items, however, the example inside the list break the HTML structure, updated into:
<ul role="menu" aria-busy="true">
<li role="none">Loading...</li>
</ul>
| <ul> | ||
| <div></div> | ||
| <div></div> | ||
| </ul> |
There was a problem hiding this comment.
I think we should lave this in with a global attribute to show how generics can find their way back into the accessibility tree:
<ul>
<div aria-live="true">
<li>Hello world</li>
</div>
</ul>There was a problem hiding this comment.
Based on ARIA 1.3, the elements with the generic role are ignored in Accessibility Child calculation in general:
All DOM descendants of the [element](https://dom.spec.whatwg.org/#concept-element) with only elements of role [generic](https://w3c.github.io/aria/#generic) or [none](https://w3c.github.io/aria/#none) intervening.
This example may cause confusion although <div aria-live="true"> may be exposed to the accessibility tree, but yet, ARIA 1.3 doesn't include it in the accessibility child calculation.
In addition, this example breaks HTML structure. It's better to remove it.
Co-authored-by: Wilco Fiers <WilcoFiers@users.noreply.github.com>
Co-authored-by: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com>
Co-authored-by: Wilco Fiers <WilcoFiers@users.noreply.github.com>
…s.github.io into aria1.3-allowed-child
|
|
||
| #### Passed Example 13 | ||
|
|
||
| The both `div` elements with explicit `list` roles have no accessibility children. The `listitem` element is either with `aria-hidden` or has no owned element through `aria-owns` in the first `div` element. |
There was a problem hiding this comment.
| The both `div` elements with explicit `list` roles have no accessibility children. The `listitem` element is either with `aria-hidden` or has no owned element through `aria-owns` in the first `div` element. | |
| Both `div` elements with explicit `list` roles have no accessibility children. The `listitem` element is either with `aria-hidden` or has no owned element through `aria-owns` in the first `div` element. |
Co-authored-by: Dan Tripp <113939352+dan-tripp-siteimprove@users.noreply.github.com>
<< Describe the changes >>
Closes issue(s):
[bc4a75] Update the rule and examples to comply with ARIA1.3 #2438
Need for Call for Review:
<< choose one of the following and remove the rest >>
<< check Process Document on Call for Review >>
This can be merged with 1 approval << choose reason: editorial changes to website/test code, adding new contributor, other (explain). >>
This will require a 2 weeks Call for Review << new rule, or substantial changes affecting a large number of examples, if in doubt, use this. >>
Pull Request Etiquette
When creating PR:
developbranch (left side).After creating PR:
Rule,DefinitionorChore.When merging a PR:
How to Review And Approve