EZUD Shift-Left Accessibility: Building It In Early
Shift-Left Accessibility: Building It In Early
“Shift left” is a software engineering principle that moves quality practices earlier in the development lifecycle. Applied to accessibility, it means addressing accessibility in research, design, and early development rather than testing for it after the product is built. The payoff is substantial: fixing an accessibility issue found during design costs a fraction of what it costs to remediate the same issue in a shipped product.
The Cost of Waiting
Research from the Systems Sciences Institute at IBM (often cited in accessibility contexts by Deque and WebAIM) found that fixing a defect found during design costs roughly six times less than fixing the same defect found during testing, and up to one hundred times less than fixing it in production. Accessibility defects follow the same curve.
When accessibility is addressed only at the testing stage, teams face:
- Expensive rework. Retrofitting a navigation pattern that was never designed for keyboard access may require redesigning the component from scratch.
- Schedule pressure. Accessibility issues discovered late compete with launch deadlines. The result is often deferral.
- Technical debt. Deferred issues accumulate, making each subsequent release harder to remediate.
For a detailed cost analysis, see our article on the cost of retrofitting vs. designing accessibly.
What Shift-Left Accessibility Looks Like
In Research
- Include people with disabilities in user research from the start. See user testing with people with disabilities.
- Build inclusive personas that represent diverse abilities, assistive technologies, and contexts of use.
- Use inclusive research methods such as contextual inquiry with assistive technology users.
In Requirements
- Write accessibility acceptance criteria into every user story. Example: “As a keyboard-only user, I can complete the checkout flow without a mouse.”
- Map features to WCAG 2.2 success criteria during backlog refinement.
- Include accessibility effort in estimation (it is not free, but it is far cheaper here than later).
In Design
- Use an accessible design system so that components are accessible by default.
- Annotate designs with accessibility specifications: heading levels, focus order, ARIA labels, color contrast ratios.
- Conduct accessibility design reviews at each design milestone.
- Train designers on accessibility principles and WCAG criteria (see training designers on accessibility).
In Development
- Use semantic HTML and follow the W3C ARIA Authoring Practices Guide for custom components.
- Run automated accessibility checks (axe-core, Pa11y) in the development environment, not just in CI/CD.
- Write unit and integration tests that assert accessible names, roles, and states.
- Train developers on accessibility so they can write accessible code from the first commit.
In Code Review
- Add accessibility to the code review checklist. Reviewers should check for semantic markup, keyboard support, and ARIA usage.
- Automated linting tools (eslint-plugin-jsx-a11y for React, axe Linter for VS Code) catch issues before code reaches review.
Organizational Prerequisites
Shifting left requires more than process changes. It requires organizational investment:
- Training. Designers, developers, product managers, and content creators all need accessibility skills. See our guides for developers, designers, and content creators.
- Tools. Provide teams with automated testing tools, assistive technology for manual testing, and design system components that are pre-validated for accessibility.
- Culture. Accessibility must be treated as a quality attribute, not a feature. It is not optional and not separate from the definition of done.
- Governance. An accessibility governance framework ensures that shifting left is sustained, not a one-time initiative.
Measuring Shift-Left Progress
Track where accessibility issues are found in your lifecycle:
- Issues found during design review (cheapest to fix)
- Issues found during development and code review
- Issues found during QA testing
- Issues found in production or reported by users (most expensive)
As shift-left practices mature, the distribution should move earlier. Report this data through your accessibility metrics dashboards.
Key Takeaways
- Accessibility defects found late cost orders of magnitude more to fix than those caught early.
- Shift-left means embedding accessibility in research, requirements, design, and development, not just testing.
- Accessible design systems, annotated designs, and accessibility acceptance criteria are practical shift-left tools.
- Training, tooling, culture, and governance are organizational prerequisites.
- Track where issues are found in the lifecycle to measure shift-left maturity.
Sources
- https://www.deque.com/blog/shift-left-accessibility/ — Deque analysis of shift-left accessibility economics and implementation
- https://www.w3.org/WAI/planning/ — W3C WAI guidance on planning accessibility into the development lifecycle from the start
- https://webaim.org/articles/ — WebAIM articles on proactive accessibility testing and implementation
- https://www.w3.org/WAI/ARIA/apd/ — W3C ARIA Authoring Practices Guide for building accessible components during development