Keyboard Accessibility Testing

Who depends on the keyboard and which criteria apply

Many people never use a mouse: blind users navigate with a screen reader driven from the keyboard; people with tremors or limited hand movement use a keyboard, a switch device or voice control that emulates keystrokes; others simply prefer it. On phones and tablets, external keyboards and switch access use the same focus model. If something cannot be reached by keyboard, all of these users are locked out of it.

These WCAG 2.2 success criteria are the core of a keyboard test:

• 2.1.1 Keyboard (A) — all functionality is operable through a keyboard interface without requiring specific timings for individual keystrokes (freehand drawing and similar path-dependent input are the exception).
• 2.1.2 No Keyboard Trap (A) — if focus can move into a component with the keyboard, it can move out with the keyboard; if a non-standard key is needed, the user is told which.
• 2.1.4 Character Key Shortcuts (A) — single-character shortcuts can be turned off or remapped, or only work while the relevant component has focus.
• 2.4.1 Bypass Blocks (A) — there is a mechanism to skip blocks repeated on many pages, such as a skip link.
• 2.4.3 Focus Order (A) — focus moves in an order that preserves meaning and operability.
• 2.4.7 Focus Visible (AA) — keyboard focus has a visible indicator.
• 2.4.11 Focus Not Obscured (Minimum) (AA) — a focused component is not entirely hidden by author-created content such as sticky headers or banners.
• 3.2.1 On Focus (A) — receiving focus does not by itself cause a change of context.
• Related: 1.4.13 Content on Hover or Focus (AA) for tooltips and popovers, and the AAA criteria 2.1.3 Keyboard (No Exception), 2.4.12 Focus Not Obscured (Enhanced) and 2.4.13 Focus Appearance.

How to run a keyboard test session

Put the mouse out of reach and start with focus in the browser address bar, so the first Tab lands on the first element of the page. Work through the page in both directions and operate every control. The keys you need:

• Tab and Shift+Tab — move to the next and previous focusable element.
• Enter — activate links and buttons, submit forms. Space — activate buttons, toggle checkboxes, open some selects.
• Arrow keys — move within composite widgets: radio groups, tabs, menus, listboxes, sliders, grids.
• Escape — close dialogs, menus, popovers and tooltips.
• Home, End, Page Up, Page Down — jump within lists, sliders and long widgets where the pattern defines them.

Focus order, visible focus and focus not obscured

Focus order should follow the reading order of the layout: in a left-to-right page from top-left to bottom-right, in an Arabic right-to-left page from the top right. Order breaks when the DOM order differs from the visual order (CSS grid or flex reordering, absolutely positioned panels) or when authors use positive tabindex values, which pull elements ahead of everything else. tabindex="0" adds a custom control to the natural order and tabindex="-1" makes an element focusable by script only; positive values are almost always a defect.

The focus indicator must be visible on every focusable element and against every background it sits on. The most common cause of failure is a global "outline: none" with no replacement style. Check links inside text, buttons in coloured banners, cards, and inputs inside dark footers. WCAG 2.2 AA requires only that an indicator is visible; the AAA criterion 2.4.13 Focus Appearance adds size and contrast requirements that make a good design target.

Finally, check that focus is never entirely hidden. Sticky headers and footers, cookie banners, chat launchers and bottom sheets often cover the focused element as the page scrolls, which fails 2.4.11 Focus Not Obscured (Minimum). Tab through long pages with every sticky element present, including at 200% zoom where they cover more of the viewport.

Keyboard traps and bypass blocks

A keyboard trap is any place focus can enter but not leave. Typical suspects are embedded third-party content in iframes (maps, video players, payment fields), rich-text editors that capture Tab to insert indentation, custom date pickers, and focus-management scripts in dialogs that keep pulling focus back after the dialog is closed. Test each by tabbing in, then trying Tab, Shift+Tab and Escape to get out. If leaving requires something unusual, the component must tell the user how.

Bypass blocks is about effort, not possibility. If a keyboard user must press Tab forty times to get past the navigation on every page, the page may be operable but it is not usable. WCAG 2.4.1 requires a mechanism to skip repeated blocks. A "Skip to main content" link as the first focusable element is the most direct one for keyboard users; landmarks and headings also serve screen reader users. Verify that the skip link becomes visible when focused, and that activating it actually moves focus — not just the scroll position — so the next Tab goes to the first control in the main content.

Custom widgets and the expected key patterns

Native HTML controls — button, a with href, input, select, textarea, details — come with keyboard behaviour built in. Custom widgets built from div and span elements have none until developers add it, and ARIA roles do not add it either. The W3C ARIA Authoring Practices Guide (APG) documents the keyboard interaction users expect for each common pattern; use it as the expected result in your test cases. In composite widgets the whole widget is usually one Tab stop and arrow keys move inside it.

• Button — Enter and Space activate. A div that responds only to click fails.
• Checkbox — Space toggles. Radio group — Tab enters the group at the checked option; arrow keys move and select.
• Tabs — Tab moves into the tab list to the active tab; Left and Right arrows move between tabs; Tab again moves into the panel.
• Menu button — Enter or Space opens the menu and focuses the first item (Down Arrow may also open it); arrows move; Escape closes and returns focus to the button.
• Combobox and listbox — Down Arrow opens or moves through options; Enter selects; Escape closes the popup.
• Slider — arrow keys change the value by a step; Home and End go to the minimum and maximum.
• Right-to-left layouts — APG assigns the horizontal arrow keys (Right Arrow for the next tab or a higher slider value) without addressing right-to-left layouts, so it gives no separate RTL rule. In a mirrored Arabic layout, the expected result this topic uses (see the accessibility testing pillar and the RTL testing guide) is that horizontal arrows follow the visual direction: the next tab sits to the left, so Left Arrow moves to it, and on a slider mirrored so that its minimum is on the right, Left Arrow increases the value. Up and Down Arrow, Home and End keep their meaning. Record the rule in the design specification and check that every widget applies it the same way.
• Disclosure and accordion — Enter or Space expands and collapses the section.
• Dialog (modal) — Tab and Shift+Tab stay inside the dialog; Escape closes it.

Modal dialogs, menus and dynamic content

Focus management is where most single-page applications fail. When a modal dialog opens, focus must move into it — to the first field, the first actionable element, or the dialog heading for long content. While it is open, Tab must cycle inside the dialog and the page behind must not be reachable. When it closes, focus should return to the element that opened it, so the user continues where they were. The native dialog element opened with showModal() handles much of this; custom dialogs must do it in script.

Apply the same rule to every change the user triggers: after deleting a row, focus should move to a neighbouring row or a status message, not fall back to the top of the document; after a client-side route change, focus should move to the new page’s heading or main region; menus and popovers opened by keyboard should close with Escape and return focus to their trigger. Content that appears on hover must also appear on keyboard focus and be dismissible without moving focus (1.4.13 Content on Hover or Focus).

Keyboard test cases

Run these for every page type and every complete process in scope. Each line is a test case with its expected result; record failures with the success criterion.

KB-01  First Tab from the address bar lands on a skip link that becomes visible on focus
KB-02  Activating the skip link moves focus to main; next Tab reaches the first control in main
KB-03  Tab reaches every interactive element; nothing non-interactive is a Tab stop
KB-04  Shift+Tab reverses the order exactly
KB-05  Focus order matches the reading order (check LTR and RTL layouts)
KB-06  Focus indicator visible on every stop, on every background
KB-07  No focused element is fully hidden by sticky header, footer, cookie banner or chat widget
KB-08  Buttons activate with Enter and Space; links with Enter
KB-09  Custom widgets follow APG keys (tabs: arrows; menu: Enter/Space, Esc; slider: arrows, Home/End)
KB-10  Modal: focus moves in on open, Tab cycles inside, Esc closes, focus returns to the trigger
KB-11  No trap: focus can leave every widget, iframe, video player and editor
KB-12  Tooltips and popovers shown on hover also show on focus and close with Esc
KB-13  Focus alone never submits, navigates or changes context
KB-14  Single-key shortcuts can be turned off or remapped, or work only when the component has focus
KB-15  After delete, add or route change, focus lands on a sensible element, not the document body
KB-16  Each complete process (e.g. checkout) can be finished with the keyboard only

Try it: AI QA Checklist Generator Try it: Test Case Generator

Defect examples

Written as bug titles, with the criterion each one fails. State the browser, the exact key sequence and where focus ended up in the report.

• "Date picker cannot be operated with arrow keys; a date can only be chosen with the mouse" — 2.1.1 Keyboard.
• "Custom Accept terms checkbox (div) does not toggle with Space" — 2.1.1 Keyboard.
• "Tab focus gets stuck inside the embedded map iframe on the Branches page" — 2.1.2 No Keyboard Trap.
• "No skip link or landmarks; 42 Tab presses needed to reach the search results" — 2.4.1 Bypass Blocks.
• "Positive tabindex on the newsletter field sends the first Tab to the footer, ahead of the skip link and header" — 2.4.3 Focus Order.
• "Focus moves to the document start after closing the Filters drawer" — 2.4.3 Focus Order.
• "Focus ring removed on all links (outline: 0) with no replacement" — 2.4.7 Focus Visible.
• "Sticky cookie banner covers the focused Pay now button at 200% zoom" — 2.4.11 Focus Not Obscured (Minimum).
• "Focusing the language selector immediately reloads the page in Arabic" — 3.2.1 On Focus.

Try it: AI Bug Title Generator

What you can automate

Rule engines catch some keyboard-related problems statically — positive tabindex, interactive roles that are not focusable, scrollable regions with no keyboard access — but they cannot judge order or visibility. Browser automation fills part of the gap: a Playwright, Cypress or Selenium test can press keys and assert which element has focus, which makes focus-management regressions in dialogs and route changes cheap to catch. Keep the manual pass for order, visibility and obscured focus, which need eyes.

test("edit address dialog returns focus to its trigger", async ({ page }) => {
  await page.goto("/account/addresses");
  const edit = page.getByRole("button", { name: "Edit address" });
  await edit.focus();
  await page.keyboard.press("Enter");
  await expect(page.getByRole("dialog", { name: "Edit address" })).toBeVisible();
  await expect(page.getByRole("textbox", { name: "Street" })).toBeFocused();
  await page.keyboard.press("Escape");
  await expect(page.getByRole("dialog")).toBeHidden();
  await expect(edit).toBeFocused();
});

Frequently asked questions

References

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)The informative explanation of each WCAG 2.2 guideline and success criterion: intent, who benefits, examples and techniques (not normative).
• ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)Patterns for common widgets (tabs, menus, dialogs, comboboxes) with the expected keyboard interaction and ARIA usage — the reference testers compare custom components against.
• Easy Checks – A First Review of Web AccessibilityW3C Web Accessibility Initiative (WAI)Simple first checks anyone can run — page title, text alternatives, headings, contrast, text resize, keyboard access — before a full evaluation.
• Accessibility — MDNMDN Web Docs (Mozilla)Practical guides to building and checking accessible web pages: semantic HTML, ARIA, keyboard support and testing.
• Playwright DocumentationMicrosoft (Playwright)Official documentation for Playwright, an end-to-end test framework that drives Chromium, WebKit and Firefox.