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.

Sign up for GitHub

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

Jump to bottom

Is ARIA required owned elements failed example 7 really a fail? [bc4a75] #1810

Closed
dd8 opened this issue Mar 10, 2022 · 11 comments
Closed

Is ARIA required owned elements failed example 7 really a fail? [bc4a75] #1810

dd8 opened this issue Mar 10, 2022 · 11 comments
Assignees
@tombrunet @kengdoj @daniel-montalvo

Comments

@dd8
Copy link
Collaborator

dd8 commented Mar 10, 2022 •
edited
Loading

Although having treeitems inside a menu doesn't make sense, I don't think this violates the required owned elements conditions in ARIA 1.1 and 1.2 so example 7 shouldn't be a fail for this rule.

https://act-rules.github.io/rules/bc4a75#failed-example-7

<!DOCTYPE html> 
<div role="menu">
 <div role="group">
  <span role="menuitem">Item 1</span>
  <div role="group">
   <span role="treeitem">Item 1</span>
   <span role="treeitem">Item 2</span>
  </div>
 </div>
</div>

The ARIA 1.1 and 1.2 specs requires "at least one element" to satisfy the condition. It does not exclude other roles:
https://www.w3.org/TR/wai-aria-1.1/#mustContain

For example, you want to have elements with role=img for document type icons inside a Mac Finder or Windows Explorer style file system tree. And Example 12 in the ARIA spec has role=presentation interleaved with tree and treeitem roles.

For the code above I think the "at least one required owned element" condition is satisfied for all elements:

role=group - required owned elements: none
role=menu - required owned elements: group -> menuitemradio, menuitem, menuitemcheckbox, menuitemradio
role=menuitem - required owned elements: none
role=treeitem - required owned elements: none

It's not a failure of the required context role rule either, since the ARIA spec allows this test case because treeitem is contained by a group:

Authors MUST ensure elements with role treeitem are contained in, or owned by, an element with the role group or tree.

This is different to the requirement for role=menuitem which must be owned by role=menu or role=menubar:

https://www.w3.org/TR/wai-aria-1.1/#menuitem

Authors MUST ensure that menu items are owned by an element with role menu or menubar in order to identify that they are related widgets
@carlosapaduarte
Copy link
Member

If I recall correctly the reasoning behind that example is the following:

  • the "menu" role has a "group" role to meet the required owned elements condition
  • but the "group" role that meets the "menu" role condition must own a "menituemradio" role to meet the condition and it doesn't (it own a "menuitem" and a "group" role)

@carlosapaduarte
Copy link
Member

This is considering ARIA 1.1
When we move to ARIA 1.2 then we will need to update this example because the "menuitem" role will work.

@WilcoFiers WilcoFiers changed the title Is ARIA required owned elements failed example 7 really a fail? Is ARIA required owned elements failed example 7 really a fail? [bc4a75] Jul 8, 2022
@WilcoFiers
Copy link
Member

This rule is stricter than WAI-ARIA. It doesn't map to WAI-ARIA in its requirements because of it. Instead it maps to SC 1.3.1, where I think you can quite reasonably argue that treeitems aren't supposed to be inside a menu, and that doing so creates problems when you want to use something like a custom stylesheet to modify how menus are presented.

I would like ARIA to have a better description on what you can and can't do. I opened an issue on it back in 2020, w3c/aria#1161 they're planning to address it in ARIA 1.3.

@dd8
Copy link
Collaborator Author

dd8 commented Jul 11, 2022 •
edited
Loading

This rule is stricter than WAI-ARIA. It doesn't map to WAI-ARIA in its requirements because of it. Instead it maps to SC 1.3.1

Ok, that makes sense, but if 1.3.1 is the mapping doesn't the rule need to only apply to visible elements?
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html#dfn-presentation

At the moment it also applies to elements not visible on screen, but still in the accessibility tree (e.g. hidden offscreen, or with content-visibility: auto; display: none;) which wouldn't fail 1.3.1 since there's no presentation rendered

And if it's not mapping to ARIA should it have ARIA in the title?

@dd8 dd8 mentioned this issue Jul 17, 2022
Closed
7 tasks
@daniel-montalvo
Copy link
Collaborator

In addition to what @WilcoFiers has commented, this seems to be having an impact on what screen reader users get when interacting with this menu.

With last versions of JAWS and Chrome, the up and down arrow keys do not go to previous and next item. I have to enable JAWS' virtual buffer to have these items spoken.

Also, JAWS does distinguish the roles. When there's a menuitem role JAWS does say "menu item", and when there's a treeitem role JAWS does say "tree item".

Even if the spec could be clearer on what ownership relationships are and are not allowed, I think we should not have passed examples like this one.

@dd8
Copy link
Collaborator Author

dd8 commented Jul 27, 2022 •
edited
Loading

I think problem is this:

  1. Does the example cause accessibility problems? I think we all agree it does.
  2. Is the example an ARIA conformance issue? That doesn't seem true in ARIA 1.2 but may be fixed in ARIA 1.3 (Inconsistent use of "owned by" w3c/aria#1161). We can ignore ARIA here because this rule maps to WCAG 1.3.1.
  3. Should example 7 map to WCAG 1.3.1? That's unclear because all the text is unstyled so it's hard to see any "Information, structure and relationships conveyed through presentation" in the example.

I think there's a general difficulty with mappings in ACT-Rules because a single failure can map differently depending on context (e.g. if the example was hidden offscreen, so in a11y tree but not rendered on screen, then it would cause accessibility problems but can't map to 1.3.1 because there's no visual presentation)

@kengdoj
Copy link
Collaborator

kengdoj commented Jul 28, 2022 •
edited
Loading

While it's not identical, could Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content be relevant for Fail Ex 7?

Description
The objective of this technique is to describe a failure that occurs when structural markup is used to achieve a presentational effect, but indicates relationships that do not exist in the content. This is disorienting to users who are depending on those relationships to navigate the content or to understand the relationship of one piece of the content to another.

This is how NVDA reads Failed Ex 7, which has treeitem in menuitem group:

menu item Item 1
level 3 Item 1 level 3 Item 2

The "level 3" information can be confusing or "disorienting" to a user because the level relationship (that is announced for treeitem) isn't announced for menus.

For comparison, this is how NVDA reads Passed Ex 7, which has menuitem in menuitem group:

menu item Item 1
menu item Item 2 menu item Item 3

@tombrunet
Copy link
Collaborator

Circling back to Carlos's comment from Mar 15. While I agree that a standalone group does not require menuitem children, the construct in Required Owned Elements of menu (https://www.w3.org/TR/wai-aria-1.2/#menu) implies that a group within a menu requires a menuitem, menuitemradio, or menuitemcheckbox. Is there anything in ARIA that clarifies that construct?

@kengdoj
Copy link
Collaborator

kengdoj commented Aug 4, 2022

Aug 4 ACT Task Force discussed and agreed: assistive technology provides different information for menuitem vs treeitem in a menuitem group, and it can be confusing for the user.

RESOLUTION: Keep failed example 7 as a failure of 1.3.1, leave the issue open to improve the example

@dd8
Copy link
Collaborator Author

dd8 commented Sep 6, 2022 •
edited
Loading

The problem I have with this being mapped to a 1.3.1 fail is the role attribute may not have any effect on visual presentation (as happens in this example).

This is different to F43 where elements with implicit semantics and default styling are used for presentational effect (e.g. mis-using a heading to make some text bold)

the following examples are all rendered identically, which makes it hard to argue that information, structure and relationships are conveyed through presentation:

<!DOCTYPE html> 
<div role="menu">
 <div role="group">
  <span role="menuitem">Item 1</span>
  <div role="group">
   <span role="treeitem">Item 1</span>
   <span role="treeitem">Item 2</span>
  </div>
 </div>
</div>

<!DOCTYPE html> 
<div role="menu">
 <div role="group">
  <span role="menuitem">Item 1</span>
  <div role="group">
   <span role="menuitem">Item 1</span>
   <span role="menuitem">Item 2</span>
  </div>
 </div>
</div>

<!DOCTYPE html> 
<div>
 <div>
  <span>Item 1</span>
  <div>
   <span>Item 1</span>
   <span>Item 2</span>
  </div>
 </div>
</div>

I'll file an issue on ARIA 1.2 for the group nesting case since the required owned elements section of https://www.w3.org/TR/wai-aria-1.2/#menu implies a stricter model than the ownership model of
https://www.w3.org/TR/wai-aria-1.2/#treeitem (and the treeitem ownership model is much looser than menuitem)

@WilcoFiers
Copy link
Member

@dd8 I think an issue with ARIA is a good idea. This may already be getting addressed with w3c/aria#1454.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tombrunet tombrunet

@kengdoj kengdoj

@daniel-montalvo daniel-montalvo

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@WilcoFiers @carlosapaduarte @dd8 @tombrunet @kengdoj @daniel-montalvo