Checklist

Complete the journey with the keyboard alone

Being able to reach a button is not the same as finishing the task.

When it fits

A feature works with a mouse but keyboard access has not been checked.

When to avoid it

Some path-dependent input has specific exceptions. This small check does not replace assistive-technology testing or a full accessibility evaluation.

Checklist

Can you reach and operate every control needed for the task?
Can you tell where focus is and follow a sensible order?
Can you leave a dialog or recover from an error without using the mouse?

Why it matters

Try a meaningful journey without the pointer: start, edit, submit, recover and leave. Observe focus and available actions at each step. A keyboard check should expose a blocked task, not merely count controls reached by Tab.

An example

A recording dialog opens from the keyboard, but its close control cannot be reached. The journey fails despite a working Start button.

Check your result

Can a fresh tester complete and exit the chosen task without pointer assistance?

Keep this limit in mind

Some path-dependent input has specific exceptions. This small check does not replace assistive-technology testing or a full accessibility evaluation.

Connected ideas

Evidence and sources

Supports

WCAG 2.1.1 requires functionality to be operable through a keyboard interface, with an exception for input that depends on the path of movement.

This card inspects ordinary interface tasks, not every path-dependent interaction or accessibility criterion.

Understanding Success Criterion 2.1.1: Keyboard · Success criterion and intent.

All sources (1)

Understanding Success Criterion 2.1.1: Keyboard