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:

• the element, and what you were trying to do with it
• the steps to reproduce
• expected result versus actual result
• browser, operating system, and which assistive technology at which version

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:

• Content that only appears on hover. Your pointer is gone, so you never see it, and neither does a keyboard user. (Related: 1.4.13 Content on Hover or Focus, AA.)
• Anything that needs a drag. Sliders, reorderable lists, map panning. WCAG 2.2 added 2.5.7 Dragging Movements (AA) precisely because this kept happening.
• Composite widgets where Tab reaches the component but the arrows inside it were never wired up. A custom listbox or tab set you can enter and cannot navigate.
• Modals that open fine and cannot be closed without a pointer. That is 2.1.2, and it is the single most common serious keyboard defect I see.
• Anything below a keyboard trap, which you will never reach, and whose absence from your notes looks like a pass.

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