Test a web page with a keyboard: a beginner exercise
Keyboard testing checks whether a person can follow a defined web task without a mouse. Pick a short path, use Tab and Shift+Tab to move between controls, activate them with the appropriate key and record what happens. This exercise helps beginners notice barriers; it is only part of a broader accessibility review.
Keyboard testing checks whether a person can follow a defined web task without a mouse. Pick a short path, use Tab and Shift+Tab to move between controls, activate them with the appropriate key and record what happens. This exercise helps beginners notice barriers; it is only part of a broader accessibility review.
Key ideas
- The keyboard task has a start and an end.
- The browser and public URL are recorded.
- Every required control is reachable.
- The focused element is visually identifiable.
Start with a real journey
Choose a small task such as opening a lesson, reaching a file link and returning to the course page. Write where the journey starts and how success will be recognised. Test the public page rather than a design screenshot. Close unrelated dialogs before you begin, then repeat with a dialog open if it is part of the task. Record the browser and page address so someone else can attempt the same check.
Watch where focus moves
Press Tab slowly and identify the focused control at each step. Can you see the focus indication? Does the sequence make sense? Use Shift+Tab to move backwards. A decorative element should not create an unnecessary stop, while an actual button or link needs to be reachable. W3C Easy Checks describes keyboard focus as an initial accessibility check; this worksheet turns it into a small learning task.
Check purpose and operation separately
A reachable link can still have an unclear label. Write what you expect before activating it, then compare the destination. Buttons and links have different purposes; MDN’s HTML accessibility material explains why native elements matter. If something opens a panel, check whether you can continue and return. Record the observed failure instead of guessing which code change will solve it.
Make a repair and repeat the same path
Choose one barrier and create a specific correction, such as a descriptive label or a visible focus style. Repeat the original journey after the change. Save both observations. Do not declare the whole website accessible because one path now works: screen-reader use, contrast, content structure and other tasks still need review. The outcome is a reproducible finding and a checked repair within a limited scope.
Your evidence checklist
Mark only what you have checked. This records your own progress, not an independent audit or a predicted result. There is no automatic saving; download the note if you want to keep it.
0 / 6 checked
In everyday language
A useful accessibility finding describes a real barrier, a reproducible task and the result after a repair.
Try it yourself
Test a course page and a linked practice file without a mouse. Record one unclear or blocked step, describe the expected behaviour, make a small correction and repeat the path.
Expected result
A before-and-after test record for one journey, including the page, browser, action and observed result. This is not a full compliance report.
Check your answer: Does passing this exercise prove WCAG compliance?
No. It covers a small keyboard journey and cannot establish complete accessibility. W3C’s initial checks are designed to reveal some issues. A broader review needs additional criteria, tasks and assistive technologies, with the scope stated clearly in its findings.
Questions
Does passing this exercise prove WCAG compliance?
No. It covers a small keyboard journey and cannot establish complete accessibility. W3C’s initial checks are designed to reveal some issues. A broader review needs additional criteria, tasks and assistive technologies, with the scope stated clearly in its findings.
Should I report a problem if I do not know its code cause?
Yes. A precise observation is useful before a diagnosis. State the page, action, expected behaviour and result. Avoid presenting a guess as a confirmed technical cause. A developer can then investigate while you keep the test reproducible.
A useful accessibility finding describes a real barrier, a reproducible task and the result after a repair.
Sources and further reading
- W3C WAI — Easy Checks ↗Sources checked:
- MDN — HTML accessibility ↗Sources checked: