Grounded

Your audit report says 2.1.1 fails on every element. Here is how to tell whether that is real.

Someone sends you an accessibility audit. Under 2.1.1 Keyboard, every element on the page carries the same verdict: no alternative to using only the keyboard. You unplug your mouse, tab through the page, and everything works — focus moves, the ring is visible, Enter activates what it should.

One of you is wrong. Working out which is not a matter of opinion, and the answer is more interesting than "the vendor is padding the report".

First, 2.1.1 does not mean what the report probably assumes

The criterion says:

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Level A. Note what is absent: any mention of a particular key.

The Understanding document is explicit about this:

buttons that have focus can generally be activated using both the Enter key and the Space bar. If a custom button control in a web application instead only reacts to Enter (or even a completely custom key or key combination), this still satisfies the requirements of this success criterion.

So "Enter didn't do anything, therefore 2.1.1" is not a finding. Neither is "this control needs a keystroke I did not guess". The question 2.1.1 asks is whether the function can be performed from a keyboard at all — not whether it can be performed the way you expected.

That cuts both ways. It rules out a class of false positives, and it also means a control can pass 2.1.1 while being effectively unusable, because nobody can discover the key. That is a genuine problem, but it belongs to other criteria and to plain usability, not to this one.

Second, three things people file under 2.1.1 that are separate criteria

This matters, because if the report is filing everything under one number, that is itself a signal about how it was produced.

Getting stuck is 2.1.2 No Keyboard Trap (A). You can tab in and cannot tab out. Different criterion.

Seeing where you are is 2.4.7 Focus Visible (AA). That thick focus ring you observed is evidence for 2.4.7. It is not evidence for or against 2.1.1 — a page can have a perfect focus indicator on every control and still fail 2.1.1, and it can pass 2.1.1 with no visible focus anywhere.

Focus being hidden behind a sticky header is 2.4.11 Focus Not Obscured (Minimum) (AA), new in WCAG 2.2. Also not 2.1.1.

If your own test consisted of "I tabbed and I could see the focus and Enter worked", you have gathered good evidence about 2.4.7 and only partial evidence about 2.1.1.

What a real 2.1.1 finding looks like

A failure under this criterion has to name a function that cannot be performed. Not an element that exists. So a usable finding contains:

That is not a high bar. It is what the tester wrote down while testing, because they had to, in order to know it failed. Any audit worth paying for has this already.

If every element carries an identical verdict, that is not a result — it is a template. A checklist filled in once and copied down the column looks exactly like this. So does a report where "not tested" was exported as "fails".

Go back and ask for reproduction steps on two or three of the flagged items. It is a factual request they can either satisfy or not, and it settles the argument without anybody having to debate the wording of a success criterion.

But do not conclude your own test cleared the page

This is the part where people who are right about the report go on to be wrong about their site.

Unplugging the mouse and pressing Tab is a real test and it misses most of the failures that actually show up in audits:

The reason you can both be right

Here is the resolution that usually applies, and almost nobody checks it: keyboard-only and keyboard-with-a-screen-reader-running are two different tests.

NVDA and JAWS in browse mode intercept keystrokes before the page receives them. An element reachable by Tab with the screen reader off can be unreachable in browse mode, and occasionally the reverse. A tester running NVDA and a developer running nothing will genuinely observe different behaviour on the same page.

So if the vendor tested with assistive technology on and you tested with it off, neither of you is lying and neither of you has the whole picture. This is also why the environment line in a finding is not bureaucratic detail — without it, the finding cannot be reproduced or refuted.

What to do, in order

  1. Ask for reproduction steps on two or three flagged items.
  2. Try those specific items yourself with NVDA running, in browse mode, on Windows. Firefox or Chrome, whichever they named.
  3. If they reproduce, you have learned something real about your site.
  4. If they cannot be reproduced and the vendor cannot produce steps, you have grounds to reject the column — and to ask what else in the report was generated the same way.

An automated scanner, mine included, will not settle this for you. Keyboard operability is not reliably machine-detectable: a tool can flag a positive tabindex, an element hidden from assistive technology while still focusable, or a control with no accessible name, and those are worth having. Whether a person can actually complete your checkout without a mouse is a question that still requires a person.

The caveat

I am describing how to evaluate a report, not telling you your site passes. If the audit is right, the fact that it was badly written does not make it wrong — it makes it badly written. Ask for the steps, and then take seriously whatever comes back.

Sources: Understanding SC 2.1.1 Keyboard · WebAIM: Keyboard Accessibility