// Review and surface undocumented accessibility assumptions in an existing feature or product. Chains: decision-documentation, tradeoff-analysis, compliance-mapping, accessibility-debt-tracking. Use when inheriting a product, joining a team, or auditing a feature where accessibility decisions were never formally captured.
| name | review |
| description | Review and surface undocumented accessibility assumptions in an existing feature or product. Chains: decision-documentation, tradeoff-analysis, compliance-mapping, accessibility-debt-tracking. Use when inheriting a product, joining a team, or auditing a feature where accessibility decisions were never formally captured. |
Surface the accessibility decisions that were made — deliberately or by default — in an existing feature, and document them before they get lost.
Walk through the feature and list every design choice that affects accessibility, even if nobody explicitly decided it:
Many of these were never consciously decided — they were inherited from a framework, copied from another feature, or left at defaults. Those are still decisions. Document them.
For each identified decision, determine:
Using tradeoff-analysis, identify decisions where accessibility was traded for something else:
Document each with its current impact on users.
Using compliance-mapping, assess the feature's current state against WCAG 2.2 Level AA. Identify conformance gaps.
Using accessibility-debt-tracking, create a debt record for every known issue discovered in this review.
Deliver a decision review report:
Generate an accessibility decision handoff for engineering. Chains: decision-documentation, compliance-mapping, accessibility-testing-strategy. Use when a design is ready for implementation and the engineering team needs clear accessibility specifications.
Document accessibility decisions and tradeoffs for a feature. Chains: decision-documentation, tradeoff-analysis, compliance-mapping. Use when a feature is being designed or shipped and accessibility decisions need to be captured.
Plan what to test, how to test, and who should test for accessibility. Use when defining a testing approach, planning QA, setting up automated and manual testing, or deciding what level of accessibility testing a project needs. Triggers on: accessibility testing, how to test, test plan, automated testing, manual testing, screen reader testing, user testing, accessibility QA, what to test, testing strategy.
Track and manage accessibility debt — known accessibility issues that have been deferred. Use when managing a backlog of accessibility issues, planning remediation, or when accessibility problems are accumulating faster than they're being fixed. Triggers on: accessibility debt, tech debt, known issues, backlog, deferred, we'll fix it later, remediation, accessibility backlog, accumulating issues, regression.
Communicate accessibility decisions, requirements, and value to stakeholders who aren't accessibility specialists. Use when presenting accessibility work to leadership, product managers, engineers, or anyone who needs to understand why accessibility decisions matter. Triggers on: stakeholder, business case, justify accessibility, explain accessibility, leadership, executive, ROI, why accessibility, cost of accessibility, persuade, convince, accessibility presentation.
Map design decisions to accessibility standards and legal requirements. Use when documenting WCAG conformance, preparing for audits, tracking compliance status, or when legal or procurement requires accessibility documentation. Triggers on: WCAG, compliance, conformance, audit, VPAT, accessibility statement, legal requirement, ADA, EAA, European Accessibility Act, Section 508, EN 301 549, accessibility standard, success criterion.