Keyboard Navigation and WCAG 2.1: What Is Required, and How Do You Test It?

Who Depends on Keyboard Navigation?

Keyboard navigation is not just about users who prefer shortcuts. It is a fundamental prerequisite for access for three overlapping groups:

Users with motor disabilities cannot use a mouse due to limited fine motor control, paralysis, or tremors. They navigate exclusively via the keyboard — or via alternative input devices such as joysticks, eye-tracking systems, or sip-and-puff devices, all of which send keyboard events to the browser.

Screen reader users — blind and severely visually impaired users — use software such as NVDA, JAWS, or VoiceOver, which communicate exclusively through keyboard commands. If an element is not accessible via the keyboard, it simply does not exist for a screen reader.

Users with temporary limitations — a broken wrist, tendinitis, or a broken mouse — find themselves in the same position: dependent on the keyboard to get anything done.

Keyboard navigation is not an edge case. It is the prerequisite for assistive technologies to function at all.

The Four WCAG 2.1 Success Criteria for Keyboard

WCAG 2.1 contains four success criteria specifically addressing keyboard navigation. Two are Level A (the absolute minimum), one is Level AA (the legal requirement), and one is Level A but was introduced in WCAG 2.1 — and therefore new to many organisations.

2.1.1 Keyboard (Level A): All functionality available through a mouse or pointing device must also be operable via keyboard alone — without requiring specific timing patterns for individual keystrokes. The only exception is functions that inherently depend on the path of movement, not just the start and end points — such as freehand drawing. Text entry via handwriting recognition is not exempt: it is the text input that is required, not the path.

2.1.2 No Keyboard Trap (Level A): If keyboard focus can be moved to a component, it must also be possible to move it away using standard keyboard commands. If non-standard keys are required to exit a component, the user must be informed. Cookie banners, modal dialogues, and embedded map applications are frequent sources of keyboard traps.

2.1.4 Character Key Shortcuts (Level A, new in WCAG 2.1): Web applications that use single-character keyboard shortcuts — such as pressing “S” for search — must allow the user to either turn off the shortcut, remap it to require a modifier key (Ctrl, Alt, Shift), or make it inactive unless the relevant component has focus. The rationale is that screen readers and voice control software use single keys as commands themselves, and conflicts produce unpredictable behaviour.

2.4.7 Focus Visible (Level AA): Any component that can be operated via the keyboard must have a visible focus indicator — the visual marking that shows where keyboard focus currently is. This is the level mandated by law for public authorities in Denmark. A common failure is CSS rules such as outline: none or *:focus { outline: none }, which remove the browser’s default focus indicator without replacing it with an alternative. The focus indicator does not need to take any specific form, but must be visible and consistent.

Additionally, 2.4.3 Focus Order (Level A) requires that keyboard focus follows a logical and meaningful sequence — typically top to bottom, left to right. A page that appears visually correct but has a disordered DOM structure or uses positive tabindex values may fail this requirement.

The Key Keyboard Commands

To understand keyboard navigation in practice, it is useful to know the standardised commands users expect:

• Tab: Move focus forward to the next interactive element
• Shift+Tab: Move focus backward to the previous element
• Enter: Activates links and buttons
• Space: Activates buttons, toggles checkboxes and radio buttons
• Arrow keys: Navigate within dropdown menus, radio buttons, sliders, and tab panels
• Escape: Closes modal dialogues, overlays, and expanded navigation menus
• Home/End: Navigate to the start or end of lists

These commands are part of the expected behaviour for well-structured HTML. Native HTML elements such as <button>, <a>, <input>, and <select> support them automatically. It is primarily custom components built on <div> or <span> elements with JavaScript event handlers that most commonly fail.

Common Failures in Practice

A review of accessibility statements and supervisory reports reveals that the same types of failure recur on public sector websites:

Focus indicator removed or invisible — Many design systems and CSS resets remove the outline style globally to avoid visual “noise”. The result is that keyboard users cannot see which element is currently active.

Keyboard traps in modal dialogues — A modal opens, but focus is not correctly contained within it. The user can tab out of the dialogue, click the background, and lose context — or conversely is locked inside and cannot close the dialogue with Escape.

Custom components without keyboard support — An accordion, tab navigation, or dropdown built on <div> elements with only onclick handlers works with a mouse but is invisible to keyboard navigation. The element receives no focus and cannot be activated.

Skip navigation link missing — Users navigating by keyboard must Tab through every navigation element on a page before reaching the main content. A “Skip to content” link, placed as the first element in the code and visible on focus, solves this — but it is absent from many public sector websites.

How to Test Keyboard Navigation

Automated testing tools can identify some keyboard navigation failures — such as interactive elements lacking tabindex or focus indicators with insufficient contrast. But they cannot simulate real keyboard navigation or verify that complex interaction patterns work correctly. Manual testing is essential.

The basic manual test is carried out by setting the mouse aside and working through the website using only the keyboard:

• Tab through all pages and verify that all interactive elements are reachable and that focus is always visible
• Use Shift+Tab to navigate backwards and check that the order is coherent
• Test that Enter and Space activate all buttons and links as expected
• Open and close all modal dialogues, dropdown menus, and accordions — and verify that focus is handled correctly when they open and close
• Complete and submit all forms using only the keyboard
• Verify that focus returns to a logical position after a dialogue closes

Supplement manual testing with automated scanners such as axe DevTools or WAVE, which can identify structural issues such as missing focus styles and incorrect tabindex values.

Keyboard Navigation in PDF Documents

A particular problem arises with PDF documents that are the only means of accessing information. A tagged PDF can in principle be navigated by keyboard in Adobe Acrobat Reader — but the navigation experience is far more complex and unpredictable than in well-structured HTML.

When a PDF document is converted to semantic HTML, it inherits all the native keyboard navigation properties that the browser provides: logical tab order, visible focus indicators, and standard keyboard commands. This is one of the reasons why converting PDF documents to HTML — for example using PDFAccess — delivers a markedly better keyboard navigation experience than even a well-tagged PDF/UA document.

Checklist: Keyboard Navigation

• All interactive elements are reachable via the Tab key
• Focus indicator is visible on all interactive elements — outline: none is not used without an alternative
• Tab order follows a logical visual sequence
• No keyboard traps: focus can always be moved away from any element
• Modal dialogues correctly contain focus and can be closed with Escape
• Focus returns to a logical element after a dialogue closes
• A “Skip to content” link is available as the first focusable element
• Single-character shortcuts can be turned off or remapped (WCAG 2.1.4)
• All forms can be completed and submitted using only the keyboard