Updated 6 October 2026. An accessibility test should explain what was checked, how a problem can be reproduced and whether a repair lets the user finish the task. This workflow gives a small team a practical way to combine automated checks with keyboard, visual and screen-reader review.
For deciding ownership and allocating repair time, see our website accessibility priorities and budgeting guide. The steps below are an editorial testing framework, not a record of a completed audit or a certification.
1. Create a small, representative test set
Include the homepage, an article or product page, a navigation menu, a form and its success and error states. Add any consent dialog, search interface or document needed for the journey. Select examples from each shared template, including an unusually long title and a page with a table or embedded media.
Record the URL, browser, viewport, zoom setting and any assistive technology used. Repeat the same task after a repair so that the result is comparable. A test of one article should not silently become a claim about every page.
2. Run an automated check and triage the findings
A browser tool can identify potential problems in the rendered page. The free axe DevTools extension provides automated testing of individual pages. Inspect each reported element and reproduce the issue before creating a repair ticket.
W3C’s guidance on evaluation tools explains why automation needs human judgement and cannot determine accessibility on its own. An empty automated report is a starting point for manual testing, not evidence that the complete journey conforms.
3. Complete the journey using only a keyboard
Begin at the top of the page and use Tab and Shift+Tab to move through controls. Activate links and buttons with their expected keys. Open the menu, reach the form, submit it with a deliberate missing value, correct the error and reach confirmation.
- Can you see which control has focus?
- Does focus move in an understandable order?
- Can you enter and leave each dialog without becoming trapped?
- After a dialog closes, does focus return to a useful place?
- Does sticky content cover the focused control?
Record the exact sequence that fails. “The menu is inaccessible” is less useful than “After opening the menu with Enter, Tab moves behind the overlay and the Close control cannot be reached.”
4. Check enlarged text, layout and contrast
W3C’s Easy Checks offers an initial review of headings, contrast, images, forms and resizing. Enlarge the page and check that the text remains readable and controls usable. Inspect links, field errors, disabled states and text placed over images, not just the default paragraph style.
For specific requirements, consult the WCAG 2.2 Quick Reference. Level AA text contrast is generally at least 4.5:1, or 3:1 for qualifying large text, with defined exceptions. Text resizing up to 200% and reflow at a width equivalent to 320 CSS pixels address different checks; test both where applicable.
5. Review the task with a screen reader
Use a screen reader and browser combination your team can support. Navigate by headings and landmarks, inspect the list of links, then operate the form. Listen for meaningful control names, field labels, required-field information and errors. Check whether important updates are announced without forcing the user to search for them.
An image description should communicate its purpose in context. A decorative image should not interrupt the reading experience with irrelevant information. A meaningful diagram may need an explanation beyond a short label. Have an experienced tester review uncertain results rather than interpreting unfamiliar output as a definite defect.
6. Save a reusable regression record
| Record | Example entry |
|---|---|
| Task and state | Enquiry form with the email field left empty |
| Reproduction steps | Reach Submit using the keyboard, activate it, then locate the error |
| Observed result | Describe what actually happens; attach a screenshot or recording |
| Acceptance check | The error is identified and the user can correct it and submit |
| Owner and retest | Name the responsible team member and record the tested environment |
This is an illustrative record format. Replace the example with your own evidence, retest the affected component in the representative pages and include it in the next release check. Track manual findings alongside automated ones so that a later clean scan does not erase unresolved user barriers.
