Digital accessibility
Accessibility audits that lead to actionable fixes
Evaluate the journeys people need to complete, document the barriers and prioritise remediation. We agree the WCAG target, product scope and testing conditions before making statements about the results.
- An evidence-based findings report
- A prioritised remediation backlog
- A traceable retest record
Start from the barrier, not the score
An accessibility engagement should identify the product decision or task that needs attention. Three common starting points:
A scan passed, but a task is blocked
A tool cannot explain the whole experience. Review keyboard navigation, focus, labels and recovery through complete tasks such as signing in, submitting a form or completing a lesson.
New features reintroduce old barriers
Trace repeated issues to shared components, content templates and interaction patterns. Fixing their source can make maintenance more manageable than repeating page-by-page patches.
The team needs a usable plan
A list of automated warnings is not a delivery plan. Findings need a location, reproduction steps, user impact and a proposed correction that designers and developers can review together.
An evaluation with a defined scope
Our approach draws on W3C WAI evaluation guidance. The depth of the review, included journeys and assistive-technology baseline are agreed for the specific product.
W3C WAI: evaluating web accessibilityDefine the scope and target
Record the product version, WCAG version and level, roles, environments and exclusions. Identify the critical processes and agree which screens and states will be evaluated.
Explore the real product
Identify shared templates, forms, dialogs, media and dynamic states. When sampling is necessary, include representative examples and complete processes rather than only the easiest pages.
Combine tools with human review
Use automated checks alongside manual examination of the agreed sample. Keyboard and assistive-technology checks follow the testing baseline. Sessions with disabled participants can be scoped separately.
Report, remediate and retest
Prioritise barriers, implement the agreed fixes and record the retest. Report which conditions were checked and what remains open; a sample review does not establish conformance for an entire product.
What the review should leave with your team
An evidence-based findings report
Scope, sample, testing conditions and findings linked to the agreed criteria, with reproduction steps and known limitations.
A prioritised remediation backlog
Issues grouped by component or flow, with user impact and recommended changes. Implementation effort and ownership can be agreed with your team.
A traceable retest record
For agreed fixes: what changed, what was retested, which states were covered and which issues remain open.
Accessibility in product design
EduSpera: access needs inside the learning journey
Captions and transcripts, adaptable reading and clear course context show how accessibility influences product decisions. The EduSpera case study explains those choices and distinguishes implemented functionality from its editorial research framework.
Explore accessibility decisions in EduSperaProduct-design evidence; this case study is not a conformance certificate.
Which journey needs an accessibility review?
Share the product URL, important user tasks and any existing audit. We can discuss a useful first scope from that context.