PRACTICAL ACCESSIBILITY TESTING
How to record useful manual accessibility test evidence
Updated September 28, 2026
A reviewer note should help another tester repeat the check. “Looks fine” does not say which page state, interaction or assistive technology was used. Keep the automated scan result and the human assessment distinct.
Start with a defined scope
Record the page URL, date, tester, browser, operating system and assistive technology with versions. Identify the state: for example, a contact form before submission, a validation error or an open dialog. Do not assume an initial-page scan exercised these interactions.
Use three practical checks
- Keyboard: navigate and operate the relevant controls without a mouse; check that users can leave menus and dialogs.
- Focus: follow its order and visibility, including after opening or closing a dialog.
- Screen reader: check useful control names, roles and states, headings, instructions, and relevant error or status information.
These are starting points, not an exhaustive audit. W3C's Easy Checks explains preliminary accessibility review and its limits.
A reusable evidence record
Page and state:
Tester and date:
Browser / OS / assistive technology:
Check and scope:
Steps to reproduce:
Expected behavior:
Actual behavior:
Outcome: Pass / Fail / Not applicable / Not reviewed
Evidence reference:
Retest date and result:
Write an outcome that another person can verify
Fictional example: “Contact form, error state. Tab to the empty email field, activate Submit, then return to the field. Expected: the error is available with the field. Actual: only the field name is announced; the visible error is not associated. Fail for this check in the recorded browser/screen-reader combination.” Record your actual observations and environment rather than copying this example as test evidence.
Keep reviewer decisions separate from automation
In a saved GatekeeperQA report, use Saved tester review to record notes and outcomes. Download a reviewed copy to retain that evidence. A saved note does not change the original automated result, and a manual Pass applies only to the stated scope.
After a fix, repeat the same steps, rescan where relevant and retain the original and retest records. If a component was absent or could not be reached, record that limitation instead of declaring a pass. Keep credentials and personal form values out of shared evidence.
Read the report interpretation guide or practice with fictional reviewer notes.
Continue your workflow
Run accessibility checks in GitHub Actions · Scan an authorized page
Automated checks support manual assessment; these examples do not certify conformance.