Define the scope
Record the pages, screens, documents, and states you will review. Include instructions, errors, confirmations, and any third-party steps in the task.
PRACTICAL ACCESSIBILITY TESTING
Testing and practical guidance
Plan an accessibility review, document useful findings, and verify changes with a repeatable workflow.
PLAN THE REVIEW
Start with a task. Follow the whole journey.
Choose something people need to accomplish, such as completing an enquiry or finding information in a document. These starting points help uncover barriers; they are not a complete accessibility audit.
Combine methods
Use automated checks alongside keyboard review and other manual checks. Include assistive technologies relevant to the experience, and involve people with disabilities to understand how barriers affect real tasks.
Keep the context
Record the browser, device, software versions, and settings used. Note what you tested and what remains outside the review so others can understand the limits of the results.
A passing tool result is a starting point
No single tool can determine whether an experience is accessible. Human evaluation is needed, and a short set of checks can miss significant barriers.
Explore W3C WAI’s evaluation resources (opens in a new tab)MAKE FINDINGS ACTIONABLE
Describe the barrier so someone can reproduce it.
A useful finding connects an observed problem to its impact on a task. Include a clear location, repeatable steps, actual behaviour, and the expected result. Add supporting evidence and the relevant accessibility requirement when you have verified it.
Example: a menu that cannot be opened
This illustrative finding concerns a website’s main navigation. The menu opens with a mouse, but a person using a keyboard cannot reveal its links.
Record the exact page address and testing environment with the finding. A screenshot or short recording can support the explanation, but the written steps should stand on their own.
Example finding
- Steps to reproduce
- Load the page. Use Tab to reach the menu button. Press Enter, then repeat with Space.
- Observed behaviour
- The menu stays closed with both keys.
- Expected behaviour
- The menu button opens the navigation using the keyboard, and its links can be reached and activated.
- Impact
- People who navigate with a keyboard cannot reach pages available through this menu.
CHECK THE OUTCOME
Retest the task, then check nearby behaviour.
A code change is ready for verification when you can repeat the original test. Check whether the barrier is resolved and whether the complete task now works.
Keep the original finding and add the retest date, environment, evidence, and outcome. If the issue remains, describe what still prevents completion.
For a first review, W3C WAI’s Easy Checks (opens in a new tab) offers practical prompts. It does not replace a comprehensive evaluation.
A practical retesting sequence
- Repeat the original steps in the recorded environment.
- Check the expected result, including focus, instructions, and feedback where relevant.
- Complete the surrounding task and check related controls for unintended changes.
- Record the result as resolved, partly resolved, or still present, with evidence.
KEEP LEARNING
Continue with another guide.
Build on this topic, browse all resources, or talk with us about your work.