Accessibility Review in the Design Process: When, Who, and How
Accessibility review happens at every stage, not just at the end. What to check in requirements, design, development, and QA, and how to run it in a sprint.
What does reviewing accessibility at every stage mean?
The idea is known as shift left: moving the check toward the beginning. Digital A11y proposes thinking about accessibility from the start and reviewing designs while they are still sketches, wireframes, or mockups. According to the same article, identifying and fixing problems at a later stage is much more expensive (Digital A11y, “Shift Left Accessibility in Design, Development and Testing”).
Illustrative example with contrast: fixing a gray in Figma can take minutes; fixing it later across twenty components that already live in code, with their tests and deployment, can take days. The same goes for focus order and control names, which depend on structural decisions.
What is checked at each stage?
One possible sequence, based on the sources below:
- Planning. Goals and an accessibility policy are set, responsibilities are assigned, and budget and resources are reserved. That is what the “Plan” phase of the W3C guide describes (W3C WAI, “Planning and Managing Web Accessibility”).
- Requirements. Each user story includes accessibility acceptance criteria. EZUD proposes writing accessibility acceptance criteria into every story, mapping features to WCAG 2.2 success criteria during refinement, and including accessibility effort in estimation (EZUD, “Shift-left accessibility”).
- Design. A review at each milestone, on sketches, wireframes, and mockups. Digital A11y suggests checking semantic structure, font and spacing, focus indicators, color contrast, and link text, and annotating designs with accessibility comments.
- Prototype and testing with people. When the prototype allows it, tests with disabled people. W3C recommends involving them throughout the design and development process. Also review the states that don’t appear in the happy path.
- Development and QA. Automated and manual tests: keyboard, screen reader, contrast, forms. EZUD mentions linting tools that catch issues before code reaches review. Findings are logged as defects and go back to the team.
- Before publishing. A full audit against the target level, confirming what earlier stages already reviewed. The W3C guide also asks you to evaluate “early and regularly,” not only at the end.
Who does what?
W3C publishes a draft resource, ARRM (Accessibility Roles and Responsibilities Mapping), which asks you to assign accessibility responsibilities to roles early in the project and marks them as primary, secondary, or contributor; its example roles are UX designer, visual designer, content author, and front-end developer (W3C WAI, ARRM). A common split on a product team, which you can adapt:
- Design. Annotates and reviews screens: contrast, text size, focus styles, reading order, states, and spacing. It helps to learn WCAG, because many color and hierarchy decisions are design decisions.
- Development. Ensures semantic HTML, correct ARIA use, and keyboard navigation. Code review can include an accessibility checklist.
- QA. Runs automated and manual tests, and logs findings with steps to reproduce them. Screen reader testing is part of the job, and it often needs design’s help to interpret what happens.
- Specialist. Audits against WCAG 2.2 AA, evaluates the fixes, and teaches the team. It can be internal or external.
How does it fit into the sprint?
Accessibility is not a parallel task. EZUD puts it bluntly: it is not optional and not separate from the definition of done. That means a story doesn’t close if it fails its accessibility criteria, just as it doesn’t close if its logic fails.
In practice, that means three things: accessibility criteria written into each story, checks inside the sprint, and findings prioritized like any other defect. A practical rule: findings that stop someone from completing a task are fixed before launch, and the rest go into the backlog with a priority.
Example
Illustrative example: a team adds a payment flow. During refinement, the story includes accessibility criteria: the form can be completed by keyboard alone, errors are announced to screen readers, and the pay button has an accessible name. In design, the milestone review finds that the error appears only in red and that focus order jumps from the card field to the cancel button. Both are fixed before coding. In QA, a screen reader test reveals that the error message isn’t announced because the live region is created after the message. The developer adjusts the region and the test is repeated. None of those fixes required rebuilding the flow.
When this review is not enough
- When only automated tools are used. They detect part of the problems. Manual tests are needed for reading order, meaningful names, and announcements.
- When the review only happens at the end. A last-minute audit finds structural problems that are already in the code.
- When the team has no one responsible. Without an owner, each discipline assumes the other one is doing it.
- When it is used as a compliance stamp. A report without fixes doesn’t make a product accessible.
Common mistakes
- Leaving accessibility until the last week before launch.
- Reviewing only contrast and forgetting focus order and states.
- Testing only with the keyboard and not with a screen reader.
- Not logging findings as defects with a priority.
- Trusting an automated score as a measure of compliance.
How to start tomorrow
Pick a story in your backlog that is in design. Add three accessibility acceptance criteria: keyboard use, accessible names, and error messages announced. Review the design against those three criteria before handing it to development, using axe DevTools for the built version and Stark for the palette. To annotate designs, see accessibility annotations. If your collaboration with development already includes a list of questions, add these three. And for the manual part, screen reader testing is the next step.