Keyboard Navigation Testing: Barriers a Scan Misses

What an automated run sees of the keyboard

Automated coverage is usually quoted as a single number, but there are two - and they answer different questions. Measured by the volume of findings, the vendor documentation of the open-source testing engine states 57 percent (Deque, axe-core). An evaluation of real first audits arrives at a very similar value: out of 294,958 findings across more than 13,000 pages and page states, 57.38 percent were identified automatically (Deque). That sounds like a solid basis, and it is - as long as you understand what the ratio counts. It counts errors, not error types. A single missing alternative-text pattern rendered a hundred times in a loop produces a hundred findings. A keyboard trap produces exactly one - and goes undetected.

Counted by success criteria instead, the picture changes noticeably. In the same evaluation, the automated rules covered 16 out of 50 Level AA success criteria (Deque). For the two criteria at the heart of keyboard operation - 2.4.3 Focus Order and 2.4.7 Focus Visible - the share of automatically detected findings was zero: they came exclusively from manual testing (Deque). So anyone reading a green report as proof of keyboard accessibility is reading it wrong. Which error types the automated part does find reliably is broken down in the article on the most common WCAG errors on business websites.

The criteria where the keyboard fails

Keyboard accessibility is not one criterion but a chain. At the very front sits 2.1.2 No Keyboard Trap at Level A - the lowest conformance level. The wording is short: if keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component (W3C). The criterion is additionally covered by the non-interference condition, so it applies even when the affected part of the page is not part of the conformance claim at all. A keyboard trap is therefore not a cosmetic defect but a failure the whole claim depends on.

WCAG 2.2 extended that chain in October 2023. The recommendation, first published on 5 October 2023 and reissued in a revised version on 12 December 2024, introduces nine new success criteria - 2.4.11, 2.4.12, 2.4.13, 2.5.7, 2.5.8, 3.2.6, 3.3.7, 3.3.8 and 3.3.9 (W3C); at the same time, 4.1.1 Parsing was removed. Three of them concern focus directly, and two of those describe precisely the failures a machine struggles to see: a sticky bar covering the focused element, and a focus indicator that is too weak. What this means for implementation deadlines is set out in the article on what website operators need to know about the accessibility act.

Keyboard trap: the Tab key cannot get out

The most common route into a keyboard trap runs through interfering with the order itself. In February 2026, home pages averaged 30.4 instances of tabindex=0 or tabindex=-1 - up 17 percent from the previous year and up nearly 300 percent since 2020 (WebAIM Million 2026). Each single instance is harmless on its own: tabindex=0 adds an element to the natural order, tabindex=-1 removes it and makes it focusable only for scripts. The volume is what creates the problem. Where hundreds of places touch the order, a state emerges that nobody can hold in their head any more - and that can only be established by walking through it.

• The dialog with no way back: A modal window captures focus so the keyboard does not wander into the background. If there is no exit via the Escape key and no return to the triggering element, focus stays inside the window.
• The frame with third-party content: An embedded map section or a video player takes over keyboard control and does not hand it back, because the embedded application sets its own key bindings.
• The rebuilt select control: Arrow keys move the selection, the Tab key is intercepted, and there is no documented way out of the opened list.
• The invisible remainder: A hidden menu stays in the focus tree because it was only pushed out of view through transparency or displacement. Focus moves into a region nobody can see.
• The consent layer: A consent dialog sits above the page without holding focus. The Tab key keeps running behind it and the choice stays out of reach.

The harsher variant is positive tabindex values, which artificially re-sort the order. They are rare: the Web Almanac crawl found them on 3.7 percent of pages on desktop and 3.4 percent on mobile (Web Almanac 2025). Where they do occur they weigh heavily, because a single positive value drags the entire natural order behind it: all elements with a positive value come first, and only then the rest of the document. A form field with tabindex=1 in the footer pulls focus ahead of the navigation.

Obscured focus: focused, but not visible

Since WCAG 2.2 there is a dedicated criterion for this. 2.4.11 Focus Not Obscured (Minimum) at Level AA requires that when a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content (W3C). The understanding document names sticky footers, sticky headers and non-modal dialogs as typical causes. The failure is so widespread because it only emerges from the combination: the bar is correct, the form field is correct, and the two together push the focused field underneath the bar as soon as the page rests at that position.

The dividing line between Level AA and the stricter Level AAA runs through the word entirely: at Level AA a partly obscured element is still permitted, at Level AAA it is not. In practice the distinction is delicate, because a half-covered focus outline is already unrecognisable for many people. If you want to start the test yourself before putting it on a fixed schedule, the accessibility quick check offers an entry point for a single URL.

The deleted focus outline

The precondition for invisible keyboard operation is usually created deliberately. In the Web Almanac crawl, around 67 percent of sites explicitly removed the browser default focus outline in 2025 - 14 percent more than the year before (Web Almanac 2025). The reason is visual: the default outline also appears on mouse clicks, and on many interfaces that looks out of place. The clean answer has existed for years and is called :focus-visible - it shows the outline only when the interaction came from the keyboard. It is barely adopted nonetheless: roughly one quarter of pages on desktop use it (Web Almanac 2025).

/* Wrong: removes the outline for every input modality */
:focus { outline: none; }

/* Right: no outline for the mouse, a clear one for the keyboard */
:focus { outline: none; }

:focus-visible {
  outline: 3px solid #004d43;   /* more than the required 2 CSS pixels */
  outline-offset: 2px;          /* the offset keeps the outline readable */
  border-radius: 2px;
}

/* Sticky bars: reserve room so focus does not scroll underneath */
:root { scroll-padding-top: 72px; scroll-padding-bottom: 64px; }

/* Skip link: visible as soon as it receives focus */
.skip-link {
  position: absolute;
  transform: translateY(-120%);
}
.skip-link:focus-visible {
  transform: translateY(0);
}

How strong the outline has to be is described by WCAG 2.2 in measurable terms for the first time. Criterion 2.4.13 Focus Appearance at Level AAA requires an area that is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component (W3C), plus a contrast ratio of at least 3:1 between the focused and unfocused states. The German testing procedure asks for the same value separately: its test step on the current focus position checks whether the contrast ratio between the focused and unfocused state is at least 3:1 (BITV-Test), with JavaScript enabled and in two browsers one after the other. How to keep track of such values after every deployment is described in the article on continuous WCAG regression monitoring.

Skip links: rarely present, often broken

The skip link to the main content is the cheapest keyboard aid there is: one line of HTML, a little CSS, and nobody has to tab through sixty navigation entries to reach the first paragraph. It is present rarely nonetheless. In February 2026, 17.1 percent of the home pages examined carried such a link, up from 15.3 percent the year before (WebAIM Million 2026). And of those present, one in ten was broken - either hidden in a way that made it inaccessible, or pointing at a target that did not exist on the page at all (WebAIM Million 2026).

A second crawl arrives at higher values because it does not look at home pages only: the share rose there from 19.7 percent in 2021 to 25.65 percent on desktop and 26.23 percent on mobile (Web Almanac 2025). Both surveys point in the same direction and to the same order of magnitude: three out of four pages force keyboard users through the entire header. The second part of the finding is the more unpleasant one, because it feels like a completed task. A skip target that no longer exists after a rebuild is the same failure type as a dead internal link - and is found with the same means, see the article on automating broken link and 404 monitoring.

Rebuilt controls and mute labels

An element that looks like a button is not one yet. The share of pages that rebuild a button through the corresponding ARIA role has increased by roughly 4 percent and now stands at 53 percent on desktop and 54 percent on mobile (Web Almanac 2025). The role alone tells assistive technology what the element is meant to be - it brings neither focusability nor key handling with it. A div with role=button additionally needs tabindex=0 and its own handling of the Enter and Space keys. If either is missing, the function exists for the mouse and not for the keyboard.

The pass: eight stops without a mouse

The test itself needs no tooling, only discipline. You put the mouse aside, place focus in the address bar with one click, and work through the page from there. What matters is that every stop is recorded - not only the conspicuous ones. A log with eight lines is a result even when all eight are fine, and it is the reference point for the next pass.

1. Set the starting point: Focus into the address bar, then move into the document with the Tab key. The first stop should be the skip link - if it does not become visible, the first finding is already there.
2. Write down the order: Number every stop and compare it with the visible layout. If focus jumps from the header into the footer and back again, that is a failure of 2.4.3.
3. Check visibility at every stop: Is the focus outline perceivable, and does the element sit fully clear? Sticky bars show up here, not before.
4. Walk backwards: Shift and Tab back up. The reverse order exposes traps that stay unnoticed going forward, because scripts often redirect focus in one direction only.
5. Open and leave every dialog: Open it, cycle through it once with the Tab key, close it with the Escape key. Focus has to land on the triggering element, not at the top of the page.
6. Operate rebuilt controls deliberately: Trigger everything that looks like a button with the Enter key and with the Space key. If only one of the two responds, the key handling is incomplete.
7. Take forms all the way to submission: Error messages have to receive focus or be announced. A field with a red border and no focus change stays unnoticed for keyboard users.
8. Repeat at 200 percent zoom: Sticky bars grow with it, the available area shrinks - obscured focus occurs far more often here than at full width.

The console lines do not replace the pass, they speed it up. Once a finding is established it belongs in a repeatable procedure so that it does not return with the next rebuild. That is exactly what recorded browser flows are for: a script walking the eight stops in the same order is set up in a few minutes and then runs unattended - the approach is described in the article on recording browser flows, the technical side under browser monitoring.

Why a one-off finding does not hold

Accessibility failures are the norm on home pages: 95.9 percent of the home pages examined had detectable WCAG failures (WebAIM Million 2026). In total, 56,114,377 individual errors were found, an average of 56.1 per page (WebAIM Million 2026). Those numbers come from an automated run across the home pages of the one million most visited websites - the keyboard problems that require manual testing come on top of them. The reason for their persistence is in the same survey: the average number of page elements rose to 1437 per home page in February 2026, an increase of 22.5 percent in a single year (WebAIM Million 2026).

The average number of page elements increased to 1437 per home page in February 2026 - a 22.5% increase in only one year.

— WebAIM Million 2026

More elements means more stops a keyboard has to cover, and more places where an order can tip over. A finding from six months ago says little about today if there have been twelve deployments since. Accessibility testing therefore belongs in the same place as any other state check: on a fixed schedule, compared against the previous run, with an alert as soon as something gets worse. The accessibility module compares findings per URL against the previous run; the technical kinship with a deep state endpoint is described in the article on the health check endpoint.

Who is affected and what is at stake

The group in question is not a fringe group. At the end of 2025, a good 7.8 million people with a severe disability lived in Germany, which corresponds to 9.4 percent of the population (Statistisches Bundesamt); the count covers people holding a valid pass with a degree of disability of at least 50. Worldwide, the health organisation estimates the number of people experiencing significant disability at 1.3 billion, around 16 percent of the world population (WHO). Not all of them depend on keyboard operation - but every motor impairment, every temporary injury and every screen reader runs through the same input modality.

How this plays out in daily use is shown by the largest ongoing survey of screen reader users. It received 1539 valid responses, collected in December 2023 and January 2024 (WebAIM Screen Reader Survey 10); 1372 respondents, or 89.9 percent, use a screen reader because of a disability. In the ranking of the most problematic items, lack of keyboard accessibility sits at rank 5 out of 12 (WebAIM Screen Reader Survey 10) - behind CAPTCHA, interactive elements that do not behave as expected, links and buttons that do not make sense and screens that change unannounced, but ahead of complex forms (rank 7) and missing or improper headings (rank 8), which often receive considerably more attention in projects.

Legally the frame has already closed. The European directive applies to services provided to consumers after 28 June 2025 (Richtlinie EU 2019/882). Where an affected service is not offered accessibly, the German implementing act provides for an administrative fine of up to one hundred thousand euros (BFSG, section 37 paragraph 2); for the remaining cases the ceiling is ten thousand euros. Under the transitional provision, legacy solutions may not continue unchanged beyond 27 June 2030 (BFSG, section 38 paragraph 1). Which warning-letter risks exist alongside that is set out in the article on accessibility warning letters.

From finding to fix

A log with eight stops is not a fix yet, but it is the basis for a prioritisation you can justify. The order follows from the conformance level and from the number of affected flows: a trap in the payment path weighs more than a missing skip link on a peripheral page, and a failure of a Level A criterion weighs more than one of Level AAA.

• Level A first: Keyboard traps and unreachable functions block use completely and are additionally covered by the non-interference condition.
• Then the focus indicator: An outline restored through :focus-visible is usually a change in a single place in the stylesheet and takes effect across the whole site.
• Then the order: Remove positive tabindex values and align the source order with the visible layout - that often clears several findings at once.
• Then the rebuilt controls: Wherever a native button is possible, it replaces the rebuild including role, focusability and key handling.
• Fine measures last: Outline thickness and contrast of the focus indicator, skip links on subpages, order in rarely used regions.

What follows is the evidence. An accessibility statement based on a one-off finding ages quickly; it only becomes defensible with a recurring test run and a record of the results that still shows, half a year later, which state applied when. For the reporting side of those results the same mechanics work as for availability reports, described under reporting and status pages. And because a navigation rebuild regularly changes both at once - focus order and URL structure - it is worth looking at canonical tag monitoring in the same pass.