Checklist for Accessible Keyboard Navigation

1. Fundamental Principles of Keyboard Navigation

Test your website journeys without a mouse: open a menu, complete a form and close a dialog. It enables people who use assistive technologies—such as screen readers, switch devices, or alternative keyboards—to interact fully with online services without relying on a mouse.

Functionality must be operable with a keyboard, except when the function depends on the path of a movement, such as freehand drawing. Basic interactions follow established conventions described in the W3C ARIA Authoring Practices Guide (APG): the Tab key moves focus forward to the next element in the tab sequence, Shift + Tab moves focus backward, the Enter key activates links and buttons, and the Spacebar activates buttons and checkboxes. Composite widgets such as tabs or menus also use arrow keys according to their interaction pattern.

Using native HTML elements such as <button> or <a href="..."> is the preferred starting point. Native elements include built-in focus handling and keyboard event support. When building a custom interactive control with JavaScript (such as a custom button using a <div> element), developers must explicitly assign tabindex="0" to place it in the document's natural focus order define its accessible role and name, then implement activation with Enter and Space without unintended page scrolling.

2. Focus Order and Indicator Visibility

Navigation order must match the logical and visual flow of the page, typically left-to-right and top-to-bottom. This order is defined by the HTML Document Object Model (DOM) structure. Using positive values for the tabindex attribute (greater than 0) should be avoided, as it alters the natural navigation sequence and leads to unpredictable behavior.

Regarding visual focus indicators, the WCAG 2.1 and WCAG 2.2 recommendations define specific requirements. Success Criterion 2.4.7 (Focus Visible) at Level AA requires focus indicators to be clearly discernible, without imposing a universal 4.5:1 contrast requirement for all focus indicators in WCAG 2.1 (Criterion 1.4.11 specifies 3:1 for visual information needed to identify components and states, with exceptions including inactive controls and unmodified browser styling). In WCAG 2.2, Criterion 2.4.13 (Focus Appearance) introduces stricter area and contrast metrics, but this criterion is classified at Level AAA. Minimum Level AA visibility requirements should not be confused with advanced Level AAA criteria.

Additionally, WCAG 2.2 introduced Success Criterion 2.4.11 Focus Not Obscured (Minimum) at Level AA. This criterion requires that when a component receives keyboard focus, it is not entirely hidden by author-created content, such as a sticky header, sticky footer, or cookie banner. Settings such as scroll-padding can help; test the result with sticky headers and at different zoom levels.

3. Modal Dialogs and Preventing Keyboard Traps

A keyboard trap (WCAG Criterion 2.1.2) occurs when a user navigates into a component but cannot navigate away using standard keyboard keys. These traps frequently occur in complex custom widgets or poorly structured third-party scripts.

When opening a modal dialog, focus management must adapt to the interaction context:

On opening, place focus on a suitable element inside: a control or a heading with tabindex="-1" depending on the content. Do not always choose the first button.

While the modal is open, keep the tab sequence inside and support closing with Escape and an accessible button. This containment is not a keyboard trap if the user can close the dialog.

On closing, return focus to the trigger or a logical next step if the trigger has disappeared or the completed action justifies it.

The W3C modal dialog pattern explains these choices.

4. A checklist for testing your journeys

Prepare the test

Choose real tasks: find information, select an option and send an enquiry. Record the browser, operating system and pages tested. First complete a keyboard pass with no screen reader running, then a separate screen reader pass to check announced names and states.

Reach each useful control with Tab or the keys expected for that component.

Check backward navigation with Shift + Tab and look for inconsistent focus changes.

Open menus and dialogs, select an option and close them.

Trigger a form error: find its message and correct the field.

Repeat with a sticky header, an open banner and a zoomed page.

For each obstacle, record the action, expected result and what you observe. A screenshot and reproduction steps help the developer fix the right component.

Fictional example

In a booking form, a visitor opens a calendar but cannot leave it. Test date selection, closing and the return to the field. After fixing the issue, check other pages using the calendar. This example describes a problem to test without claiming a measured conversion gain.

5. Use tools alongside manual tests

Axe, Lighthouse or WAVE can flag some errors. A report with no alerts does not prove that a journey works with a keyboard. Check the interactions and screen reader announcements. Include useful checks in your updates and retest fixes.

Choose a standard and its scope according to your organisation. Our accessibility guide for Switzerland distinguishes WCAG, eCH-0059 and applicable requirements. Assign someone to these checks now and reuse the checklist when adding components.