MenuItem must use aria-checked only when its role is menuitemcheckbox or menuitemradio

[afercia]

See #8279 and following changes. See #10545

The aria-checked state is used to indicate the "checked" state of checkboxes, radio buttons, and other widgets. It must be used exclusively with the following ARIA roles:

https://www.w3.org/TR/wai-aria-1.1/#aria-checked
used in roles:
checkbox
option
radio
switch

inherits in roles:
menuitemcheckbox
menuitemradio
treeitem

The MenuItem component has a default ARIA role of menuitem, and it's used also with the roles menuitemcheckbox and menuitemradio.

However, its aria-checked HTML attribute is set based on its isSelected prop, regardless of its role:

gutenberg/packages/components/src/menu-item/index.js

Line 81 in 122e569

'aria-checked': isSelected,

The component should make sure aria-checked is set only when the role prop is menuitemcheckbox or menuitemradio.

Also, it should make sure that when a isSelected prop is passed, the actual intent of the developers is to communicate a "checked" state, thus a menuitemcheckbox or menuitemradio should be used.

Currently, seems to me the correct usage of this component is up to the developers knowledge, while I'd tend to think a component shouldn't assume such a deep accessibility knowledge.

Right now, there's at least one case where aria-checked is applied incorrectly on a role menuitem: the BlockNavigation component:

The menuitem role doesn't have any "checked" state, it's meant for generic items in a menu.

Reference:

menuitem role:

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

An option in a set of choices contained by a menu or menubar.

menuitemcheckbox role:

meant to indicate a menu item with checked state, where multiple choices are allowed:

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

A menuitem with a checkable state

menuitemradio role:

meant for a menu item in a set of items where only one can be checked (single choice):

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

A checkable menuitem in a set of elements with the same role, only one of which can be checked at a time.

Worth also mentioning the implementation details in the ARIA Authoring Practices:
https://www.w3.org/TR/wai-aria-practices-1.1/#menu

Not sure what is the best path forward, but I'd recommend to consider to make developers life easier offering them a component that sets the correct ARIA roles and states/properties based on a simple prop. Maybe something like a type generic, singleChoice, and multipleChoice or something along those lines?

[designsimply]

I noticed at the top of https://www.w3.org/TR/wai-aria-1.1/#aria-checked it says:

aria-checked (state) indicates the current "checked" state of checkboxes, radio buttons, and other widgets.

Forgive me if these are silly questions. Could block navigation be considered a widget? I noticed both check boxes and menu items are listed in the definition of a widget on that same page. Would switching from menuitem to treeitem solve the problem for block navigation or are you saying that aria-checked should simply be removed for block navigation menu items because menuitem isn't explicitly mentioned in the characteristics table?

Aside from that, is there a use case that can show the problem you are trying to solve? For example, navigating block navigation using a Screenreader or VoiceOver is not working? Or is this strictly about adhering to W3C WAI recommendations and to be considered a code quality issue?

[afercia]

Absolutely. Thanks for your question, it gives me the opportunity to dive into details a bit better 🙂

When it comes to assistive technology software, it's like going back to how browsers used to behave 15 years ago 😬There are different implementations, inconsistencies, and support for some features greatly varies. The only way to maximize support is to strictly adhere to the specification, as that's the basement assistive technology software are built upon.

A menu is certainly a composite widget, see https://www.w3.org/TR/wai-aria-1.1/#widget_roles
Worth also noting "widget" is a term that's also generically used to refer to user interface elements that don't exist natively in HTML.

As per the consequences of not using ARIA roles and attributes correctly, they vary. In my testing, seems Safari and VoiceOver don't pay much attention to it and announce "ticked" anyways.

Instead, for example with Firefox and NVDA, there's an important difference:

menuitemcheckbox: the checked state is announced:

menuitemradio: the checked state is announced

menuitem: the checked state is not announced, thus not allowing users to understand which block is the selected one in the blocks navigation menu 😞

Aside: the two screen readers also announce the same information in different ways: "ticked" vs. a more verbose wording. That's typical and I guess JAWS and other screen readers announce it in their own way as well.

[BE-Webdesign]

I can work on this. Thank you for your knowledge @afercia!

[afercia]

@BE-Webdesign @designsimply thanks!
Not sure what are the plans, but I've just realized that if this menu is meant to be used also with nested block and to represent their "indentation level", then an ARIA menu wouldn't be appropriate and we should consider an ARIA tree. I guess it's something that can go in next iterations, if necessary.

[BE-Webdesign]

@afercia,

I think that would make another good issue. The aria-checked, although related, is separate from how the hierarchy/indentation level is structured.