Controversial use of the `role="menu"`

[alexnozer]

Hello! I found the KeyUX interesting. But I don't quite agree with using the role="menu" for widgets with arrow navigation. According to the ARIA specification, role="menu" represents vertical (by default) or horizontal (when using aria-orientation="horizontal" or role="menubar") sets of actions that users can invoke. This is similar to the command menu bar in most desktop applications. But it's not a set of navigation links or tabs as described in README.

This stems from a misunderstanding of the term "menu" in natural usage (as panel with links) and the term "menu" from the ARIA specification (as set of invokers). Also more about menu pattern describes in ARIA AGP. It also gives an example of a navigation menu with a role="menu", but warns that this role is not entirely suitable in this case, although it can be applied.

For navigation aids role="navigation" + role="link" (<nav> and <a> elements in HTML) should be used. For tabs role="tablist" + role="tab" + role="tabpanel" (there is no alternative in HTML) should be used. There are also many patterns that use arrow navigation between grouped elements instead of tab-key: listbox, toolbar, menubar, radiogroup, grid, etc. I think that using a single abstraction like role="menu" as an arrow navigation indicator, as in KeyUX, is not the best way.

Instead, I propose to look at focusgroup proposal from the OpenUI group and the focusgroup polyfill for this proposal by Microsoft Edge team and make a similar or the same (for future compatibility with the focusgroup standard). This approach will allow developers to use suitable ARIA roles for different patterns and combine them with KeyUX arrow navigation.

[ai]

This is why I love open source.

It worried me too, but I didn't know a standard syntax for that.

Let's add support of more roles for arrow-navigation and I will think about adding that proposal.

[ai]

The only problem with focusgroup which worry me, that screen reader will not notify user about another type of navigation.

Later, when it will be standard, they could have some way.

But what we can do right now? Maybe you know some aria- property to explain that we are in arrow key navigation.

[ai]

Here is the first refactoring planes https://github.com/ai/keyux/issues/9

Do you want to send PR or I can use Cult of Martians?

The second plan will be focusgroup but we need to think about screen reader UX first.

[alexnozer]

Let's add support of more roles for arrow-navigation

According to the WAI ARIA spec, authors must manage focus for the following roles: grid, listbox, menu, menubar, radiogroup, tree, treegrid and tablist. Arrow navigation also used in toolbar widget.

The listbox widget uses focus management technique using the aria-activedescendant attribute.

The grid and treegrid widgets use two-axis arrow navigation.

The only problem with focusgroup which worry me, that screen reader will not notify user about another type of navigation.

Later, when it will be standard, they could have some way.

But what we can do right now? Maybe you know some aria- property to explain that we are in arrow key navigation.

I think that is not a problem. The focusgroup is a keyboard navigation mechanism. But the information about the navigation mechanism relates to the element semantics. Every role that includes arrow navigation implies the presence of such navigation. I mean that when a screen reader user comes to a menu or toolbar, they expect arrow navigation to be available. That is, the very addition of the ARIA role already gives the user an infirmation of how to navigate through the element.

Developers can use the aria-describedby or less supported aria-description attributes to provide additional information about shortcuts and navigation mechanism. But it is not required.

Do you want to send PR or I can use Cult of Martians?

I can try to make some fixes/additions to it.

[ai]

I mean that when a screen reader user comes to a menu or toolbar, they expect arrow navigation to be available.

Yes, but on focusgroup screen readers will not say anything.

For visual user it is not a problem since they see that focus is not moved to element they saw.

But for screen reader is a problem since they do not know about elements they are missing not pressing arrow keys.

Developers can use the aria-describedby

Screen reader will repeat it every time. So we need some example in docs with very short but clear notice.

Or maybe we should not add focusgroup for now and recommend using menu/listbox/tablist(treeandtreegrid` required different UX and is not supported yet).

[alexnozer]

Yes, but on focusgroup screen readers will not say anything.

For visual user it is not a problem since they see that focus is not moved to element they saw.

But for screen reader is a problem since they do not know about elements they are missing not pressing arrow keys.

My point is that a focusgroup and a role serve different purposes. Developers can combine the semantic value of role and keyboard navigation with a focusgroup. Also developers can use role without focusgroup and implement their own mechanism or developers can use focusgroup without role to implement their own semantics (e.g. role="group" with aria-label or something else).

Screen reader will repeat it every time. So we need some example in docs with very short but clear notice.

We can recommend developers to use focusgroup + one of the arrow navigation roles. We can also display a console warning if focusgroup is used without the appropriate role. But this is an interesting question, there are different solutions.

Or maybe we should not add focusgroup for now and recommend using menu/listbox/tablist (treeandtreegrid` required different UX and is not supported yet).

This makes sense as a starting point. I think a focusgroup requires more research and can be implemented later.