This is part 3 of the Accessibility Testing series. It covers how to test that every interactive element on your page is reachable and usable with a keyboard alone.

macOS users: Keyboard navigation is NOT enabled by default. Your test results will be inaccurate if you don’t enable it:

1. System Settings → Keyboard → turn on Keyboard navigation
2. Safari only: Safari → Settings → Advanced → turn on Press Tab to highlight each item on a webpage

Key WCAG criteria

• 2.1.1 Keyboard — all functionality must be operable via keyboard
• 2.1.2 No Keyboard Trap — users must be able to navigate away from any component
• 2.4.1 Bypass Blocks — provide a way to skip repeated navigation (skip links)
• 2.4.3 Focus Order — focus order must be logical and match visual layout
• 2.4.7 Focus Visible — focused elements must have a visible indicator

Standard keyboard interactions

Key	Action
Tab	Move focus to next interactive element
Shift + Tab	Move focus to previous interactive element
Enter	Activate links and buttons, submit forms
Space	Activate buttons, toggle checkboxes
Arrow Keys	Navigate within composite widgets (tabs, menus, radio groups)
Escape	Close/dismiss modals, dropdowns, tooltips, menus
Home / End	Jump to first/last item in a list or menu

Although WCAG doesn’t explicitly require Enter or Space for activation, it recommends that custom controls mimic native keyboard behavior to meet user expectations — otherwise, you must supply clear instructions.

Tip: Search for “Keyboard interactions” in the MDN ARIA role documentation to find the official keyboard pattern for any role.

How to test

Put your mouse aside and navigate the page using only the keyboard. As you go, check:

• Skip link works — press Tab once on a fresh page load. A “Skip to main content” link should appear. Pressing Enter should move focus past the navigation.
• All interactive elements are reachable — can you Tab to every link, button, input, and control?
• Focus order is logical — does focus move in a sequence that matches the visual layout? No unexpected jumps?
• Focus indicator is visible — can you always tell which element has focus? The indicator should be clearly visible, not just a subtle color change.
• No keyboard traps — can you navigate in and out of every component? (Modals are an intentional exception — see below.)
• Hidden content is not focusable — elements that are visually hidden (display: none, visibility: hidden, hidden attribute, or inside a closed <details>) should not receive focus.
• All actions are possible — can you open menus, close dropdowns, submit forms, dismiss notifications, and interact with every feature without a mouse?

tabindex pitfalls

A common source of keyboard issues:

• tabindex="0" — adds an element to the natural tab order. Use this for custom interactive elements that aren’t natively focusable.
• tabindex="-1" — removes from tab order but allows programmatic focus (e.g., element.focus()). Useful for elements that should receive focus only via scripts.
• tabindex > 0 — avoid this. It overrides the natural DOM order and creates unpredictable navigation for keyboard users.

Common patterns to test

Modals and dialogs

Modals require special attention. When open, focus must be trapped inside — users should not be able to Tab past the modal to the page behind it.

1. Open the modal with the keyboard
   • Focus moves into the modal
2. Tab through all elements in the modal
   • Focus stays trapped inside the modal
3. Close the modal with Escape or a close button
   • Focus returns to the element that opened it

The native HTML <dialog> element with showModal() handles focus trapping automatically and is the recommended approach over custom implementations.

Dropdown menus

• Enter or Space opens the menu
• Arrow Keys move between menu items
• Escape closes the menu and returns focus to the trigger
• Tab from the last item closes the menu

Tab panels

• Tab moves focus to the active tab
• Arrow Keys move between tabs
• Tab from a tab moves focus into the tab panel content

Accordions

• Enter or Space expands/collapses a section
• Content inside a collapsed section is not focusable

See also: Assistive technology testing