Is there a standard for keyboard activation of drop-down menus? We are using multiple drop-down menus from various sources which behave differently from one another. Technically speaking, each individual jump menu is WCAG 2.0 AA accessible because it can be navigated keyboard-only, but the technique for opening the menu varies from menu to menu.
I can't imagine that to be a pleasant experience for site visitors, but I also can't seem to find documentation from an authoritative source for a standard menu-open behavior that could (theoretically) be applied across all drop-down menus.
Is there a standard? Where is it documented? If there is no standard, is there a way to force a single behavior across incompatible drop-downs or else enable forgiving actions? If not, is there a reasonable way, e.g., through appropriate ARIA labeling, to communicate the correct way to access a particular drop-down menu without forcing the site visitor to figure it out for themselves?
I despair of keyboard-only visitors being able to achieve mastery of drop-down menus on websites.
Details follow:
We have multiple drop-down menus throughout our website. They exhibit different behaviors from one another:
We have a Quick Links menu which implements the Drupal Better Jump Menu module:
Steps to open the menu:
1. Go to https://www.sfmta.com/about-sfmta
2. Tab until QuickLinks is highlighted (note: for some reason, doesn't seem to highlight in Firefox, although it highlights just fine in Safari, Chrome, Edge.
3. Potential options to open (choose one):
a. Down arrow (opens menu)
b. Press space, then page up to bring open menu into view (space opens menu but also scrolls the page)
c. Press Enter (doesn't do anything)
4. Once the menu is open, you can navigate it using the down and up arrow keys; you can close it with the Escape key or one or more presses of the up arrow key. If an item is selected, pressing Enter activates that item (goes to another web page).
We also have the Google Translate widget
Steps to open the menu:
1. Go to https://www.sfmta.com/about-sfmta
2. Tab until QuickLinks is highlighted (note: for some reason, doesn't seem to highlight in Firefox, although it highlights just fine in Safari, Chrome, Edge.
3. Potential options to open (choose one):
a. Down arrow (doesn't do anything)
b. Press space (doesn't do anything)
c. Press Enter (opens menu)
4. Once the menu is open, you can navigate it using the tab and shift-tab keys; you can close it by tabbing or back-tabbing out of it at the cost of losing your place on the page. If an item is selected, pressing Enter activates that item (translates the page into the selected language).
We also have a FormAssembly form with a drop-down:
- Go to https://www.sfmta.com/munimobile-help
- Tab until Please select... is highlighted
- Potential options to open (choose one):
a. Down arrow (opens menu)
b. Press space (opens menu)
c. Press Enter (doesn't do anything) - Once the menu is open, you can navigate it using the down and up arrow keys; you can close it with the Escape key or one or more presses of the up arrow key. If an item is selected, pressing Enter retains that item and closes the menu without submitting the page.
Another third party form is on another website (so I'm not going to link to it) but behaves as follows:
- Go to the third-party site
- Tab until "-- Please select --". is highlighted
- Potential options to open (choose one):
a. Down arrow (displays first item in menu without opening the menu)
b. Press space (scrolls page; has no effect on menu)
c. Press Enter (moves cursor to the end of the words "-- Please select --") - You can navigate the menu using the down and up arrow keys; you can leave it using the Tab key. If an item is selected, pressing Tab retains that item and moves to the next field.
So, as you can see there is a broad range of slightly or significantly different behaviors, all potentially being displayed to a site visitor on the same site visit. (They do cover different needs, so the odds are not likely, but still...)
The closest I can get to an authoritative recommendation are:
W3 ARIA's Collapsible Dropdown Listbox Example https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collap... which suggests using Enter to expand the menu (as the Google menu does) and up and down arrow to navigate to a menu selection (as the non-Google menus do).
and in:
WAI-ARIA Authoring Practices 1.1
W3C Working Group Note 14 August 2019
3.14 Listbox
Keyboard Interaction
https://www.w3.org/TR/wai-aria-practices/#listbox_kbd_interaction
it recommends opening the list as soon as focus is achieved and then using up and down arrow to navigate.
But neither document seems to be an official recommendation.
Thoughts?
Comments
More W3C design patterns to consider
Charles, I agree that these sorts of widgets should have more consistent interfaces. The MuniMobile Help form is different than your first two examples - that's just a standard HTML
<select>element, and the keyboard model is standard for that field type.Regarding the Quick Links and Google language widgets, I think you're right to consult the WAI-ARIA Authoring Practices looking for applicable design patterns, but there are a couple of other design patterns that I think might be a better fit:
The difference between the two is subtle: The Disclosure design pattern is arguably better a list of web links, whereas the Menu (or Menubutton) design pattern is arguably better for a list of functions (i.e., to change the language of the current page).
The design patterns in the WAI-ARIA Authoring Practices aren't official standards, they're just examples, but they're intended to guide how we build such widgets. I think if you compare them all, you'll see commonalities:
In addition to the keyboard model, note the ARIA markup that's being used. For example, both of the above design patterns use aria-expanded on the button to communicate the current state of the dropdown. Neither the Quick Links nor Google Language widget are using that currently.