What is this?
This tool provides a structured template for recording accessibility user testing sessions, testing with real disabled users. User testing is the most valuable form of accessibility evidence.
When do I need this?
Use this when conducting user research sessions with disabled participants, or when reviewing usability testing that included accessibility tasks.
Applies to:Any product undergoing user testing that includes accessibility tasks or disabled participants.
- 1Set up the session record, Enter the date, participant's disability and assistive technology used, browser, and OS.
- 2Record tasks and outcomes, For each task you tested, record whether the participant completed it, any issues they encountered, and direct quotes.
- 3Note severity, For each issue found, record severity: critical (task failure), serious (significant difficulty), moderate (workaround needed), or minor.
- 4Capture participant quotes, Direct quotes from participants are powerful evidence in a Technical File and for development teams.
- 5Export your session log, Download the completed log for your compliance file. Multiple logs build a strong evidence base.
Blank checklist, printable form
User Testing with Disabled Participants, Checklist
Testing Methodology & Documentation Checklist
Blank checklist for offline completion.
Tick one box per row. Add comments and evidence references in the Notes column as needed.
Participant Recruitment & Representation
Ensure participant panels are representative of disabled end-users and that recruitment practices are ethical and documented.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 Annex C | Critical | A minimum of 2 participants per disability profile are recruited for each testing round.Single-participant testing per profile does not produce reliable findings. Two participants per profile is the minimum to identify patterns versus individual preferences. Larger panels are preferred for critical services. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 Annex C | Critical | Disability profiles include vision, hearing, motor, and cognitive impairments.Testing must cover the four major disability categories. Within each category, consider sub-profiles (e.g. Low vision vs blind, d/Deaf vs hard-of-hearing). The specific profiles selected should reflect likely end-users of the product. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 §5.1 | Major | Participants use their own assistive technology during testing sessions.Asking participants to use unfamiliar AT introduces confounding variables. Users should bring their own devices and AT (screen readers, switches, magnifiers) configured to their preferences. If remote testing, confirm participants are using their everyday setup. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EAA Article 15 | Major | Participants receive fair compensation for their time.Unpaid testing exploits disabled participants and may bias recruitment toward those with fewer options. Compensation should be at least equivalent to market rates for usability testing. Payment must be accessible (e.g. Bank transfer, not only gift cards to inaccessible platforms). | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EAA Article 15 | Critical | Informed consent is documented for each participant, covering data use, recording, and anonymisation.Consent forms must be accessible (not image-only PDFs). They must explain what data is collected, how sessions are recorded, how findings are anonymised, and how participants can withdraw. Provide consent forms in advance so participants can review with their AT. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Testing Methodology
Verify that the testing approach is structured, reproducible, and appropriate for accessibility evaluation with disabled participants.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 Annex C | Critical | Defined task scenarios cover all critical user journeys.Task scenarios should cover the end-to-end journeys that matter most: registration, login, core functionality, payments, support. Tasks must be written in plain language and be achievable within session time. Avoid leading participants toward specific UI elements. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 Annex C | Major | Tasks match the scope of the accessibility assessment (same pages, components, and flows).User testing should validate the same scope as the conformance assessment. If the WCAG audit covers 20 pages, user testing tasks should exercise those same pages. Misaligned scope means testing results cannot be correlated with audit findings. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 Annex C | Major | Think-aloud protocol or structured observation method is documented and followed.The facilitation method must be defined before testing begins. Think-aloud protocol asks participants to verbalise their thoughts while performing tasks. Alternatively, retrospective interviews or structured observation with a predefined rubric are acceptable. The method must be consistent across all sessions. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EAA Article 15 | Major | Sessions are recorded (with participant consent) for evidence and later analysis.Recordings provide evidence for enforcement bodies and allow the team to review findings in detail. Both screen and audio should be captured. If participants decline recording, detailed contemporaneous notes must substitute. Recordings must be stored securely with restricted access. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 Annex C | Major | Testing is helped by an independent person, not the product developer or designer.Developers and designers have inherent bias and knowledge of the product that can lead them to unconsciously guide participants. The facilitator should be someone who did not build the feature being tested. External accessibility consultants or trained UX researchers are preferred. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Findings Documentation
Ensure barriers discovered during user testing are documented with sufficient detail for remediation and regulatory evidence.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EN 301 549 Annex C | Critical | Each barrier documented with: disability profile, AT used, task attempted, barrier description, and severity.A finding without context is not actionable. Each documented barrier must state which participant profile encountered it, what AT was in use, which task was being attempted, a clear description of the barrier, and a severity rating (critical / major / minor). This structure enables prioritised remediation. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| WCAG 2.2 | Major | Each finding is linked to the relevant WCAG success criterion.Linking user testing findings to WCAG success criteria connects real-user evidence to normative requirements. This strengthens conformance claims and helps developers understand which requirement is affected. If a barrier does not map to a specific SC, document it as a usability issue outside WCAG scope. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EAA Article 15 | Minor | Participant quotes are included in findings (anonymised).Direct quotes from participants provide powerful qualitative evidence. They illustrate the human impact of barriers and are compelling in regulatory submissions and stakeholder presentations. All quotes must be anonymised (e.g. 'Participant B3, blind, JAWS user'). | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 Annex C | Major | Success rate per task per disability profile is recorded.Quantitative success rates complement qualitative findings. For each task, record how many participants in each disability profile completed it successfully, partially, or not at all. This data reveals which journeys are most problematic and for which user groups. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |
Follow-Up & Remediation Verification
Confirm that user testing findings drive remediation and that fixes are validated through re-testing.
| Ref | Severity | Requirement | Status | Notes / Evidence |
|---|---|---|---|---|
| EAA Article 15 | Critical | Re-testing is planned after remediation of identified barriers.User testing without follow-up re-testing is incomplete. A re-testing round should be scheduled after developers address the critical and major findings. The re-test plan should specify timelines, scope (which fixes to validate), and participant requirements. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 Annex C | Major | The same participants (or same disability profiles) are invited for re-testing.Re-testing should involve participants with the same disability profiles as the original round to ensure fixes are validated by the affected user groups. Ideally, the same individuals participate to provide continuity. If original participants are unavailable, recruit replacements with matching profiles. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EAA Article 15 | Critical | Findings are shared with the development team within 5 working days of testing completion.Delayed reporting reduces the likelihood of remediation. Critical barriers should be communicated immediately; the full report should follow within 5 working days. Use accessible formats and include enough technical detail for developers to reproduce and fix each barrier. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EN 301 549 Annex C | Major | User testing findings are integrated into the self-assessment or conformance evaluation results.User testing should feed into the formal accessibility assessment. WCAG conformance claims should be informed by real-user evidence, not just automated and expert testing alone. Where user testing reveals barriers that expert testing missed, the assessment must be updated. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EAA Article 15 | Major | User testing is repeated annually or after any major product release.A single round of user testing does not provide ongoing assurance. Testing should be conducted at least annually and triggered by major releases that affect accessibility-relevant functionality. Document the testing cadence in the accessibility policy. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A | |
| EAA Article 15 | Minor | Testing report is available for market surveillance authorities upon request.Enforcement bodies may request evidence of user testing as part of market surveillance. The report must be stored securely, be retrievable within a reasonable timeframe, and contain sufficient detail to demonstrate compliance with EAA Article 15 technical documentation requirements. | ☐ Pass ☐ Partial ☐ FAIL ☐ N/A |