The Problem
Many teams treat accessibility as something to address "later" or in a dedicated sprint. This approach fails because accessibility issues compound. Fixing them retroactively takes 10x longer than building them in from the start.
Shifting Left
"Shifting left" means moving accessibility considerations earlier in your development process. Here's what that looks like in practice:
During Sprint Planning
- Add accessibility acceptance criteria to every user story that involves UI
- Example: "As a keyboard user, I can navigate and activate all controls in this feature without using a mouse"
- Include accessibility in your definition of done
During Design
- Review designs for color contrast, focus indicators, and logical tab order
- Annotate designs with accessibility notes (heading levels, ARIA labels, alt text)
- Use your design system's accessible component library
During Development
- Write semantic HTML first, then add styles
- Test keyboard navigation as you build
- Run axe or similar tools in your browser dev tools during development
- Flag accessibility issues in code review just like you would flag a bug
During QA
- Add screen reader testing to your test scripts
- Verify keyboard navigation for every interactive element
- Test with browser zoom at 200%
- Check that dynamic content changes are announced to assistive technology
Sample Acceptance Criteria
For a "Add to Cart" button:
- Button is focusable via keyboard
- Button has a descriptive accessible name
- Screen reader announces the action result
- Focus is managed appropriately after the action
- Color contrast meets WCAG 2.2 AA requirements
The Payoff
Teams that integrate accessibility into their regular workflow spend less time on remediation, ship more inclusive products, and avoid the costly scramble of a pre-launch accessibility audit that finds hundreds of issues.