Fixes by subject · 52 techniques
How to Fix Keyboard and Focus Problems
If one check had to stand for all of accessibility, it is this one. Everything has to work without a mouse.
Keyboard access is the load-bearing wall. A screen reader user drives by keyboard, and so does somebody with a tremor, somebody with a repetitive strain injury, somebody using voice control and somebody on a switch device. The techniques here cover making everything reachable, keeping the focus indicator visible, and ordering focus so it preserves meaning. They also cover letting people back out of anything they can get into, getting past repeated blocks, and handling single-key shortcuts that fire while somebody is dictating. Two of those are wider than people expect. Skipping repeated blocks does not have to mean a skip link, because grouping that content into landmarks and section headings is the other sufficient route. A page with both conforms without one. And a keyboard trap is only a failure when there is no way out, so a media player that needs Escape to release focus and says so passes.
All 52 techniques
They run in technique order, and each one carries a tag. Sufficient techniques satisfy a rule. Advisory ones help without being required. Failures document a specific way of getting it wrong. None of them is mandatory, because W3C publishes techniques as documented ways of meeting a criterion rather than the only ways, so your own approach conforms as long as it meets the criterion.
- G1Sufficient2.4.1Add a skip link as the first element on the page
- G202Sufficient2.1.1Make every control work with a keyboard
- C15Sufficient1.4.1, 2.4.7Style the focus indicator instead of removing it
- F55Failure2.1.1, 2.4.7, 2.4.13, 3.2.1Do not use script to throw focus away
- H91Sufficient4.1.2, 2.1.1Use native HTML controls instead of rebuilt ones
- H64Sufficient4.1.2, 2.4.1Give every iframe a descriptive title
- H69Sufficient2.4.1, 2.4.10Start every content section with a real heading
- H97Sufficient2.4.1, 1.3.1Wrap navigation link groups in nav elements
- H102Sufficient2.4.3Build modal dialogs with the native dialog element
- ARIA11Sufficient1.3.1, 1.3.6, 2.4.1Add landmarks so users can skip around
- C6Sufficient1.3.2, 1.4.5, 1.4.9, 2.4.1Keep source order meaningful when CSS repositions content
- C27Sufficient1.3.2, 2.4.3Match DOM order to visual order
- C40Sufficient1.4.11, 2.4.7, 2.4.13Build focus indicators that work on any background
- C41Sufficient2.4.13Draw a strong focus indicator inside the control
- C43Sufficient2.4.11, 2.4.12Stop sticky headers hiding focused content
- C45Sufficient2.4.7Show keyboard focus with :focus-visible
- SCR2Sufficient2.1.1Pair every mouse handler with a keyboard one
- SCR20Sufficient2.1.1Give device-specific scripts a keyboard path
- SCR26Sufficient2.4.3Insert new content right after its trigger
- SCR27Sufficient2.4.3Reorder sections in the DOM, not just on screen
- SCR28Sufficient2.4.1Collapse repeated blocks so they can be skipped
- SCR29Advisory2.1.1Make a scripted div or span keyboard-operable
- SCR31Sufficient2.4.7Highlight the focused element with script
- SCR35Sufficient2.1.1Hang scripted actions on real links and buttons
- F10Failure2.1.2Do not trap keyboard users inside embedded content
- F42Failure1.3.1, 2.1.1, 4.1.2Do not emulate links with scripted spans
- F44Failure2.4.3Do not break tab order with positive tabindex
- F54Failure2.1.1Do not wire functionality to pointer events only
- F78Failure1.4.11, 2.4.7, 2.4.13Never remove the keyboard focus outline with CSS
- F85Failure2.4.3Do not open dialogs far from their trigger
- F98Failure2.5.6Do not build interactions that respond to touch alone
- F99Failure2.1.4Do not hardwire single-character keyboard shortcuts
- F110Failure2.4.11Do not let sticky bars bury the focused element
- G21Sufficient2.1.2Never trap keyboard focus inside a widget
- G59Sufficient2.4.3Order interactive elements to match the content
- G90Sufficient2.1.1Pair every event handler with keyboard support
- G123Sufficient2.4.1Add skip links past repeated content blocks
- G124Sufficient2.4.1Add top-of-page links to each content area
- G125Sufficient2.4.5Link related pages so content is findable
- G126Sufficient2.4.5Provide a list of links to every page
- G136AdvisoryLink nonconforming pages to a conforming version
- G149Sufficient2.4.7Use components the browser highlights on focus
- G161Sufficient2.4.5Add a site-wide search function
- G165Sufficient2.4.7Keep the platform's default focus indicator
- G195Sufficient1.4.11, 2.4.7, 2.4.13Ship a clearly visible custom focus indicator
- G217Sufficient2.1.4Let users remap or disable single-key shortcuts
- G223AdvisoryMake keyboard focus impossible to miss
- PDF2Advisory2.4.5Add bookmarks so long PDFs are navigable
- PDF3Sufficient1.3.2, 2.1.1, 2.4.3Fix the reading and tab order in PDFs
- PDF9Sufficient1.3.1, 2.4.1Tag PDF headings with real heading tags
- PDF11Sufficient1.3.1, 2.1.1, 2.4.4, 2.4.9Tag PDF links so they are announced
- PDF23Sufficient2.1.1Use fillable form fields instead of flat text
More on Keyboard and focus
The other 13 subjects
Knowing the technique is not the same as knowing you need it.
The free scan checks 10 pages in a real browser and maps every machine-checkable failure to the exact fix guide that clears it.