axe-core: Call out missing accessible name on various ARIA roles
Expectation: <div role="tree" /> triggers a violation because it does not have an accessible name. Example: https://2m3yw.csb.app/
Actual: No violation reported
Motivation:
role="tree"requires an accessible name in ARIA 1.1 and 1.2.- the tree will be announced as a generic “tree” in NVDA (possibly any screen reader) making it hard to understand the context of a specific item (though not as bad as having a generic
<button />). - Required to add an audit to lighthouse (https://github.com/GoogleChrome/lighthouse/issues/11155)
axe-core version: 3.5.5
chrome extension: 4.5.3
axe-core should probably report any element without a name that has a role that requires an accessible name.
Rules to add: Taken from https://github.com/dequelabs/axe-core/issues/2421#issuecomment-667045198
-
aria-structure-name (NEW) - tag: best-practice (https://github.com/dequelabs/axe-core/pull/2431) - aria-dialog-name (NEW) - tag: best-practice #2609
-
aria-table-header-name (NEW) - tag: 1.3.1 - aria-treeitem-name (NEW) - tag: best-practice #2615
- aria-meter-name (NEW) - tag: sc111 #2607
- aria-toggle-field-name: add “option” #2605
-
aria-input-field-name: add “radiogroup” - skipped, not sure if this is right - aria-command-name: (NEW) - tag: sc412 #2571
- aria-progressbar-name (NEW) - tag: sc111 #2555
- aria-tooltip-name (NEW) - tag: best-practice #2548
-
aria-marquee-name - not happening because of w3c/aria#1339
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (15 by maintainers)
Alrighty, update. I’ve discussed these new rules internally, and gained some new perspective on things. Here’s what has been decided:
aria-structure-name should not be added. There are lots of scenarios where grid, form, application, etc. do not benefit from having an accessible name. The only one that generally would benefit from getting an accessible name is
table, since tables can be pulled up in a list in screen readers, but in that case the best practice should apply to all tables, not just ARIA tables. See #2603.aria-table-header-name should not be added. Empty table headers are suspicious, but don’t necessarily mean there’s an accessibility issue. Instead of testing this just for ARIA, it would be better to have a role that checks all table headers, native or ARIA if they have an accessible name and flag it for as needs review if it does not have one. Here’s the ticket: #2604
That leaves a few more changes, see the top post of this issue.
I’d like to try tackling
aria-treeitem-name (NEW) - tag: best-practice. @WilcoFiers just a heads up!@WilcoFiers If you want to group the roles by their “concept” then I don’t know how you want to give actionable advise with the current json format of the rules. For example
treegets the name from author only whileheadingcan get it from contents and author. I don’t think reporting an error is helpful if no actionable advise is given.It’s also not clear how https://github.com/dequelabs/axe-core/issues/2421#issuecomment-667045198 fits into https://github.com/dequelabs/axe-core/pull/2431#pullrequestreview-458752473
I lean more towards https://github.com/dequelabs/axe-core/pull/2431#pullrequestreview-458752473 since this focuses on the action that should be taken. I see little value in telling the user that a
treeis in thestructuregroup. Or are there some additional axe ressources where you go into detail how structures should be handled?Hey @eps1lon, apologies for the slow response.
Yes, you’re right, my bad.
Each new rule should be in a new PR.