Accessibility audit before major releases

Severity: Recommended

Automated tests are continuous; audits are deep. Major releases should get a thorough review beyond what CI catches.

Check automatically:

# Look for release checklists or QA docs
find . -maxdepth 4 -type f \( -name "*release*" -o -name "*checklist*" -o -name "*qa*" \) -name "*.md" 2>/dev/null | xargs grep -l -iE "accessibility|a11y|wcag" 2>/dev/null

# Check for audit reports
find . -maxdepth 4 -type d -name "*audit*" 2>/dev/null
find . -maxdepth 4 -type f \( -name "*a11y*audit*" -o -name "*accessibility*report*" \) 2>/dev/null

# Look for PR templates with a11y checkbox
grep -riE "accessibility|a11y" .github/PULL_REQUEST_TEMPLATE* 2>/dev/null

Ask user:

• "Is there a pre-release accessibility check?" (manual audit, Lighthouse run, external review)
• "What triggers an audit?" (major releases only, every release, never)
• "Who performs it?" (developers, QA, external firm)
• "Are there blocking criteria?" (can't release with critical a11y issues)

Pass criteria:

• Accessibility is part of release process (documented or practiced)
• Major releases get some level of review
• Blocking issues prevent release

Fail criteria:

• No accessibility gate before releases
• "We'll fix it in the next release"
• Only happens when someone remembers

Cross-reference with:

• A11Y-002 (automated testing is minimum; audit is deeper)
• A11Y-010 (audit findings should be tracked)

Evidence to capture:

• Audit process documented
• Last audit date
• Who performs audits
• Blocking criteria

---