Keyboard accessibility testing: real keys, real evidence

Keyboard accessibility testing means operating a site with nothing but the keyboard, and checking that every element can be reached, focus stays visible and nothing traps you. Reviseberg's keyboard agent does the part of that a machine can do reliably: it presses Tab through the pages you name – with real key events – and keeps a trail of every step as evidence, so you audit the test instead of repeating it.

Run a free scan – the full report includes a keyboard run

Why test with the keyboard?

Many people use the web without a mouse: with a keyboard, with switches, with voice control, or with a screen reader that also moves through the page by keyboard. For them, a button that Tab never reaches does not exist. A dialog you cannot get out of ends the visit.

Rule-based scanners see little of this. They check one state of the page – whether an element has a positive tabindex, for instance. Whether you can actually get through a menu, a filter or a checkout only shows when someone presses the keys. That is why the keyboard agent exists.

What the keyboard agent does

You name the pages it should walk – basket, booking flow, application form. The agent drives Chromium with real key events, never a scripted focus call. A scripted call reaches elements the tab order does not – and that gap is exactly the bug it is looking for.

On every page it:

• records how each focusable element looks without focus, before the first key press,
• presses Tab and notes where focus lands, with the element's role and name,
• compares the focused element with how it looked before – on the element, its ::before and ::after, its parent and the nearest elements inside it (a card used as a link often draws the ring on the card), and for a form control that is not drawn itself, on its visible label (how Bootstrap draws checkboxes), because design systems draw the focus ring on any of those,
• checks whether focus lands on something with no size, something transparent or something off-screen,
• looks for things that behave like controls but no Tab reaches,
• checks whether the first focusable element is a working link to the main content,
• confirms a keyboard trap with Tab, Shift+Tab and Escape before it calls it one.

It does not press Enter or Space: it does not open menus or dialogs. On a crawl from an account, the same walk also runs on one page of each template the crawl finds, and a check of our own presses controls there with Enter and Space. It reports a dialog or menu that focus neither moves into nor reaches next, focus that is dropped when it closes, and a trap or invisible focus inside it. Focus management in dialogs behind a step it cannot take remains a manual check.

The agent runs on every full crawl, on every plan and on the free account. In the free full report it walks the start page you give on the form. The instant one-page scan and single-page checks leave it out.

What it reports – and which WCAG criteria are involved

If the agent finds no failure on its pages, these criteria stay "partial" rather than "passed": it walks the pages you named, not every page, and whether an order makes sense is ultimately a human call. Focus order (2.4.3) is therefore judged by a person – the agent's trail shows them the order it found. Whether a sticky header or a cookie banner covers the focused element (2.4.11) is not something the agent checks; it has a guided manual test instead. Our methodology explains how each status is derived.

Every finding shows its working

A score you cannot interrogate is a liability. Open a keyboard finding and you see the run that produced it. Auditors and developers look at the same artefact.

Keyboard findings appear in the issue list with points back like everything else. Developers can pull them straight into their coding agent via the MCP server – keyboard:focus-visible with its selector and affected page, for example.

Run a keyboard test yourself in five minutes

Want to check for yourself first? Here is how to test a site's keyboard accessibility without any tool:

1. Click into the address bar and press Tab. The first focused element should be a skip link ("Skip to content"). Enter should take you to the main content.
2. Keep pressing Tab. Can you see where focus is at every step? Does the order follow the reading order?
3. Open menus, filters and dialogs with Enter or Space. Close them with Escape. Does focus return somewhere sensible?
4. Go back with Shift+Tab. Can you leave every area again?
5. Watch sticky headers, cookie banners and chat widgets: do they cover the focused element?
6. Complete your most important journey to the last step – without the mouse.

Five minutes for one page; too long for a whole site on every release. That is what the agent is for – and for steps 3 and 5, which it does not do, the guided tests in Reviseberg.

Honest limits

Some judgements are not ours to make. These stay with people, and the product says so in the interface rather than quietly guessing:

• Plain-language quality and editorial intent
• Sign-language interpretation quality
• Legal sign-off on the accessibility statement
• Flows requiring real payment or real identity documents
• Anything the evidence leaves ambiguous – it is marked "human" rather than asserted

When the agent is wrong, you mark the finding a false positive with a reason; it then costs no points and no longer fails its criterion. Agreement rates against human auditors will be published once there is a run history to compute them from – not before.

Seven more agents, in development

One agent runs today: keyboard and focus. The seven below do not exist yet. None of them is in the product, none feeds a score or a status, and each is badged "In development" here until it is real.

Point the agent at your hardest page

Checkout, booking flow, application form: name the page the keyboard walk should start on – ideally the one your team dreads testing.

Run a free scan Book a demo