I’m trying to create an accessible menu that can be operated with the arrows, as described here:
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html
In the example once user has tabbed to menu, next tab moves him out of the menu. In other words user can't tab within the menu itself, only use arrows.
How widespread / discoverable is that? Or should menu retain “tabbing” functionality?
Section 5.1 of the WAI-ARIA Authoring Practices points out that (emphasis added)
ARIA roles, states, and properties model accessibility behaviors and features shared among GUI components of popular desktop GUIs, including Microsoft Windows, macOS, and GNOME. Similarly, ARIA design patterns borrow user expectations and keyboard conventions from those platforms, consistently incorporating common conventions with the aim of facilitating easy learning and efficient operation of keyboard interfaces across the web.
In other words, users should not need to learn one set of keyboard access conventions for desktop UI components and another set of keyboard conventions for web UI components. Using different keyboard access conventions for desktop and web would increase the burden on users, since they would need to remember two sets of conventions that partially conflict with each other, which would have a negative impact on usability.
The same section also points out that (my emphasis)
A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements. The path that the focus follows when pressing the tab key is known as the tab sequence or tab ring.
For this reason, the WAI-ARIA Authoring Practices describe keyboard interaction for menus that works like in a desktop GUI, except that the way a menu receives focus may differ (e.g. Alt + specific accelerator key for a menu works well on the desktop but not necessarily on a web application).
The roles used for menus (i.e. menu, menubar, menuitem, ...) tell assistive technologies what type of UI component they are dealing with. However, these roles need to be complemented with proper CSS styles and JavaScript event handlers in order to mimic keyboard behaviour for desktop-based GUIs.
An accessible menu and an operational menu are not mutually exclusive. Accessibility isn't tacked on after the fact. It's part of the DNA of the interface. If you are implementing a true menu (as opposed to a list of navigational elements, which are sometimes referred to as "menus" but they're not really application menus), then having the menu as one tab stop is the expected operation, and arrowing left/right to move to the next menu item is the expected operation. That behavior has been around since the 1980's.
Think of old school applications that had File, Edit, View, etc along the top of the application. Using the alt key (on a PC), I could move my keyboard focus to the menu. I could then arrow left/right to move to Edit, View, whatever. I could not tab to the other menu items.
If you use role="menu" and role="menuitem" when you implement your menu, the screen reader will announce that these items are menus and the user will expect to be able to use the arrow keys to navigate. The tab key will not be expected to navigate.
There should never be a disconnect between "standard functionality" and "accessible functionality". They are the same.
Now, regarding further details for a menu, see the menu role. In particular:
To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.
(their emphasis, not mine)
By "managing focus", they mean to allow the arrow keys to move the focus to the next menu item rather than using the tab key. (You don't have to "manage" the focus yourself when using the tab key. The browser does it for you.)
Making an accessible UI should not break the operational expectations of users who do not require the accessibility functionality. If you were not making this menu accessible, would tab functionality be expected/assumed and implemented? If so, it should remain implemented when you make it accessible.
If it's impossible to maintain the standard functionality because the accessible functionality actively conflicts with it, you need to make it clear, somehow, that the standard functionality is superseded by the accessibility functionality.
