Accessibility testing: follow a keyboard-only enquiry journey
Prepared with AI assistance and linked primary sources. Examples are illustrative unless stated otherwise.
Test accessibility by following a complete user task and recording where it becomes difficult or impossible. For an enquiry form, check navigation, understandable labels, error recovery and confirmation. Use automated scans as supporting evidence, alongside manual checks and feedback from people who use assistive technology.
Choose a journey you can finish
This evergreen lesson covers the October 2 slot and was first published on October 5, 2026. Use a local practice form or a staging page you are allowed to test. Do not send fake enquiries to a live business. The fictional task is to choose a course, enter contact details, correct a mistake and receive confirmation.
Write the expected journey as a short story before listing checks. The learner should be able to find the form, understand each field, change a choice and recover from a rejected value. This framing gives each observation a purpose: the issue matters because it prevents or complicates something the learner is trying to accomplish.
Move through the page using the keyboard
W3C's introductory checks cover visible keyboard focus, headings, page titles and zoom among other topics. Treat them as starting points for evaluation. For this exercise, put the mouse aside and use Tab and Shift+Tab to move between interactive controls. Record the sequence and whether the current control is visibly identifiable.
Open the course selector using its supported keyboard controls and choose an option. Continue to the form fields and submit control. If focus disappears or you cannot escape an open menu, record the exact preceding action. Describe the control and browser state rather than writing only that keyboard support is broken.
Check labels and recover from one mistake
Enter a fictional name, leave the email field incomplete, and submit in the practice environment. Observe whether the error explains what to fix and whether you can reach the affected field. Correct only that value and check whether other entered values remain available. A recovery path that deletes valid work deserves a separate observation.
Inspect whether controls have clear, persistent labels and whether required-field instructions are understandable before submission. Use an available screen reader for an additional pass and record its name and version. If you have not tested with a screen reader, state that plainly; seeing a label on screen is not evidence that it is announced correctly.
Add a scan at meaningful page states
Playwright's accessibility guide describes integrating @axe-core/playwright and explains that automated checks detect only some issues. In an existing Playwright project, navigate to the practice page, wait for the form, and run an AxeBuilder analysis. Save the violation output with the page state rather than reporting only a total score.
Repeat the scan after opening an interactive panel or displaying validation errors, because the visible interface has changed. Keep the initial, error and success states distinguishable in the report. Investigate each finding and reproduce it where possible. A scan of the initial page alone provides no evidence about a confirmation message that did not yet exist.
Record a defect someone else can reproduce
Create one issue with a concise title, test URL, browser, viewport, keyboard sequence, expected behaviour and observed result. For example, a hypothetical defect could say that focus remains behind the open course selector and prevents selection. Label the example as fictional until you have reproduced it in your own practice page.
Zoom the browser to 200 percent and repeat the journey, noting clipped instructions or controls you cannot reach. Save a screenshot as context, but include written steps because a picture alone cannot show the focus sequence. After a correction, rerun the failing step and the rest of the journey to look for regressions.
Describe the coverage honestly
W3C explains that no evaluation tool alone can determine whether a site meets accessibility standards. A useful report therefore names the pages, states and methods covered, and the work still outstanding. This short enquiry exercise is not a conformance audit and should not be presented as certification of an entire website.
Finish with three pieces of evidence: a completed keyboard journey, a defect and retest record if you found one, and the automated results with their limitations. Add user feedback when available. These habits fit a QA portfolio because they show observation and communication, and can be extended through the related AI-Powered QA / SDET program.
Sources and further reading
- W3C WAI: Easy Checks, a first review · checked 2026-10-05
- Playwright documentation: Accessibility testing · checked 2026-10-05
- W3C WAI: Evaluating Web Accessibility · checked 2026-10-05
Spot an error? Email info@spothub.in with the article link and correction.