Perspective

I can't get to it without a mouse or touchscreen

An action is visible and usable with a pointer, but cannot be reached or operated through the keyboard.

A control can work perfectly when clicked and still be unavailable through another input method.

Interface demands

These describe what the interface requires from the person in this barrier. They are not disability categories and do not imply that everyone affected has the same experience.

What happens

A person navigating by keyboard reaches part of the interface and then cannot move to an action, cannot operate it, or becomes trapped inside a component.

This can also expose custom controls whose visual appearance suggests interactivity but whose underlying element is not actually keyboard-operable.

Why it matters

Keyboard access is important in its own right and is also foundational to many alternative input and assistive-technology interaction patterns.

How to test it

Put the pointer aside.

Start at the beginning of the page or flow and use the keyboard to:

Do not test only by repeatedly pressing Tab. Some native widgets have their own expected keyboard interaction patterns.

Can automation detect it?

Partially.

Automation can catch some structural problems, but it cannot reliably prove that a complete workflow is keyboard-operable or that focus behaviour makes sense.

Relevant WCAG

This barrier commonly relates to:

Other criteria may apply to the actual failure, including focus order and focus visibility.

What a pass does not prove

Keyboard completion does not prove that screen-reader output is useful, that speech input works, or that the interaction is cognitively understandable.

Follow the evidence trail