Open alexnozer opened 6 months ago
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.
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.
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.
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.
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(
treeand
treegrid` required different UX and is not supported yet).
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.
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 usingaria-orientation="horizontal"
orrole="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 tabsrole="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 likerole="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.