# Handoff

> 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.

- Skill: `owl-listener/handoff` (Agent Skill)
- Install (CLI): `npx skillmds@latest add owl-listener/handoff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/owl-listener/handoff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: Owl Listener (https://skillmd.com/u/owl-listener)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/owl-listener/handoff

---


# 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:

1. **Accessibility specification** — element-by-element requirements
   with HTML, ARIA, keyboard, and visual specifications
2. **Test cases** — specific, executable test scenarios for keyboard,
   screen reader, visual, and zoom testing
3. **WCAG mapping** — which success criteria each requirement
   addresses
4. **Risk register** — known challenges and recommended approaches
5. **Definition of done** — the specific accessibility criteria
   that must pass before the feature ships