Known accessibility issues tracked

Severity: Recommended

Like technical debt, accessibility issues need explicit tracking. "We know about it" isn't good enough.

Check automatically:

# Check for accessibility label in GitHub
gh label list 2>/dev/null | grep -iE "a11y|accessibility"

# Count open accessibility issues
gh issue list --label "accessibility" --state open --json title --limit 100 2>/dev/null | jq length
gh issue list --label "a11y" --state open --json title --limit 100 2>/dev/null | jq length

# Sample open issues
gh issue list --label "accessibility" --state open --json title,createdAt --limit 5 2>/dev/null

# Look for known issues doc
find . -maxdepth 4 -type f \( -name "*known*issues*" -o -name "*a11y*backlog*" \) -name "*.md" 2>/dev/null

Ask user:

• "Where are accessibility issues tracked?" (GitHub label, Jira, dedicated board)
• "Is there visibility into the current a11y backlog?"
• "Are issues from audits captured and tracked?"

Pass criteria:

• Dedicated label or tag for a11y issues
• Known issues are logged (not just remembered)
• Issues from audits/testing get captured
• Backlog is visible to team

Fail criteria:

• No tracking ("we fix them when we find them")
• Issues found but never logged
• Scattered across random tickets with no way to find them

Cross-reference with:

• A11Y-005 (audit findings should become tracked issues)
• A11Y-011 (tracked issues feed the remediation plan)
• Section 40 (Technical Debt Tracking) — same principle, different domain

Evidence to capture:

• Tracking method (label, board, doc)
• Open issue count
• Sample of tracked issues
• Last activity date

---