Template preview · Software
Accessibility evaluation
Record an evidence-based accessibility evaluation and remediation path.
A manual evaluation report for a defined product surface.
Sample purpose
Record an evidence-based accessibility evaluation and remediation path.
Audience: Accessibility specialist, QA lead- Structure
- 4 sections
- Criteria
- 15
- Sources
- 11
- Watches
- 5
- Default approach
- Review first
Set the purpose first. Then change every section, criterion, and agent setting before anything runs.
Fictional sample
Structure and criteria
Sample content shows the shape of a useful document. Copying it is optional.
01 Review firstScope and method
State the evaluated surface and manual method.
Criteria
- Names specific flows (not 'the product') and at least three methods, e.g. keyboard only, 200% zoom, NVDA
- States the target standard (WCAG 2.1 AA) and the date
- Names at least one flow or component left out, with a reason
- States what was manual and what was tool-assisted
Sources
- W3C evaluation report template w3.orgStructure for scope and method statements.
- WebAIM screen reader testing webaim.orgWhat screen reader testing does and does not cover.
- WCAG 2.1 quick reference w3.orgSuccess criteria in scope.
Watches
- Checks w3.org monthly
Agent may read w3.org, webaim.org.
Sample content
Evaluation covers the fictional Transit Nest trip-alert signup flow on 2026-02-11 using keyboard navigation, zoom at 200%, and a screen reader spot check.
02 Review firstFindings
Record reproducible barriers and their impact.
Criteria
- Each finding has exact reproduction steps and the assistive technology or technique used
- Names the affected user and the outcome they cannot complete
- Severity follows task impact (blocked is High), not technical effort
- Contains no finding found only by an automated tool
Sources
- WCAG 2.1 success criteria w3.orgCriteria to map each finding to.
- WebAIM articles webaim.orgPractical examples of barrier impact.
- Transit Nest findings archive (fictional) api.transit-nest.exampleEarlier findings, to avoid re-reporting and to calibrate severity.
Watches
- Follows Scope and method
Sample content
Finding Impact Severity Focus disappears after station search. Keyboard user cannot reach alert frequency. High Error color lacks text cue. Some users miss correction guidance. Medium 03 ManualRemediation plan
Turn findings into owned, testable changes.
Criteria
- Each item links to one finding and names an owner
- Verification repeats the method that exposed the barrier (keyboard, zoom, screen reader)
- High severity items have a due date; deferred items are listed, not dropped
Sources
- ARIA Authoring Practices Guide w3.orgCorrect patterns for components like comboboxes and focus handling.
- WebAIM ARIA guide webaim.orgCommon ARIA mistakes to avoid when fixing.
- Transit Nest accessibility patterns (fictional) api.transit-nest.exampleApproved internal component patterns.
Watches
- Follows Findings
Sample content
- ☑ Mira restores focus to frequency control; verify with keyboard test
- ☑ Dev adds text error cue; verify at 200% zoom
04 Review firstEvaluation status
Show the scope and remediation state without overstating coverage.
Criteria
- Counts open findings by severity with a trend, not one total
- Shows coverage as a ratio of flows or pages checked
- Gives the date of the last manual re-test
- Makes no conformance claim without a full evaluation
Sources
- WCAG 2.1 conformance w3.orgWhat a conformance claim requires.
- Transit Nest compliance trends (fictional) api.transit-nest.exampleRe-test completion across the product.
Watches
- Follows Findings
- Follows Remediation plan
Sample content
- High severity open
- 1
- Flows manually checked
- 1 of 1