What the reader needs

Choose one complete task, such as opening an article and sending an enquiry. Navigate it using the keyboard alone. Check whether links, menus, buttons and form fields can be reached in a sensible order, whether the current focus is visible, and whether any overlay traps the user. W3C’s keyboard guidance explains why this matters; the practical review should use the same content and controls a real visitor encounters.

How to review it

Write down the exact point where progress becomes unclear or impossible. Give the implementation team a reproducible sequence rather than a general comment that the page feels inaccessible. Retest after changes, including any mobile menu or modal that uses a different interaction. Keyboard testing is a useful check, not a complete accessibility certification. Combine it with other reviews and user feedback, and avoid claiming conformance merely because one journey worked on one browser.

Imagine this

Hypothetical example

A magazine’s enquiry button opens a modal, but keyboard focus remains behind it. The reviewer records the steps and the team corrects the focus behaviour. A second test confirms the form can be completed and closed without reaching for a mouse.

Make it practical.

Use this checklist as you read. Checks are not stored.

References & further reading

Further reading: W3C WAI: Keyboard compatibility ↗

Published by Tap Tap Go. Product availability and eligibility vary by programme and market. About our stories.