Plenty of people never touch a mouse. Some are blind and use a screen reader, some have tremors or limited hand movement and use a keyboard or a switch device, some simply work faster that way. If your site cannot be used from the keyboard alone, none of them can book, buy or get in touch.
A keyboard accessibility test is the cheapest serious check you can run. It needs no software and no budget, only a clear idea of which keys do what. It does need patience and a way of writing things down, and that is what this post gives you.
What each key is supposed to do
Before testing, it helps to know what “working” looks like. These are the conventions keyboard users expect, and the ones WCAG 2.1.1 Keyboard is really about.
| Key | Expected behavior |
|---|---|
| Tab | Moves focus forward to the next link, button or form control |
| Shift+Tab | Moves focus back to the previous one |
| Enter | Follows a link or presses a button; often submits a form |
| Space | Presses a button, ticks a checkbox; scrolls the page if nothing is focused |
| Arrow keys | Move within a group: radio buttons, select lists, tabs, some menus and sliders |
| Escape | Closes a popup, dialog, dropdown or open menu |
Not every component uses every key. A plain link only needs Tab and Enter. A set of tabs usually puts one Tab stop on the tab list and uses the arrow keys between tabs. What matters is that the behavior matches what people expect and that nothing is reachable only by mouse.
One practical note for Mac users: Safari skips links when you press Tab unless you change a setting in its Advanced preferences. Turn that on, or test in Chrome, Edge or Firefox, otherwise you will report problems that are really a browser default.
Running a keyboard accessibility test, step by step
Pick a handful of pages that use different templates: home, a content page, a blog post, the contact form, and your most important task page, such as checkout or a booking form. Then, for each one:
- Reload the page and click into the address bar, then press Tab once. The first stop should usually be a “skip to content” link that appears on focus. If it does not exist or does not work, our post on skip to content links explains why it matters.
- Keep pressing Tab slowly through the header, menu, main content, sidebar and footer. After each press, find the focus indicator on screen before you press again.
- Open every menu and submenu with the keyboard. Try Enter, Space and the arrow keys. Close them with Escape.
- Operate every interactive thing: accordions, tabs, sliders, video players, filters, popups, the cookie banner, the chat button.
- Fill in and submit a form without the mouse, including one deliberate mistake, and see whether focus goes somewhere useful when the error appears.
- Go backwards with Shift+Tab through a section or two. Some focus problems only show up in reverse.
- Write down each problem as you find it, before you forget the exact spot.
Expect a full pass on a busy page to take a while. That is normal. Rushing is how people miss the one button that cannot be reached.
The four failures you will meet most
Focus you cannot see
You press Tab and the outline vanishes. Something has focus, but you have no idea what. Plenty of themes strip out the outline browsers draw by default because a designer disliked it, and a sticky header can cover the focused item as you move down the page. That breaks 2.4.7 Focus Visible and, in the second case, 2.4.11 Focus Not Obscured (Minimum). The fix belongs in CSS; our article on visible focus indicators goes into what a good one looks like. For testing, just record where focus disappears.
Order that jumps around
Focus moves from the logo to the footer, then back to the menu, then into a sidebar before the main heading. This usually comes from content reordered visually with CSS or page-builder settings while the code order stays the same, or from positive tabindex values someone added to “fix” it. Under 2.4.3 Focus Order, the sequence has to preserve meaning. Note the order you actually got.
Traps
You Tab into something and cannot Tab out. Embedded maps, some video players, third-party booking widgets and badly built popups are the usual suspects. A trap fails 2.1.2 No Keyboard Trap and is one of the most serious things you can find, because a keyboard user’s only way out may be to close the tab. If you get stuck, try Escape and Shift+Tab before recording it.
Things you cannot reach at all
A submenu that appears only under the mouse pointer. A “div” styled as a button with a click handler but no keyboard support. An image that acts as a link but never takes focus. Tab skips straight past these, so you only notice if you are comparing what you see with where focus goes. This is why the slow approach pays off.
Widgets that need more than Tab
Most simple pages pass or fail on Tab and Enter alone. The trouble lives in interactive components, and each has its own expectations.
- Dropdown menus: check that you can expand each submenu from the keyboard, step into its links, and collapse it again. If the parent item is both a link and a toggle, check that both jobs are possible.
- Popups and dialogs: when one opens, focus should move inside it, stay inside while it is open, and return to the button that opened it when it closes. Escape should close it. Our post on accessible popups and modals covers how that should behave.
- Sliders and carousels: the previous, next and pause controls must be reachable and labeled. An autoplaying slider with no pause control is a problem for more people than keyboard users.
- Date pickers and custom selects: many booking and form plugins replace native controls with their own. Check that you can pick a date or option with the keyboard, or type it in.
- Drag-only controls: range sliders, sortable lists and map pins should offer another way to do the same thing. That is the idea behind 2.5.7 Dragging Movements.
Forms deserve their own careful pass beyond keyboard behavior, and our guide to testing WordPress forms covers delivery and spam checks you will want anyway.
A recording sheet that a developer can act on
A keyboard accessibility test is only as useful as its notes. A spreadsheet with these columns is enough; keep one row per problem, not one row per page.
| Column | What to write |
|---|---|
| Page | The full URL |
| Element | Plain description: “cart icon in header”, “second accordion on FAQ page” |
| Keys pressed | Exactly what you did: “Tab from search field, then Enter” |
| What happened | “Focus disappears behind sticky header”, “cannot leave map” |
| Expected | “Visible outline on button”, “Tab moves past the map” |
| Browser | Chrome, Firefox, Edge or Safari, with the device |
| Severity | Blocks a task, makes it harder, or minor |
Severity matters more than count. One trap on the checkout page outranks twenty slightly faint outlines on blog posts. Fix blockers first, on the pages that carry your main tasks.
When you retest after fixes, use the same sheet and add a “retested” column with the date. That gives you a simple record of what was found and fixed, which is useful whoever does the work.
Keyboard checks are one stage of a fuller method. Our guide on testing a website for accessibility shows where this pass fits next to the screen reader and zoom checks, and the rest of our accessibility services for US businesses are mapped on the hub page.
Frequently asked questions
Do keyboard problems also affect screen reader users?
Often, yes. Screen reader users on a desktop move around largely with the keyboard, so a trap or an unreachable menu blocks them too. The reverse does not hold: a page can pass a keyboard test and still give a screen reader nothing useful, such as buttons with no names or errors that are never announced. Test both.
Does keyboard navigation testing work the same on a Mac?
Mostly, with one catch. Chrome behaves much as it does on Windows, but Safari, and to some extent Firefox, limit what Tab reaches unless keyboard navigation is switched on in macOS settings, and Safari has its own Tab option as well. Turn those on before you start, or every Mac result will look worse than the site really is.
Is it a failure if the focus outline is faint but visible?
It can be. WCAG 2.4.7 asks for a visible indicator, and the non-text contrast rule expects interface parts to stand out from what is around them. If you have to search the screen to find focus, real users will struggle too. Record it as lower severity than a missing outline, but record it.
What is the worst keyboard problem to find?
A keyboard trap, where focus goes into something and cannot get out. It stops a keyboard user completely. Close behind are important controls that cannot be reached at all, like a checkout button or menu that only works with a mouse, because they block the main task.
If you want this done for you, with a written list of each barrier and the fix it needs, our manual accessibility testing includes a full keyboard pass on your key templates and tasks.
Next in this series: Automated vs Manual Accessibility Testing: Who Judges What
