The Real Cost of Ignoring Accessibility

Scenario: Search Feature Launch

You launch search feature. No accessibility consideration.

Week 1: PM emails from blind user: "Your search is unusable for me. I can't see the autocomplete suggestions."

Week 2: Another user: "I can't use keyboard to navigate search. Arrow keys don't work."

Week 3: Accessibility review (before enterprise customer signs): "Search fails WCAG AA. We can't use this product."

Result:

  • Feature feels broken for users with disabilities
  • Enterprise customer blocks (compliance requirement)
  • 2-week rework to fix accessibility
  • Reputation damage (user publicly tweets complaint)

Cost: $50K lost deal. 2 weeks of engineering. Negative PR.

If spec'd upfront:

  • Built keyboard navigation from day 1
  • Built screen reader support in from day 1
  • No rework needed
  • Zero cost

Framework: Accessibility-First Specification

WCAG 2.1 Three Levels

WCAG A (Minimum):
- Adequate color contrast (3:1 for large text)
- Keyboard accessible
- Alt text for images

WCAG AA (Standard - Most Products Target This):
- Enhanced contrast (4.5:1 for normal text)
- Keyboard accessible + logical tab order
- Descriptive alt text
- Form labels + error messages

WCAG AAA (Gold Standard - Complex Interfaces):
- Enhanced contrast (7:1)
- Audio descriptions for videos
- Sign language interpretation
- Simplified language available

Recommendation: Spec WCAG AA as minimum. It's standard across industry and covers 95% of accessibility needs.

Four Pillars of Accessibility

PILLAR 1: PERCEIVABLE (Users can see/hear content)
- Images: Descriptive alt text (not "image.jpg")
- Videos: Captions + audio description
- Color: Don't rely on color alone (red=error, green=success)
- Contrast: 4.5:1 ratio for text

PILLAR 2: OPERABLE (Users can navigate using keyboard/voice)
- Keyboard: Every interactive element reachable via keyboard
- Tab order: Logical, not random (left-to-right, top-to-bottom)
- Focus indicator: Visible blue outline on focused element
- No keyboard trap: Users can always move forward/backward
- Mouse-only flows: Unacceptable (keyboard-first design)

PILLAR 3: UNDERSTANDABLE (Users can comprehend content)
- Language: Clear, simple language
- Instructions: Explicit ("Click 'Submit' button" not "Go")
- Error handling: Explain what went wrong + how to fix
- Consistency: Same things work the same way everywhere

PILLAR 4: ROBUST (Works with assistive tech)
- Screen readers: Semantic HTML (not DIVs for buttons)
- Voice control: Interactive elements respond to voice
- Magnification: 200% zoom works without loss of content
- Testing: Test with actual assistive tech (NVDA, JAWS, Voice Control)

Accessibility PRD Template Section

## Accessibility (WCAG 2.1 AA)

PERCEIVABLE:
- Images: All images have descriptive alt text (e.g., "Graph showing 30% revenue growth" not "graph.png")
- Videos: Captions provided (not auto-generated; human-reviewed)
- Color: Errors shown with text + icon, not just red highlight
- Contrast: All text 4.5:1 contrast minimum (test with WebAIM checker)

OPERABLE:
- Keyboard: Every button/link/input reachable via Tab key
- Tab order: Logical left-to-right, top-to-bottom
- Focus: Blue outline visible on focused element
- No traps: Tab key always moves forward; Shift+Tab moves backward

UNDERSTANDABLE:
- Instructions: "Click Submit to save" not "Go"
- Error messages: "Email is required. Please enter your email." not "Invalid input"
- Form labels: Each input has visible label (<label> tag)
- Consistency: Submit button always in same place, same color

ROBUST:
- HTML: Semantic markup (<button>, <input>, <form>, not <div>)
- ARIA: Role/label attributes where needed (e.g., <button aria-label="Close menu">)
- Assistive tech: Tested with NVDA (Windows screen reader, free)

TESTING:
- [ ] Keyboard-only navigation (no mouse)
- [ ] Screen reader (NVDA/JAWS)
- [ ] Color contrast (WebAIM checker)
- [ ] 200% zoom (content readable, no loss)
- [ ] Real users (1-2 users with disabilities)

Real-World Example: Accessibility-Ready Search

Bad PRD (No A11y Consideration)

FEATURE: Search

BEHAVIOR:
- User types query
- Autocomplete dropdown appears
- User clicks result
- Search completes

Accessibility Problems:

  1. Autocomplete: Screen reader can't announce suggestions
  2. Keyboard: Can't arrow-down through suggestions
  3. Focus: No visual indicator on selected suggestion
  4. ARIA: Missing (dropdown not marked as role="listbox")

Good PRD (A11y Built-In)

FEATURE: Search with Accessibility (WCAG 2.1 AA)

USER FLOW:
- User types query into search input
- Autocomplete dropdown appears (aria-expanded="true")
- Screen reader announces: "10 suggestions available"

KEYBOARD NAVIGATION:
- Tab: Move to search input
- Type: Search query
- Arrow Down: Move through autocomplete suggestions
- Enter: Select suggestion or search
- Escape: Close autocomplete, keep text in input

SCREEN READER:
- Input: "Search products"
- Dropdown: "10 suggestions, use arrow keys to navigate"
- Each suggestion: "Nike Air Max, product"

FOCUS & CONTRAST:
- Selected suggestion: Blue background (4.5:1 contrast), blue outline on focused element
- Unselected: Gray text on white background (4.5:1 contrast)

ARIA MARKUP:
<input
  aria-label="Search products"
  aria-autocomplete="list"
  aria-expanded={showSuggestions}
  aria-controls="suggestions-list"
/>

<ul id="suggestions-list" role="listbox">
  <li role="option" aria-selected={isFocused}>
    Nike Air Max
  </li>
</ul>

TESTING PLAN:
- [ ] Keyboard-only: Navigate search + autocomplete using arrow keys only
- [ ] Screen reader: NVDA announces all suggestions + selected item
- [ ] 200% zoom: Search box and suggestions still readable
- [ ] Color contrast: Test with WebAIM (4.5:1 minimum)
- [ ] Real users: 2 blind users test with their screen readers

ACCEPTANCE CRITERIA:
- All keyboard-navigable
- Screen reader announces all content
- Color contrast ≥ 4.5:1
- 200% zoom readable
- Real user testing: 2/2 users say "It works for me"

Anti-Pattern: "We'll Make It Accessible Later"

The Problem:

  • Feature ships without accessibility
  • "We'll add it in the next sprint"
  • Never happens (other priorities)
  • Users with disabilities can't use feature

The Fix:

  • Accessibility is part of definition of done
  • No ship without WCAG AA checklist passing
  • Test with real users (not just automated tools)

Actionable Steps

Step 1: Define Accessibility Target in PRD

## Accessibility Target

This feature targets WCAG 2.1 AA compliance.

Before launch, we will:
- [ ] Test keyboard-only navigation
- [ ] Test with screen reader (NVDA)
- [ ] Verify 4.5:1 color contrast
- [ ] Test 200% zoom
- [ ] Get feedback from 2 users with disabilities

Step 2: Create Accessibility Checklist

For EVERY feature:

BEFORE LAUNCH:

Perceivable:
- [ ] All images have alt text
- [ ] Videos have captions
- [ ] Color not used alone (e.g., "red error box" also has error icon)
- [ ] Text contrast ≥ 4.5:1 (use WebAIM checker)

Operable:
- [ ] Every interactive element keyboard-accessible (Tab through all buttons)
- [ ] Tab order logical (left-to-right, top-to-bottom)
- [ ] Focus indicator visible (blue outline on all focused elements)
- [ ] No keyboard traps (always able to Tab forward/backward)

Understandable:
- [ ] Error messages descriptive ("Email is required" not "Error")
- [ ] Form labels present (<label> tag)
- [ ] Instructions clear ("Click Save" not "Go")

Robust:
- [ ] Semantic HTML (<button>, <input>, not <div>)
- [ ] ARIA labels where needed
- [ ] Tested with NVDA screen reader (Windows)

Real Testing:
- [ ] 1-2 users with disabilities tested feature
- [ ] Feedback incorporated

Step 3: Involve Users With Disabilities

Before launch, recruit 2 users:

RECRUITMENT:

"We're building [Feature]. Want to test it?"

For blind users: Ask to use their screen reader
For motor disabilities: Ask to use keyboard only
For color blindness: Ask to verify they can distinguish interface states

Feedback session:
- "Try to [task]. Tell me what's confusing."
- "Could you navigate this with just keyboard?"
- "Did the screen reader tell you what you needed?"

Step 4: Embed in Definition of Done

FEATURE COMPLETE WHEN:

Core functionality working: ✓
Tests passing: ✓
Code reviewed: ✓
Accessibility checklist passing: ✓ (now required)
Real user testing (disability): ✓ (now required)

Step 5: Create Accessibility Section in Every PRD

## Accessibility (WCAG 2.1 AA)

[Copy template above]

TESTING: Completed by [date]
USER TESTING: [Name 1, Name 2] provided feedback: [summary]
WCAG AUDIT: [Link to audit report]

PMSynapse Connection

Accessibility specification is manual. PMSynapse's A11y Generator creates WCAG checklists: "You're building search. Here's your accessibility spec: Keyboard navigation, screen reader support, 4.5:1 contrast, ARIA labels." By automating a11y spec generation, PMSynapse prevents features shipping inaccessible.

Key Takeaways

  • Accessibility is not optional. 15-20% of your addressable market needs it.

  • WCAG 2.1 AA is the standard. Most products target this; it's industry baseline.

  • Four pillars: Perceivable, Operable, Understandable, Robust. Spec all four.

  • Test with real users. Automated tools catch 60%; real users catch issues tools miss.

  • Keyboard-first design benefits everyone. Accessible = usable for all (noisy environment, busy hands, etc.).

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.

Accessibility in Product Specs: Building for Everyone From Day 1

Article Type

SPOKE Article — Links back to pillar: /prd-writing-masterclass-ai-era

Target Word Count

2,500–3,500 words

Writing Guidance

Reference PRD Section 9 Accessibility & Inclusivity. Cover WCAG 2.2 AA in PM-friendly terms, cognitive accessibility, and how to include accessibility in acceptance criteria. Soft-pitch: PMSynapse embeds accessibility checklists in every design spec.

Required Structure

1. The Hook (Empathy & Pain)

Open with an extremely relatable, specific scenario from PM life that connects to this topic. Use one of the PRD personas (Priya the Junior PM, Marcus the Mid-Level PM, Anika the VP of Product, or Raj the Freelance PM) where appropriate.

2. The Trap (Why Standard Advice Fails)

Explain why generic advice or common frameworks don't address the real complexity of this problem. Be specific about what breaks down in practice.

3. The Mental Model Shift

Introduce a new framework, perspective, or reframe that changes how the reader thinks about this topic. This should be genuinely insightful, not recycled advice.

4. Actionable Steps (3-5)

Provide concrete actions the reader can take tomorrow morning. Each step should be specific enough to execute without further research.

5. The Prodinja Angle (Soft-Pitch)

Conclude with how PMSynapse's autonomous PM Shadow capability connects to this topic. Keep it natural — no hard sell.

6. Key Takeaways

3-5 bullet points summarizing the article's core insights.

Internal Linking Requirements

  • Link to parent pillar: /blog/prd-writing-masterclass-ai-era
  • Link to 3-5 related spoke articles within the same pillar cluster
  • Link to at least 1 article from a different pillar cluster for cross-pollination

SEO Checklist

  • Primary keyword appears in H1, first paragraph, and at least 2 H2s
  • Meta title under 60 characters
  • Meta description under 155 characters and includes primary keyword
  • At least 3 external citations/references
  • All images have descriptive alt text
  • Table or framework visual included