handoff

Name: handoff
Author: Owl-Listener

82stars25forks

How to install handoff?

owl-listener/inclusive-design-skills/handoff

$npx -y skills add Owl-Listener/inclusive-design-skills --skill handoff

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Accessibility Decision Handoff
2
3	Package accessibility decisions into a clear specification that
4	engineers can implement against — because "make it accessible"
5	is not a specification.
6
7	## Process
8
9	### Step 1: Compile Decisions
10	Using decision-documentation, gather all accessibility decisions
11	for the feature:
12	- Interaction patterns and keyboard behaviour
13	- Screen reader announcements and ARIA requirements
14	- Visual specifications (contrast, colour independence, motion)
15	- Content requirements (reading level, alt text, link text)
16	- Adaptive behaviour (preferences, zoom, density)
17
18	### Step 2: Map to Implementation
19	Using compliance-mapping, translate each design decision into
20	specific implementation requirements:
21
22	For each interactive element specify:
23	- HTML element or ARIA role
24	- Keyboard behaviour (which keys do what)
25	- Focus management (where focus goes after actions)
26	- Screen reader name, role, and state announcements
27	- Visual states (default, hover, focus, active, disabled, error)
28
29	For each content element specify:
30	- Heading level
31	- Alt text (exact text or strategy)
32	- Link text
33	- Language attributes if multilingual
34
35	For each adaptive behaviour specify:
36	- Media query and expected response
37	- Preference detected and what changes
38	- Breakpoints and reflow behaviour
39
40	### Step 3: Define Test Criteria
41	Using accessibility-testing-strategy, provide specific test
42	cases for each requirement:
43	- Keyboard test: "Tab to the submit button, press Enter,
44	verify focus moves to the confirmation message"
45	- Screen reader test: "Navigate to the error, verify it
46	announces: 'Error: email address is required'"
47	- Visual test: "Verify contrast ratio of body text is at
48	least 4.5:1 in both light and dark modes"
49	- Zoom test: "At 200% zoom, verify the form reflows to
50	single column with no horizontal scroll"
51
52	### Step 4: Flag Risks and Dependencies
53	Note anything engineers need to be aware of:
54	- Components that need custom keyboard handling
55	- Places where framework defaults aren't accessible
56	- Third-party components that may need wrapping or replacing
57	- Areas where automated testing won't catch the issue
58
59	## Output
60
61	Deliver a handoff document containing:
62
63	1. Accessibility specification — element-by-element requirements
64	with HTML, ARIA, keyboard, and visual specifications
65	2. Test cases — specific, executable test scenarios for keyboard,
66	screen reader, visual, and zoom testing
67	3. WCAG mapping — which success criteria each requirement
68	addresses
69	4. Risk register — known challenges and recommended approaches
70	5. Definition of done — the specific accessibility criteria
71	that must pass before the feature ships

People who liked this also viewed

6 picks

Type

handoff

82stars25forks

View on GitHub

How to install handoff?

owl-listener/inclusive-design-skills/handoff

$npx -y skills add Owl-Listener/inclusive-design-skills --skill handoff

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Accessibility Decision Handoff
2
3	Package accessibility decisions into a clear specification that
4	engineers can implement against — because "make it accessible"
5	is not a specification.
6
7	## Process
8
9	### Step 1: Compile Decisions
10	Using decision-documentation, gather all accessibility decisions
11	for the feature:
12	- Interaction patterns and keyboard behaviour
13	- Screen reader announcements and ARIA requirements
14	- Visual specifications (contrast, colour independence, motion)
15	- Content requirements (reading level, alt text, link text)
16	- Adaptive behaviour (preferences, zoom, density)
17
18	### Step 2: Map to Implementation
19	Using compliance-mapping, translate each design decision into
20	specific implementation requirements:
21
22	For each interactive element specify:
23	- HTML element or ARIA role
24	- Keyboard behaviour (which keys do what)
25	- Focus management (where focus goes after actions)
26	- Screen reader name, role, and state announcements
27	- Visual states (default, hover, focus, active, disabled, error)
28
29	For each content element specify:
30	- Heading level
31	- Alt text (exact text or strategy)
32	- Link text
33	- Language attributes if multilingual
34
35	For each adaptive behaviour specify:
36	- Media query and expected response
37	- Preference detected and what changes
38	- Breakpoints and reflow behaviour
39
40	### Step 3: Define Test Criteria
41	Using accessibility-testing-strategy, provide specific test
42	cases for each requirement:
43	- Keyboard test: "Tab to the submit button, press Enter,
44	verify focus moves to the confirmation message"
45	- Screen reader test: "Navigate to the error, verify it
46	announces: 'Error: email address is required'"
47	- Visual test: "Verify contrast ratio of body text is at
48	least 4.5:1 in both light and dark modes"
49	- Zoom test: "At 200% zoom, verify the form reflows to
50	single column with no horizontal scroll"
51
52	### Step 4: Flag Risks and Dependencies
53	Note anything engineers need to be aware of:
54	- Components that need custom keyboard handling
55	- Places where framework defaults aren't accessible
56	- Third-party components that may need wrapping or replacing
57	- Areas where automated testing won't catch the issue
58
59	## Output
60
61	Deliver a handoff document containing:
62
63	1. Accessibility specification — element-by-element requirements
64	with HTML, ARIA, keyboard, and visual specifications
65	2. Test cases — specific, executable test scenarios for keyboard,
66	screen reader, visual, and zoom testing
67	3. WCAG mapping — which success criteria each requirement
68	addresses
69	4. Risk register — known challenges and recommended approaches
70	5. Definition of done — the specific accessibility criteria
71	that must pass before the feature ships

People who liked this also viewed

6 picks

Type