The Problem
You ship a feature. A user with a screen reader can't navigate it. Another user says "I can't use this with keyboard only." You get labeled insensitive. You fix it 3 months later.
You didn't think about accessibility. Now it's a reputation problem.
The Trap
Many PMs see accessibility as a nice-to-have or a legal obligation ("We need to be ADA-compliant"). This is both incomplete and wrong.
Incomplete: Accessibility is 15-20% of your addressable market, including aging users, users with temporary disabilities (broken arm, low vision from bright sun), and users in noisy/quiet environments who can't use audio.
Wrong: Accessibility isn't about compliance. It's about usability for all users.
The Shift
Think of accessibility as "can all users, regardless of ability, accomplish their goals?"
This means:
- Keyboard navigation (no mouse-only flows)
- Screen reader support (semantic HTML, descriptive alt text)
- Color contrast (readable for color-blind users)
- Motion (no auto-playing animations that trigger vestibular issues)
- Resizable text (zooming should work)
Actionable Steps
1. Define WCAG Target Level
Most products target WCAG 2.1 AA (industry standard). Spec it:
Accessibility Target: WCAG 2.1 AA compliance
- All interactive elements keyboard-accessible
- All images have descriptive alt text
- Color contrast ratio ≥ 4.5:1 for text
- No content restricted to pointer/hover alone
- Forms labeled and error messages descriptive
2. Create an A11y Checklist for Features
For every new feature:
| Element | Requirement | How to Test |
|---|---|---|
| Buttons | Labeled, keyboard-focusable, tab-ordered | Tab through all buttons; test screen reader |
| Images | Alt text descriptive (not "image.jpg") | Screen reader reads aloud |
| Forms | Label + error messages | Keyboard + screen reader navigation |
| Color | Contrast ≥ 4.5:1 | Use WebAIM contrast checker |
| Motion | No auto-play; can be disabled | Check settings; disable animations |
3. Involve Users Early
Don't spec in a vacuum. Talk to users:
- Blind users (screen reader preferences)
- Users with motor disabilities (what keyboard patterns work)
- Users with cognitive disabilities (clarity, not complexity)
4. Build Into Definition of Done
Acceptance criteria for every feature:
Acceptance Criteria:
- Feature works via keyboard (Tab, Enter, Esc)
- Feature works with NVDA screen reader (Windows)
- Features works with VoiceOver (Mac)
- No WCAG 2.1 AA violations (test with axe DevTools)
5. Document Exceptions (if any)
Some features genuinely can't meet WCAG AA. Document why and what workaround exists:
Accessibility Exception: [Feature X]
- Issue: Interactive map requires precise pointer control
- WCAG Level: AAA (impossible without alternate interaction)
- Workaround: List view of results for keyboard users
- Timeline: Redesign Q4 to support both
Key Takeaways
- Accessibility is a feature, not a compliance task. Spec it upfront; building it in is cheaper than retrofitting.
- 15-20% of users have accessibility needs. You're not being nice—you're serving your market.
- Universal design is better design. Curb cuts help wheelchair users and people with strollers and deliveries. Accessible UX is just better UX.