ResourcesHow people use the web
Keyboard access and focus
Quick answer
Nearly everything that works with a mouse has to work with a keyboard. People need to see where they are, reach every control, and never get stuck. You can check the basics on your own site with a keyboard.
Facts last checked
Who uses a keyboard
Some people use the web with a keyboard and nothing else.
People who can't use a mouse
For some people a mouse is painful, tiring or impossible to use.
Screen reader users
On a computer, people usually drive a screen reader with keys, not a mouse.
Switch and voice control users
Switches and voice control act through the same keyboard interface.
Power users
Some people without disabilities prefer the keys, or find them quicker.
The keys people use
A few keys do most of the work. Learn them in the table, then try them on the small form below it.
| Key | What it does |
|---|---|
| Tab | Moves forward to the next link, button or field |
| Shift + Tab | Moves back |
| Enter | Follows a link or presses a button |
| Space | Presses a button or toggles a checkbox |
| Arrow keys | Move within menus, tabs and radio groups |
| Escape | Closes a dialog or menu |
Source: W3C, ARIA Authoring Practices Guide
Try it: move through a booking form
Press Tab to move forward and Shift + Tab to move back. This form is only a demo, so nothing is sent.
Focus: outside the form
- The plum outline is the focus ring. It shows where you are.
- Focus moves one control at a time, in the order you see on screen.
- Every control can be reached and used without a mouse.
What WCAG 2.2 asks for
The main success criteria for keyboard use, focus and target size, at Level A and AA.
| Success criterion | Level | What it asks for |
|---|---|---|
| 2.1.1 Keyboard | A | Everything works with a keyboard, except input that depends on the path of a movement. |
| 2.1.2 No Keyboard Trap | A | Focus can always move on. It never gets stuck. |
| 2.4.1 Bypass Blocks | A | People can skip blocks that repeat on every page, like the menu. |
| 2.4.3 Focus Order | A | Focus moves in an order that makes sense. |
| 2.4.7 Focus Visible | AA | You can see which control has focus. |
| 2.4.11 Focus Not Obscured (Minimum) | AA | The control with focus isn't fully hidden behind other content. New in WCAG 2.2. |
| 2.5.8 Target Size (Minimum) | AA | Targets are at least 24 by 24 CSS pixels, with exceptions. New in WCAG 2.2. |
Source: W3C, Understanding WCAG 2.2
- 24 by 24 CSS pixels: the WCAG 2.2 Level AA minimum (2.5.8), with exceptions
- 44 by 44 CSS pixels: Level AAA (2.5.5 Target Size (Enhanced))
- Squares are drawn at true size.
A quick keyboard check
You don't need any tools. Open your site and try this.
Unplug the mouse
Or move it out of reach.
Press Tab
Keep pressing it to move down the page.
Look for focus
Can you see where you are at every stop?
Use everything
Can you reach and use every menu, form and button?
Get out
Can you close each menu and dialog, and keep going?
This check finds the basics. It doesn't replace testing by people who know what to look for.
Common barriers and fixes
Six barriers we look for, and two of the fixes.
2.4.7 Focus Visible
No visible focus ring
The outline was removed with outline: none, so people can't see where they are.
2.1.1 Keyboard
Clickable divs
A div with a click handler isn't a button. Tab skips it.
2.4.3 Focus Order
Focus that jumps around
Focus moves in a different order from the one on screen.
2.1.1 Keyboard
Menus that only open on hover
The menu opens for a mouse pointer, and never for a keyboard.
2.4.3 Focus Order, 2.1.2 No Keyboard Trap
Dialogs that don't take focus, or won't let it go
A dialog opens and focus stays behind it. Or focus goes in and can't get out.
2.4.1 Bypass Blocks
No skip link
With no skip link or other way past it, people have to Tab through the whole menu on every page.
Follows the page
Tab moves through the page in the order you read it.
Jumps around
Tab jumps from the logo to the footer and back, so people lose their place.
Removed: <div class="button" onclick="openMenu()">Menu</div>
Added: <button type="button" onclick="openMenu()">Menu</button>
A real button can be reached with Tab, and works with Enter and Space.
Removed: a:focus { outline: none; }
Added: a:focus-visible { outline: 3px solid; outline-offset: 3px; }
Keep the outline. If you restyle it, 1.4.11 Non-text Contrast (Level AA) asks for at least 3:1 against the colors next to it.
Sources
- W3C, Understanding Success Criterion 2.1.1: Keyboard (accessed 2026)
- W3C, Understanding Success Criterion 2.1.2: No Keyboard Trap (accessed 2026)
- W3C, Understanding Success Criterion 2.4.1: Bypass Blocks (accessed 2026)
- W3C, Understanding Success Criterion 2.4.3: Focus Order (accessed 2026)
- W3C, Understanding Success Criterion 2.4.7: Focus Visible (accessed 2026)
- W3C, Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum) (accessed 2026)
- W3C, Understanding Success Criterion 2.5.8: Target Size (Minimum) (accessed 2026)
- W3C, Understanding Success Criterion 2.5.5: Target Size (Enhanced) (accessed 2026)
- W3C, ARIA Authoring Practices Guide: Developing a Keyboard Interface (accessed 2026)
- W3C, Understanding Success Criterion 1.4.11: Non-text Contrast (accessed 2026)
We provide technical accessibility services, not legal advice.
More guides
Who web accessibility is for
Who benefits from an accessible website: the numbers, the types of disability, the tools people use and what each group needs from a site.
How screen readers work
How a screen reader turns a web page into speech, how people move around with one, which ones people use, and what breaks them.
Color contrast, explained
What a contrast ratio is, the ratios WCAG 2.2 asks for, and how to check and fix your own colors.
Start with a free snapshot.
Tell us your website. We'll run an automated check of up to 10 key pages and walk you through what we found. It's an automated check that finds only some issues, not an audit.
Get a free snapshot