Keyboard accessibility test: a 5-minute check

W3C's Easy Checks notes that many people cannot use a mouse and rely on the keyboard. Tools that stand in for a keyboard, such as speech input software and on-screen keyboards, feed the same keyboard interface (W3C's note on 2.1.1), so a page that cannot be operated from the keyboard is out of reach for them too. This is a manual test. None of GotAlt's checks presses keys, and a page with a clean scan can still be unusable from the keyboard.

The routine below checks eight things in about five minutes on one page. Run it on each template and each distinct component, not on every page.

Before you start

• Keys. Tab moves forward and Shift+Tab backward. Enter activates links and buttons, and Space activates buttons. Arrow keys move within radio groups, drop-down lists and menus, and Escape closes dialogs (WebAIM's keyboard guide lists these keys, including Esc to close. W3C Easy Checks lists Tab, Shift-Tab, the arrow keys, Enter and Space.)
• Start at the top. Reload the page, click in the address bar, then put the mouse aside and leave it alone. Browser toolbar buttons may take a few presses of Tab before focus enters the page.
• On a Mac in Safari, Tab highlights only form fields and pop-up menus by default. Option-Tab also reaches links, and both reach buttons and other controls when Keyboard Navigation is on in Keyboard settings. The "Press Tab to highlight each item on a webpage" setting in Safari's Advanced pane swaps the two behaviors (Apple's Safari shortcuts page). Easy Checks also tells Mac users to enable keyboard navigation for all controls.
• Keep a log. Write down the page, the step, the element (by its visible text) and what happened. The table below is a layout you can copy.

The 5-minute check at a glance

The times are our estimates for a page with a handful of widgets; a busy page takes longer. The criteria reference lists every criterion above in context.

Passing these eight checks does not show that a page meets WCAG or any law. W3C describes its own Easy Checks as quick and easy, rather than definitive, and this routine is the same kind of check.

Step by step

1. Skip link (about 30 seconds)

Press Tab until focus enters the page. The first stop should be a "Skip to content" link, which may stay hidden until it has focus. Press Enter and then Tab again: focus should land in the main content, not back in the header. Success criterion 2.4.1 Bypass Blocks asks for a mechanism to bypass blocks repeated across pages, and W3C's technique G1 is a link at the top that goes to the main content. Our criteria reference notes that landmark regions or headings can also serve, but a skip link is the usual aid for someone tabbing. A skip link that exists but does nothing is a common fault: the February 2026 WebAIM Million reports that 17.1% of home pages had a "skip" link and that one out of every ten skip links was broken, so press Enter on yours and confirm focus moves.

2. Tab through the page and back (about 90 seconds)

Keep pressing Tab, then Shift+Tab to return, and look for these:

• Everything you can click can be reached, including links, form fields, buttons, media player controls, carousel arrows and the buttons in a cookie banner. Something that looks clickable but never takes focus, such as a div with a click handler, fails 2.1.1 Keyboard when there is no other keyboard way to do the same thing, because that criterion requires all functionality to be operable through a keyboard interface.
• The order makes sense. Success criterion 2.4.3 Focus Order asks that focusable components receive focus in an order that preserves meaning and operability. W3C notes that focus order need not match the visual layout exactly, and calls it a failure when the order impedes meaning or operation. Focus that jumps to the footer and back, or that reaches a form's submit button before its fields, is the kind of thing to log.
• The page does not reorder tabbing with tabindex. MDN recommends using only 0 and -1 as tabindex values and avoiding values above 0, and WebAIM says not to use values of 1 or greater. MDN also warns against CSS properties that can change the order of focusable elements, such as ordering flex items, so when Tab order and visual order disagree, look at the CSS as well as the HTML. The free scan flags any positive tabindex.

3. Visible focus (during step 2)

At every stop, can you see where focus is? Success criterion 2.4.7 Focus Visible (Level AA) requires a mode of operation where the keyboard focus indicator is visible. The usual cause of failure is a style that removes the browser's default ring: W3C lists F78 for styling outlines and borders so the indicator disappears, and WebAIM advises avoiding outline: none and outline: 0. Browsers may show the ring only when a keyboard is in use, so do not be surprised that clicking shows none. Check dark areas, photos and custom buttons, where a thin ring can vanish. If you style the indicator yourself, our color contrast guide covers the 3:1 requirement for it.

4. Focus not obscured (about 30 seconds)

Tab to elements near the top and bottom edges while a sticky header, sticky footer, cookie banner or chat panel is on screen. Success criterion 2.4.11 (Level AA, new in WCAG 2.2) says a component receiving keyboard focus must not be entirely hidden by author-created content. W3C names sticky headers, sticky footers and non-modal dialogs as typical culprits, and says a cookie banner fails if it entirely obscures the focused item. Content the user opened, such as a chat window, may cover the item, provided the user can reveal it without moving focus. Sticky bars take a bigger share of a small viewport, so repeat this step at a narrow width and at 200% zoom. Level AAA 2.4.12 goes further and allows no part to be hidden. See what's new in WCAG 2.2 for the other additions.

5. Keyboard traps (about 30 seconds)

Tab into every embedded thing and try to Tab out: video players, maps, rich text editors, iframes, date pickers and chat widgets. Success criterion 2.1.2 No Keyboard Trap says that if focus can move into a component with the keyboard, it can move away using only the keyboard. If leaving needs more than unmodified arrow or Tab keys or other standard exit methods, the user must be told how. W3C calls Escape a commonly used standard exit method. A trap is easy to spot: you simply stop being able to move on.

6. Menus and dialogs (about 60 seconds)

Open every menu, dialog, accordion and pop-up with Enter or Space, not the mouse. A menu that opens only on hover cannot be used from the keyboard, which in our reading fails 2.1.1. For a modal dialog, W3C's ARIA Authoring Practices pattern describes the expected behavior:

• Focus moves into the dialog when it opens.
• Tab and Shift+Tab move through the controls in the dialog and wrap from the last to the first, and from the first to the last.
• Escape closes it.
• When it closes, focus returns to the element that opened it, unless that element no longer exists or another target is more logical.

Focus that stays inside an open modal is intended, not a trap, because Escape closes the dialog. Inside a menu bar or drop-down list, arrow keys move between items, as Easy Checks describes.

7. Custom widgets (about 45 seconds)

Native links, buttons, inputs and select lists bring keyboard behavior with them. Widgets built from divs need script to match, so try every tab set, accordion, slider, carousel, custom drop-down and date picker. The ARIA Authoring Practices guide to developing a keyboard interface says Tab and Shift+Tab move focus from one component to another, while arrow keys move focus inside a component that holds several focusable elements, and that the Tab sequence should include only one focusable element of such a component. The tabs pattern applies that rule: Tab moves focus into the tab list on the active tab, Tab again moves on to the next element outside the list, and the Left and Right Arrow keys move focus between the tabs. Drag and drop must work from the keyboard too (2.1.1), and 2.5.7 Dragging Movements separately asks for a single-pointer alternative to dragging. Keyboard operation is only half of a custom control: 4.1.2 Name, Role, Value also needs its name, role and state exposed to assistive technology, which takes a screen reader to check.

8. Single-character shortcuts (about 15 seconds)

This applies only if the page defines shortcuts that use a single letter, number, punctuation or symbol key, as web apps often do. With focus on the page and not in a text field, press a few letters. If something happens, success criterion 2.1.4 Character Key Shortcuts (Level A) needs at least one of three things to be true: you can turn the shortcut off, you can remap it to include a non-printable key such as Ctrl or Alt, or it is active only while its component has focus. W3C gives the reasons: speech input users whose dictation can arrive as a string of letters, and keyboard users who press keys by accident.

After the test

Turn the log into a fix list. The fixes that recur are short:

• Use native elements, such as button and a, in place of clickable divs.
• Remove outline: none, or replace it with a visible style.
• Delete positive tabindex values and fix the source order instead.
• Add a skip link, and manage focus in dialogs as the pattern above describes.
• Make every hover-only function work on focus and from the keyboard.

A dated record of what you tested and found can feed your accessibility statement and is the kind of documented testing an accessibility conformance report draws on (see our VPAT and ACR guide), but a 5-minute check is a starting point for either, not a complete evaluation. For the zoom, screen reader and form checks that sit beside this one, use how to test website accessibility, and for a deeper review across a whole site see website accessibility audits.

What GotAlt's scan checks, and what it cannot

The free scan reads the HTML your server sends. Two of its 16 rule-based checks relate to keyboard focus. Everything else in this test needs a person, because it needs a browser that renders the page and real key presses. What we check sets out the limits, and why scanners miss issues covers the wider picture.

The methodology page explains why: finding a trap means pressing Tab repeatedly in a real browser, and where focus lands and whether an outline is visible depend on computed styles and layout, which a markup parser never produces. The accessibility bookmarklet checks the rendered page, but its own limits list says it cannot tell whether a page works with a keyboard. None of GotAlt's checks presses keys.