Keyboard access is the load-bearing wall. A screen reader user drives by keyboard. So does someone with a tremor, someone with repetitive strain injury, someone using voice control, someone using a switch device, and plenty of people who simply find it faster.
It is also the fastest thing to test and the most brutal to fail. A missing alt attribute is an inconvenience. A keyboard trap in your checkout is a customer who cannot buy from you and cannot leave the page.
The Rules That Govern the Keyboard
One guideline is named after this subject and holds four criteria. Three of them are Level A, which is the level every law that names WCAG asks for.
- 2.1.1 Keyboard, Level A. Every function has to work without a mouse. There is one exception, and it is narrow. Where the function genuinely depends on the path your movement takes rather than on where it starts and stops, such as freehand drawing, it is excused. Almost nothing else is.
- 2.1.2 No Keyboard Trap, Level A. Anything you can tab into, you have to be able to get out of by keyboard. And there is a second half nearly everyone drops. Where escaping needs something other than Tab or the unmodified arrow keys, you have to tell the user which key does it. A media player that releases focus on Escape conforms, as long as it says so.
- 2.1.4 Character Key Shortcuts, Level A. Say a shortcut is a bare letter, number or punctuation mark with no modifier. Then you owe one of three things. A way to turn it off, a way to remap it onto a non-printable key, or making it work only while the relevant component has focus.
- 2.1.3 Keyboard (No Exception), Level AAA. The same as 2.1.1 with the path-dependent exception removed. Every function, no exceptions at all.
Take a second look at the shortcuts one, because it reads like a niche rule and it is not. A single-character shortcut is the classic voice-control failure. Dictation puts letters into the page, the page reads them as commands, and the person watching their own words trigger a delete is having the worst possible day with your software. This page opened by naming voice-control users. That is the criterion written for them.
Three more criteria from elsewhere in the standard decide how a keyboard journey actually feels.
- 2.4.3 Focus Order, Level A. Focus moves in an order that preserves meaning and operability.
- 2.4.7 Focus Visible, Level AA. You can always see where focus currently is. It is Level AA in WCAG 2.2, whatever a secondary source may tell you, and it has not moved.
- 2.4.11 Focus Not Obscured, Level AA, new in WCAG 2.2. A sticky header or cookie bar must not hide the focused thing entirely. Read that word carefully, because being partly covered still passes at AA, and it is 2.4.12 at AAA that closes the gap. Even so, this one catches a lot of otherwise well-built sites.
There is a useful carve-out attached to the obscuring rule too. Content the user opened themselves, such as a dropdown they just expanded, does not count against you as long as they can reveal the focused thing again without moving focus on.
Why a Third-Party Embed Is Still Your Failure
WCAG names four criteria that apply to everything on a page, including content you never claimed conformance for, and the keyboard trap rule is one of them.
So a trap inside an embedded booking widget, a chat bubble or a cookie banner breaks conformance for the whole page. Not for the widget. That is worth knowing before the vendor tells you their component is out of scope, because on this particular rule it is not, and the page carrying it is yours.
The Test, in Ten Minutes
Put your mouse out of reach. Not to one side. Out of reach, so you cannot cheat without noticing.
- Load your home page and press Tab. A "Skip to content" link should appear as the first stop. What the rule behind this actually requires is 2.4.1 Bypass Blocks, which asks for a way past repeated content and accepts several routes. A skip link is one. Landmarks and a proper heading structure are others, and both of those only help screen reader users, so a site relying on them alone still makes a sighted keyboard user tab through the whole navigation on every single page.
- Keep tabbing. Can you see where you are at every stop? If the indicator vanishes even once, that is Focus Visible failed.
- Watch the order. Focus should move roughly the way your eye reads. A jump from the header to the footer and back is a real failure, not a quirk.
- Open every menu, modal, dropdown, and date picker. Can you operate it with the arrow keys? Can you close it with Escape?
- Try your cookie banner. These get added last, by a third party, and they are among the most common traps we find.
- Complete one real task. Buy something, book something, send something. Start to finish, no mouse. If a page in that flow fails, the whole process fails with it, because conformance runs across every page in a process rather than page by page.
The one that surprises owners
Most people find something in the first thirty seconds, and it is usually a control they had no idea was unreachable. The custom dropdown, the image carousel, the star rating. They were built from divs, and a div is not focusable unless somebody made it so.
The Failures We Find Most
| What breaks | Why | The fix |
|---|---|---|
| Focus outline removed | outline: none in CSS to tidy up the design | Draw a replacement with :focus-visible at 3:1 contrast |
| Divs built as buttons | <div onclick> is not focusable and is not announced | Use a real <button> |
| Modal does not trap focus | Focus keeps tabbing to the page behind it | Move focus in, keep it inside, restore it on close |
| Modal traps focus permanently | No Escape handler and no reachable close button | Handle Escape, and put the close button in the tab order |
| Positive tabindex | tabindex="3" jumps the natural order | Use tabindex="0" or none, and fix source order instead |
| Sticky header covers focus | The focused element scrolls under a fixed bar | Add scroll-margin-top, or shrink the bar |
| Custom widgets ignore arrow keys | Native controls were replaced without the keyboard behaviour | Implement the expected key handling for that pattern |
| A single-letter shortcut fires during dictation | A bare character key was bound with no modifier | Let people turn it off or remap it, or scope it to a focused component |
That last row about arrow keys has a stronger backing than most people realise, and it is worth quoting at a developer who thinks it is optional. ARIA itself, as a full W3C Recommendation, puts a must-level duty on authors to manage focus for eight container roles. Grid, listbox, menu, menubar, radiogroup, tree, treegrid and tablist. Claim one of those roles and you have taken on the keyboard behaviour, as a requirement of the specification rather than as an inference from WCAG.
Focus Visible, Done Properly
Removing the focus outline is the single most common cause of keyboard failures we see. It happens for an understandable reason. The browser default looks out of place, so somebody deletes it and never replaces it.
The modern answer is :focus-visible, which shows an indicator for keyboard users and stays out of the way for mouse users. That removes the design objection entirely. Whatever you draw needs 3:1 contrast against the colours next to it, which comes from 1.4.11 Non-text Contrast rather than from the focus rule itself. It also has to survive every background it can land on, including your dark sections.
There is a second, stricter test at Level AAA, and it is the reason "our focus ring passes" sometimes turns out to be half an answer. 2.4.13 Focus Appearance measures 3:1 between the focused and unfocused states on the same pixels, and asks for a minimum area rather than a minimum thickness. A ring with plenty of contrast against the page, sitting on a component that already had a border much like it, passes the AA test and fails the AAA one.
One caveat on :focus-visible that catches teams out. The browser decides when it matches, and the heuristics differ between engines. A control focused by script, such as a dialog on open, may or may not get the indicator, so anything you focus programmatically needs testing rather than assuming.
Our fix guides cover the specifics, at style focus-visible, a two-colour focus indicator for backgrounds that vary, and what not to do.
Keyboard Access Is Not the Same as Screen Reader Access
This trips up teams who've done the keyboard work and assume they are finished.
Keyboard access asks. Can I reach it and operate it? Screen reader access asks. Do I know what it is, what state it is in, and what just happened? A button you can reach and press, announced as "button" with no name, passes the keyboard test and fails the person using it.
Do both. Our screen reader testing guide covers the second half.
One honest limit
You tabbing through your own site finds a lot, and it will not find everything, because you know where everything is. Somebody meeting your interface cold, driving it by keyboard every day, finds the parts that are technically reachable and practically unusable. That is what the human pass in our audit is for.