Accessibility Decision Handoff
Package accessibility decisions into a clear specification that
engineers can implement against — because "make it accessible"
is not a specification.
Process
Step 1: Compile Decisions
Using decision-documentation, gather all accessibility decisions
for the feature:
- Interaction patterns and keyboard behaviour
- Screen reader announcements and ARIA requirements
- Visual specifications (contrast, colour independence, motion)
- Content requirements (reading level, alt text, link text)
- Adaptive behaviour (preferences, zoom, density)
Step 2: Map to Implementation
Using compliance-mapping, translate each design decision into
specific implementation requirements:
For each interactive element specify:
- HTML element or ARIA role
- Keyboard behaviour (which keys do what)
- Focus management (where focus goes after actions)
- Screen reader name, role, and state announcements
- Visual states (default, hover, focus, active, disabled, error)
For each content element specify:
- Heading level
- Alt text (exact text or strategy)
- Link text
- Language attributes if multilingual
For each adaptive behaviour specify:
- Media query and expected response
- Preference detected and what changes
- Breakpoints and reflow behaviour
Step 3: Define Test Criteria
Using accessibility-testing-strategy, provide specific test
cases for each requirement:
- Keyboard test: "Tab to the submit button, press Enter,
verify focus moves to the confirmation message"
- Screen reader test: "Navigate to the error, verify it
announces: 'Error: email address is required'"
- Visual test: "Verify contrast ratio of body text is at
least 4.5:1 in both light and dark modes"
- Zoom test: "At 200% zoom, verify the form reflows to
single column with no horizontal scroll"
Step 4: Flag Risks and Dependencies
Note anything engineers need to be aware of:
- Components that need custom keyboard handling
- Places where framework defaults aren't accessible
- Third-party components that may need wrapping or replacing
- Areas where automated testing won't catch the issue
Output
Deliver a handoff document containing:
- Accessibility specification — element-by-element requirements
with HTML, ARIA, keyboard, and visual specifications
- Test cases — specific, executable test scenarios for keyboard,
screen reader, visual, and zoom testing
- WCAG mapping — which success criteria each requirement
addresses
- Risk register — known challenges and recommended approaches
- Definition of done — the specific accessibility criteria
that must pass before the feature ships
1---2name: handoff3description: 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.4---56# Accessibility Decision Handoff78Package accessibility decisions into a clear specification that9engineers can implement against — because "make it accessible"10is not a specification.1112## Process1314### Step 1: Compile Decisions15Using **decision-documentation**, gather all accessibility decisions16for the feature:17- Interaction patterns and keyboard behaviour18- Screen reader announcements and ARIA requirements19- Visual specifications (contrast, colour independence, motion)20- Content requirements (reading level, alt text, link text)21- Adaptive behaviour (preferences, zoom, density)2223### Step 2: Map to Implementation24Using **compliance-mapping**, translate each design decision into25specific implementation requirements:2627For each interactive element specify:28- HTML element or ARIA role29- Keyboard behaviour (which keys do what)30- Focus management (where focus goes after actions)31- Screen reader name, role, and state announcements32- Visual states (default, hover, focus, active, disabled, error)3334For each content element specify:35- Heading level36- Alt text (exact text or strategy)37- Link text38- Language attributes if multilingual3940For each adaptive behaviour specify:41- Media query and expected response42- Preference detected and what changes43- Breakpoints and reflow behaviour4445### Step 3: Define Test Criteria46Using **accessibility-testing-strategy**, provide specific test47cases for each requirement:48- Keyboard test: "Tab to the submit button, press Enter,49 verify focus moves to the confirmation message"50- Screen reader test: "Navigate to the error, verify it51 announces: 'Error: email address is required'"52- Visual test: "Verify contrast ratio of body text is at53 least 4.5:1 in both light and dark modes"54- Zoom test: "At 200% zoom, verify the form reflows to55 single column with no horizontal scroll"5657### Step 4: Flag Risks and Dependencies58Note anything engineers need to be aware of:59- Components that need custom keyboard handling60- Places where framework defaults aren't accessible61- Third-party components that may need wrapping or replacing62- Areas where automated testing won't catch the issue6364## Output6566Deliver a handoff document containing:67681. **Accessibility specification** — element-by-element requirements69 with HTML, ARIA, keyboard, and visual specifications702. **Test cases** — specific, executable test scenarios for keyboard,71 screen reader, visual, and zoom testing723. **WCAG mapping** — which success criteria each requirement73 addresses744. **Risk register** — known challenges and recommended approaches755. **Definition of done** — the specific accessibility criteria76 that must pass before the feature ships