Carbon menu specification – keyboard accessibility

Feature request part 1: Change to keyboard behaviour

Current behaviour

1. Tab order: Only the first menu instance is focused with the tab key. A subsequent tab takes the user to the next focusable item after the nav.
2. Right/left arrow keys: Moves focus to adjacent menus
3. Right/left arrow keys on menu item instance with submenu: Moves focus to next/previous item
4. Up arrow key on menu item instance with submenu: Opens submenu, places focus on the last item in the submenu
5. Down arrow key on bottom submenu item: Cycles focus to the top item
6. Up arrow key on top submenu item: Cycles focus to the bottom item

Desired behaviour

General behaviour

• Click/tap/enter/space or some positive action is required to open a top level menu instance
• Hover on a top level menu instance doesn’t trigger the submenu

Top level menu behaviour

1. Tab order:
   1. The first tab on the page after the ‘skip link’ (see suggested ‘Feature request part 2’, below) moves focus to the first menu instance
   2. Further tabs take the focus to each subsequent menu instance
   3. After the last menu instance, a further tab takes the user to the first focusable item of page content
   4. Shift-tab repeats the above in reverse
2. Right/left arrow keys: Have no effect
3. Up arrow key, Down arrow key, Space or Enter on menu item instance with submenu: Opens submenu, places focus on the first item in the submenu
4. Enter on a menu item instance should follow the link

Sub menu behaviour

1. When the submenu is opened, the first item should be focused
2. The tab key should follow the natural tab order of the submenu
3. Down arrow key on bottom submenu item: Focus stays at the bottom and doesn’t cycle. To get to the top item (from any item other than the top item) the user has to use the ↑ arrow key as many times as necessary, or press ⌘ + ↑ (or control + ↑ or Home on Windows)
4. Up arrow key on top submenu item: Focus stays at the top and doesn’t cycle. To get to the bottom item (from any item other than the bottom item) the user has to use the ↓ arrow key as many times as necessary, or press ⌘ + ↓ (or control + ↓ or End on Windows)
5. A subsequent tab from the last item in a submenu would
   • close the submenu
   • move focus to the next item in the tab index, whether top level item or content item on the page
6. Pressing shift + tab on the top sub menu item should close the submenu, putting focus on its parent menu instance
7. The esc key should close the submenu, putting focus on its parent menu instance.
8. Right/left arrow keys: Have no effect
9. Enter on a submenu item should follow the link

Keypress reference table

Menu

This is for top-level Menu items, whether they have a Submenu or not. Once a Submenu is open, the Submenu keyboard presses apply.

Key Function	Function
tab	Moves to next item
shift + tab	Moves to previous item
space	If item has Submenu, opens Submenu and moves focus to first item in the Submenu; if item doesn’t have Submenu (i.e. the item is a link), scrolls the page down one ‘frame’ (the normal space behaviour)
return	If item has Submenu, opens Submenu and moves focus to first item in the Submenu; if item doesn’t have Submenu (i.e. the item is a link), activates/follows link
→ (Right Arrow)	Has no effect
← (Left Arrow)	Has no effect
↓ (Down Arrow)	If item has Submenu, opens Submenu and moves focus to first item in the Submenu
↑ (Up Arrow)	If item has Submenu, opens Submenu and moves focus to first item in the Submenu

Submenu

This is for Submenu items. For the parent, top-level items, the Menu keyboard presses apply.

Key Function	Function
tab	Moves to next item in Submenu; when tabbing from the last item in the Submenu, the Submenu should close and focus placed on the next top-level Menu item, after the parent of the Submenu that was tabbed from
shift + tab	Moves to previous item in Submenu; when tabbing back from the first item in the Submenu, the Submenu should close and focus placed on the parent of the Submenu that was tabbed back from
return	Activates Submenu item, causing the link to be followed
space	scrolls the page down one ‘frame’ (the normal space behaviour)
esc (Escape)	Closes Submenu; moves focus to parent Menu item
→	Has no effect
←	Has no effect
↓	Moves down the items in the Submenu; when the last item has focussed, ↓ has no effect
↑	Moves up the items in the Submenu; when the first item has focussed, ↑ has no effect
Home command ↑ (control + ↑ on Windows)	Moves focus to first item in the Submenu
End or command + ↓ (control + ↓ on Windows)	Moves focus to last item in the Submenu
Character	Moves focus to the next item in the Submenu that that starts with the typed character; if none of the items have a name starting with the typed character, focus does not move
Subsequent character(s)	If multiple Submenu items begin with the same character or characters, focus moves to the first item that matches the keys pressed, so in a Submenu with ‘Black page’ and ‘Blue page’ as options, ordered alphabetically, <kbd>bl</kbd> would focus on ‘Black page’, and typing <kbd>blu</kbd> would move focus to ‘Blue page’

Suggested solution

See ‘Desired behaviour’, above.

Describe alternatives you’ve considered

n/a

Additional context

These changes are proposed after consultation with expert in accessibility Martin Underhill and @benwilsonsage.

Your environment

Live Carbon site: v54.1.1 Mac OS + Chrome, Mac OS + Safari

Behaviour as seen at: https://carbon.sage.com/?path=/story/design-system-menu--full-navbar-alignment-example

[tempertemper]

@jamime Yeah, I think this was instead of the table, as it quickly got very complex to the point of not-useful. It’s because this is essentially a component made up of multiple components, and in lots of combinations. I added a Gist to the description with a bare-bones example of the markup patterns to follow, which is hopefully more useful/practical. Let me know if more is needed though.

On the skip link front, a design has been put together by Craig Priestman I’ll DM you to check how best to deliver this, along with the markup and suggested show/hide styling.

[ian-forster]

Following the discussion, the actions are:

• @benwilsonsage to produce a design for the Skip Navigation link, and
• @tempertemper to include a table in the description with all Keys and Functions similar to the menubar description in the DLS site, and to generally review the description for accuracy and completeness.