Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Examples in ARIA Authoring Practices fail ARIA required owned elements rule #1985

Open
dd8 opened this issue Dec 5, 2022 · 5 comments
Open

Comments

@dd8
Copy link
Collaborator

dd8 commented Dec 5, 2022

Some examples in ARIA Authoring Practices 1.2 fail the ARIA required owned elements rule

Which one is wrong? The ARIA Authoring Practices examples or the rule?

The tab examples - they have an h3 with implicit role=heading inside the tab, which isn't in the required owned elements list of tab:

The radiogroup example also contains an h3:

<div role="radiogroup" aria-labelledby="group_label_1" id="rg1">
  <h3 id="group_label_1">Pizza Crust</h3>

  <div role="radio" aria-checked="false" tabindex="0">
    Regular crust
  </div>

https://w3c.github.io/aria-practices/examples/radio/radio.html

The table example has a div#students_table_desc inside the tab which has implicit role=generic:

<div role="table" aria-label="Students" aria-describedby="students_table_desc">
  <div id="students_table_desc">Students currently enrolled in WAI-ARIA 101 for the coming semester</div>
  <div role="rowgroup">
    <div role="row">

https://w3c.github.io/aria-practices/#table

The menubar example has an explicit role=separator in the middle of the menu which isn't in the required owned elements list. This definitely looks like a problem with the rule - not representing the menu separator in the a11y tree is probably a failure of 1.3.1.

          <li role="separator"></li>
          <li role="none">
            <a role="menuitem" href="#course-explorer">Course Explorer</a>
          </li>

https://w3c.github.io/aria-practices/examples/menubar/menubar-navigation.html

And what about these - the caption element maps to role=caption but that isn't a required owned element of table or treegrid:

<table role='table'>
<caption>This is the table caption</caption>
</table>

<table role='treegrid'>
<caption>This is the treegrid caption</caption>
</table>

The problematic part of the rule is the expectation that only required owned roles appear - which means the rule fails optional owned elements like table captions, or menu separators (all menus have menu items, but not all menus have menu separators)

For example, the spec for menuitemcheckbox says:

Authors MAY separate menu items into sets by use of a separator or an element with an equivalent role from the native markup language

https://www.w3.org/TR/wai-aria-1.2/#menuitemcheckbox

Edit: the problems with headings and separator occur with the ARIA 1.1 examples as well:
https://www.w3.org/WAI/ARIA/apg/example-index/tabs/tabs-automatic.html#sc1_label
https://www.w3.org/WAI/ARIA/apg/example-index/radio/radio.html#sc1_label
https://www.w3.org/WAI/ARIA/apg/patterns/menu/#h-note-17

But other problems are new in ARIA 1.2 because of new roles like generic, caption and paragraph.

@Jym77
Copy link
Collaborator

Jym77 commented Dec 6, 2022

Seems to be related to #1426 🤔

@dd8
Copy link
Collaborator Author

dd8 commented Dec 6, 2022

The caption role is allowed in table/grid/treegrid but is not a required owned element:

Visible content that names, and may also describe, a figure, table, grid, or treegrid.

When using caption authors SHOULD ensure:
The caption is a direct child of a figure, table, grid, or treegrid.
The caption is the first child of a table, grid, or treegrid.
The caption is the first or last child of a figure.

https://www.w3.org/TR/wai-aria-1.2/#caption

And this is accessible:

<fieldset> <!-- implicit role=group -->
<legend>Color</legend>
<label><input name="color" type="radio" aria-describedby="help" >Red</label>
<label><input name="color" type="radio" aria-describedby="help" >Green</label>
<p id="help">Choose a color for your background</p>
<fieldset>

but fails the rule as soon as you add a role to the fieldset because the p has implicit role of paragraph:

<fieldset role="radiogroup">
<legend>Color</legend>
<label><input name="color" type="radio" aria-describedby="help" >Red</label>
<label><input name="color" type="radio" aria-describedby="help" >Green</label>
<p id="help">Choose a color for your background</p>
<fieldset>

@dd8
Copy link
Collaborator Author

dd8 commented Dec 14, 2022

ARIA 1.3 w3c/aria#1454 treats role=generic like role=presentation when looking for ancestor / descendants so problems with div and span go away (and ARIA 1.2 says role=generic has no semantics so not unreasonable to ignore role=generic for ancestors / descendants when referencing ARIA 1.2).

Also added a comment about the optional child roles:
w3c/aria#1454 (comment)

However the issue with <p id=help> in the fieldset in the previous example remains.

@dd8
Copy link
Collaborator Author

dd8 commented Dec 14, 2022

The rule also fails an ARIA example on MDN because the <p> inside radiogroup has implict role=paragraph
https://developer.mozilla.org/en-US/docs/web/accessibility/aria/roles/radiogroup_role#examples

There's also an issue with naming role=radiogroup: if only role=radio elements are allowed as owned elements, how do you add a visible label for the group inside the radiogroup? ARIA 1.3 solves this by allowing role=caption in radiogroup, but this isn't allowed in ARIA 1.2.

For example:

<div role='radiogroup' aria-labelledby='legend'>
 <p id='legend'>I accept the Terms and Conditions</p> <!-- implicit role=paragraph -->
 <span role='radio'>Yes</span>
 <span role='radio'>No</span>
</div>

Even the ARIA 1.3 allowance for caption is too limiting - a real-life version of the example above needs a link to the terms and conditions somewhere inside the radiogroup.

@carlosapaduarte
Copy link
Member

From the CG meeting:

update "owned by" definition to ignore role generic; and update the expectation of aria required element to "require at least one element" instead of "requires all required elements"

This should address the issues raised here and #1990 and #1995

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants