Keyboard and focus checker
Finds controls people can't reach by keyboard, focus styles that were removed, and focused elements hidden behind sticky headers.
What this check looks for
The audit runs this check with every other check, on the page as the browser renders it.
- Clickable elements that are not controls
- Divs and spans with click handlers that a keyboard can't reach or activate.
- Removed focus styles
- outline:none and similar rules that leave no visible focus indicator.
- Focus hidden by fixed content
- Sticky headers and banners that can cover the focused element.
- Positive tabindex
- tabindex values above 0 that break the natural tab order.
What a failure looks like
A menu toggle is a div with a click handler. Keyboard users can't reach it, so the navigation never opens for them.
<!-- Broken: not focusable, no keyboard activation -->
<div class="menu-toggle" onclick="openMenu()">Menu</div><!-- Fixed: a real button gets focus, Enter and Space for free -->
<button type="button" class="menu-toggle" aria-expanded="false" aria-controls="site-menu">Menu</button>How it shows in AccessGuard
Each finding names the WCAG criterion, explains the problem in plain words and shows the element that fails, so a developer can find it on the page.
WCAG criteria
Findings from this check name one of these criteria. How much of each the audit can decide on its own:
| Criterion | Level | Automation |
|---|---|---|
| 2.1.1 Keyboard Clickable elements that are not keyboard controls are flagged. Using every feature by keyboard needs a person. | A | Partly automated |
| 2.1.2 No Keyboard Trap | A | Needs a person |
| 2.4.3 Focus Order | A | Needs a person |
| 2.4.7 Focus Visible | AA | Partly automated |
| 2.4.11 Focus Not Obscured (Minimum) | AA | Partly automated |
What still needs a person
No automated tool can confirm these. AccessGuard marks related findings as Review, so nobody mistakes them for a pass.
- Tabbing through the whole page to confirm the focus order makes sense.
- Checking that focus never gets stuck inside a widget (a keyboard trap).
- Using menus, dialogs and forms end to end with only a keyboard.
Questions
Can keyboard accessibility be tested automatically?
Partly. The audit finds common causes, such as click handlers on non-interactive elements and removed focus styles. Moving through the page with a keyboard is still the only way to confirm focus order and that nothing traps focus.
Is outline:none always a failure?
Only when nothing else shows where focus is. A custom focus style with enough contrast is fine, and often looks better than the browser default.
What is WCAG 2.4.11?
A criterion new in WCAG 2.2. When an element receives keyboard focus it must not be entirely hidden by other content, such as a sticky header or cookie banner.
Related checks and guides
- ARIA checker
Finds invalid roles and attributes, controls with no accessible name and ARIA that hides content people need.
- Target size checker
Measures buttons, links and icons on the rendered page against the WCAG 2.2 minimum of 24 by 24 pixels.
- Headings and landmarks checker
Checks that pages have a clear heading outline, a main landmark and a way to skip repeated navigation.
- Keyboard Navigation Accessibility: A Complete WCAG Guide
Guide
- Accessible Modals: How to Build Dialogs the Right Way
Guide
Check a client page for keyboard and focus issues
The free audit runs this check and every other one. Results in about a minute.