Keyboard navigation and visible focus — what does WCAG require?
A significant share of web users navigate without a mouse: people with motor impairments, screen reader users — and power users who prefer the keyboard because it's faster. WCAG therefore sets a series of requirements: everything interactive must be reachable by keyboard, focus must never get stuck, the order must be logical and it must always be visible where you are. These are requirements that don't show up in a screenshot — they only reveal themselves when someone actually tabs through the page.
What does WCAG require?
Five criteria carry the main responsibility:
- 2.1.1 Keyboard (level A) — all functionality must be operable with a keyboard alone. Menus, forms, modals, date pickers: if it can be clicked, it must be tabbable.
- 2.1.2 No keyboard trap (level A) — focus must never get stuck in an element it can't leave by keyboard. A modal that captures focus with no way out locks the entire page for anyone without a mouse.
- 2.4.3 Focus order (level A) — the tab order must be logical, normally matching the visual order. Focus that jumps back and forth makes the page incomprehensible.
- 2.4.7 Focus visible (level AA) — it must be visible which element has focus. Without a visible indicator, keyboard users navigate blind.
- 2.4.11 Focus not obscured (level AA, new in WCAG 2.2) — the focused element must not be completely hidden by sticky headers, banners or other layers sitting on top of the page.
Who is covered?
The criteria are part of the European standard EN 301 549, which the Swedish Act on Accessibility to Digital Public Service (DOS-lagen) requires of the public sector. Since 28 June 2025, the same level also applies to private businesses covered by the EU's European Accessibility Act through the Swedish Accessibility Act (2023:254) — e-commerce, banking services, passenger transport and electronic communications, among others. The core is services to consumers; pure B2B is not covered.
Common issues we see
- Clickable elements built from div or span without keyboard support — they look like buttons but can neither be reached nor activated by keyboard.
- The focus outline styled away with outline: none — often because the designer found it ugly — without any replacement added.
- Modals and cookie banners that capture focus with no way out, or the opposite: let focus slip through to the page behind.
- Tab order following the source order instead of the visual order — focus jumps between columns and sections.
- Sticky headers covering the focused element — you're standing on a link but can't see it.
- Flows that work on desktop but break in mobile view, where menus and components change behaviour.
How CompliantHQ tests this
This can't be determined by just reading the page's code — it has to be experienced. In our deep suite, included in the paid plans, the scanner tabs through the pages with a real keyboard in a real browser and measures: is everything interactive reachable, does focus get stuck anywhere, is the order logical, is the focus indicator visible, and is the focused element obscured by sticky layers.
Everything is also re-run in mobile view, since menus and components often change behaviour there — a menu that works perfectly on desktop can be a trap on mobile.
How to fix it
- Use real interactive elements — button, a, input — instead of clickable divs. Keyboard support then comes for free.
- Never remove the focus outline without replacing it with a clearer indicator of your own — outline: none without a replacement fails 2.4.7 outright.
- Make sure modals can be closed with Escape and that focus returns to the element that opened them.
- Let the tab order follow the visual order — avoid positive tabindex values and let the document order decide.
- Give the page scroll margin below sticky headers (for example with scroll-padding), so focused elements land below the header instead of behind it.
- Test it yourself: put the mouse away and work through the page's most important flow with Tab, Shift+Tab and Enter.
What the check covers
- That everything interactive on the page can be reached with a keyboard alone.
- That keyboard focus never gets stuck in an element it can't leave.
- That the focus order is logical when tabbing through the page.
- That it's visible where keyboard focus currently is.
- That focused elements aren't hidden behind fixed headers or banners.
WCAG criteria covered
- 2.1.1 Keyboard — everything on the page must be usable with a keyboard alone, because many people can't use a mouse — e.g. people with motor impairments or low vision. (A)
- 2.1.2 No keyboard trap — someone navigating by keyboard must never get stuck in a part of the page (e.g. a popup) with no way to move on or back out. (A)
- 2.4.3 Focus order — when tabbing through the page, the highlight must move in a sensible order, not jump back and forth across the page. (A)
- 2.4.7 Focus visible — when tabbing through the page it must be visible where you are, e.g. with a clear outline around the highlighted element. (AA)
- 2.4.11 Focus not obscured (minimum) — the element you've tabbed to must not sit hidden behind a fixed menu or cookie banner, leaving you navigating blind. (AA)
Common questions
How do I test keyboard navigation myself?
Put the mouse away and tab through the page: can you reach everything interactive, can you always see where you are, can you go backwards with Shift+Tab, and can you complete the most important flow — a purchase or a form, say — without getting stuck?
Is it allowed to remove the focus outline with CSS?
Only if you replace it with a clearly visible indicator of your own. outline: none without a replacement means the page fails WCAG 2.4.7 — nothing shows where focus is.
What is a keyboard trap?
An element that focus can get into but not out of by keyboard — often a modal, an embedded widget or a third-party player. For a user without a mouse, it ends the entire visit.
What's new in WCAG 2.2 around focus?
Criterion 2.4.11: the focused element must not be completely hidden by sticky layers like headers and banners. It catches a common problem earlier WCAG versions didn't cover — focus exists and is visible, but sits behind the menu.
Want to see what we find on your site?
Run a free scan — all four modules included for 30 days, no card required.