mcpField
H
handoff

handoff

github.com/owl-listenerDesign & UI10875 installsUpdated 20w ago
Repository

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

  1. 01Compile accessibility design decisions
  2. 02Map elements to HTML, ARIA, keyboard, and visual requirements
  3. 03Define executable test cases
  4. 04Map requirements to WCAG criteria
  5. 05Document risks and definition of done

Use cases

  1. 01Prepare an accessibility specification for a feature
  2. 02Give engineers concrete implementation requirements
  3. 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 handoff

After installing, type/handoffin Claude Code to confirm it loaded.

Details

From the project README

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

Comments

Markdown supported