About handoff
handoff is an accessibility design skill that turns decisions into implementation requirements and test criteria. It gives engineers an element-by-element specification, WCAG mapping, and a register of risks and dependencies.
Key features
- 01Compile accessibility design decisions
- 02Map elements to HTML, ARIA, keyboard, and visual requirements
- 03Define executable test cases
- 04Map requirements to WCAG criteria
- 05Document risks and definition of done
Use cases
- 01Prepare an accessibility specification for a feature
- 02Give engineers concrete implementation requirements
- 03Set test and release criteria for accessible interactions
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ owl-listener/ inclusive-design-skills --skill handoffAfter installing, type/handoffin Claude Code to confirm it loaded.
Details
From the project READMEAccessibility 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