posts/menubar-navigation-and-keyboard/

[giscus[bot]]

posts/menubar-navigation-and-keyboard/

From role to a keybaord interaction model, a tale of a mega menu.

https://neilosman.com/posts/menubar-navigation-and-keyboard/

[aardrian]

A nav landmark tells users what the region is: site navigation. A menubar tells assistive technology users something about how it behaves:

It tells only screen reader users that it is an application-style menu, though APG has had a hand in corrupting that meaning and intent (which, fine, UIs evolve). But menubar also limits it to only contain the roles menuitem, menuitemcheckbox, menuitemradio, and separator. Which means all those headings and images common to "megamenus" are right out. As are links. So menubar does far more than just telling screen reader users its purpose and keyboard interaction method. It constrains patterns.

The unresolved question is whether adding menubar semantics should force authors to remove the familiar Tab model simply to preserve the purity of the composite-widget convention.

Yes, because menubar is exposed only to screen reader users, depriving keyboard users of the only programmatic cue that the navigation has had one of its core operability features removed. On top of that, a menubar is a widget role, meaning it's a tab-stop of its own and that authors must manage focus within it (so supporting Tabbing within it would be against the ARIA spec).

I am not presenting that as a new pattern. I am saying it is a combination worth testing rather than rejecting automatically.

I have tested it. Screen reader users can already arrow through the links because of the virtual cursor (on Windows, but similar on Mac). Except changing those links to menu items removes the cues to screen reader users that they can still treat them as links — opening in a new tab, bookmarking, etc.

This is why the disclosure-based navigation pattern in APG, which I defined, also says adding arrow key support is an option. That pattern is permissive.

And, where arrow navigation is a deliberate and tested part of the experience, add menubar/menuitem semantics to inform AT users that the richer keyboard model is available.

Please don't.

APG is understandably conservative. Its patterns favor consistency […]

This is very much not true. APG was built to show off idealized ARIA patterns which recreate Windows95 paradigms. Many of the APG patterns had no support in browsers, and many introduced WCAG violations. This is the opposite of conservative. Its patterns favored Windows platform parity instead of actual support.

If menubar gives an AT user a useful hint […]

I think this is the crux of the misunderstanding. The only AT that exposes ARIA is screen readers (and Braille displays attached to them). With the exception of accessible name calculation, ARIA is hidden to other AT users. Especially keyboard-only users (which encompasses other AT like switch, sip-puff, wands, gaze, etc.), where so many APG patterns assert keyboard behaviors.

I appreciate that you're mulling variations on existing navigation patterns. But please don't speculate when you can build them and put them in front of users. I don't look forward to 10 more years of trying to get APG to listen to users that its menu navigation pattern is crap.