accessibility-testing-strategy

Name: accessibility-testing-strategy
Author: Owl-Listener

82stars25forks

How to install accessibility-testing-strategy?

owl-listener/inclusive-design-skills/accessibility-testing-strategy

$npx -y skills add Owl-Listener/inclusive-design-skills --skill accessibility-testing-strategy

Installs into the current project.

Summary

Plan what to test, how to test, and who should test for accessibility. Use when defining a testing approach, planning QA, setting up automated and manual testing, or deciding what level of accessibility testing a project needs. Triggers on: accessibility testing, how to test, tes

Files · 1

View on GitHub

SKILL.md

1	# Accessibility Testing Strategy
2
3	Plan a testing approach that catches real accessibility barriers —
4	because automated tools find roughly 30% of issues. The other 70%
5	require human judgment.
6
7	## The Testing Pyramid
8
9	### Layer 1: Automated Testing (Catches ~30%)
10	What it finds:
11	- Missing alt text
12	- Colour contrast failures
13	- Missing form labels
14	- Missing language attribute
15	- Empty headings and buttons
16	- Duplicate IDs
17
18	What it misses:
19	- Whether alt text is meaningful
20	- Whether focus order is logical
21	- Whether content makes sense
22	- Whether interactions work with keyboard
23	- Whether the experience is usable
24
25	Tools: axe, Lighthouse, WAVE, Pa11y, jest-axe
26	When: on every build, in CI/CD pipeline
27	Who: automated — no human needed
28
29	### Layer 2: Manual Expert Testing (Catches ~50%)
30	What it finds:
31	- Keyboard navigation issues
32	- Focus management problems
33	- Logical reading order failures
34	- Meaningful alt text assessment
35	- Cognitive accessibility barriers
36	- Interaction pattern issues
37
38	Method:
39	- Tab through every interactive element
40	- Test with screen reader (VoiceOver or NVDA)
41	- Test at 200% zoom
42	- Test with system preferences enabled
43	- Review content for plain language
44
45	When: before each release, on major feature changes
46	Who: someone trained in accessibility testing
47
48	### Layer 3: User Testing With Disabled People (Catches remaining ~20%)
49	What it finds:
50	- Real-world usability barriers that experts miss
51	- Assistive technology compatibility issues
52	- Unexpected workflows and workarounds
53	- Cognitive and emotional barriers
54	- Issues that only appear with actual AT proficiency
55
56	Method:
57	- Recruit participants with diverse disabilities
58	- Test core tasks with their own devices and AT
59	- Observe — don't guide or explain
60	- Record what works, what fails, and what frustrates
61
62	When: quarterly, or before major launches
63	Who: users with disabilities using their own setup
64
65	## What to Test First
66
67	### Priority 1: Core Tasks
68	- Can users complete the primary tasks the product exists for?
69	- Test the critical path end to end
70	- Any failure here is a launch blocker
71
72	### Priority 2: Input and Navigation
73	- Keyboard-only navigation through the core flow
74	- Screen reader navigation through the core flow
75	- Touch interaction on mobile for the core flow
76
77	### Priority 3: Content and Comprehension
78	- Is content understandable at the target reading level?
79	- Are error messages helpful?
80	- Is help available and findable?
81
82	### Priority 4: Edge Cases and Preferences
83	- Zoom to 200%
84	- System preferences (reduced motion, high contrast, dark mode)
85	- Long content, empty states, error states
86
87	## Screen Reader Testing Basics
88
89	For teams new to screen reader testing:
90
91	### Start With VoiceOver (Mac)
92	- Turn on: Cmd + F5
93	- Navigate: VO + arrow keys (VO = Ctrl + Option)
94	- Headings: VO + Cmd + H
95	- Links: VO + Cmd + L
96	- Forms: VO + Cmd + J
97	- Turn off: Cmd + F5
98
99	### Start With NVDA (Windows)
100	- Download free from nvaccess.org
101	- Navigate: Tab, arrow keys
102	- Headings: H
103	- Links: K
104	- Forms: F
105	- Stop speech: Ctrl
106
107	### What to Listen For
108	- Does every interactive element have a name?
109	- Are state changes announced (expanded, selected, checked)?
110	- Does focus move to the right place after actions?
111	- Can you understand the page reading only the headings?
112
113	## Assessment Questions
114
115	1. Is automated testing running on every build?
116	2. Is manual expert testing happening before each release?
117	3. Has the product been tested by people with disabilities?
118	4. Are core tasks tested with keyboard and screen reader?
119	5. Is there a clear priority for what to test first?

People who liked this also viewed

6 picks

Type

accessibility-testing-strategy

82stars25forks

View on GitHub

How to install accessibility-testing-strategy?

owl-listener/inclusive-design-skills/accessibility-testing-strategy

$npx -y skills add Owl-Listener/inclusive-design-skills --skill accessibility-testing-strategy

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Accessibility Testing Strategy
2
3	Plan a testing approach that catches real accessibility barriers —
4	because automated tools find roughly 30% of issues. The other 70%
5	require human judgment.
6
7	## The Testing Pyramid
8
9	### Layer 1: Automated Testing (Catches ~30%)
10	What it finds:
11	- Missing alt text
12	- Colour contrast failures
13	- Missing form labels
14	- Missing language attribute
15	- Empty headings and buttons
16	- Duplicate IDs
17
18	What it misses:
19	- Whether alt text is meaningful
20	- Whether focus order is logical
21	- Whether content makes sense
22	- Whether interactions work with keyboard
23	- Whether the experience is usable
24
25	Tools: axe, Lighthouse, WAVE, Pa11y, jest-axe
26	When: on every build, in CI/CD pipeline
27	Who: automated — no human needed
28
29	### Layer 2: Manual Expert Testing (Catches ~50%)
30	What it finds:
31	- Keyboard navigation issues
32	- Focus management problems
33	- Logical reading order failures
34	- Meaningful alt text assessment
35	- Cognitive accessibility barriers
36	- Interaction pattern issues
37
38	Method:
39	- Tab through every interactive element
40	- Test with screen reader (VoiceOver or NVDA)
41	- Test at 200% zoom
42	- Test with system preferences enabled
43	- Review content for plain language
44
45	When: before each release, on major feature changes
46	Who: someone trained in accessibility testing
47
48	### Layer 3: User Testing With Disabled People (Catches remaining ~20%)
49	What it finds:
50	- Real-world usability barriers that experts miss
51	- Assistive technology compatibility issues
52	- Unexpected workflows and workarounds
53	- Cognitive and emotional barriers
54	- Issues that only appear with actual AT proficiency
55
56	Method:
57	- Recruit participants with diverse disabilities
58	- Test core tasks with their own devices and AT
59	- Observe — don't guide or explain
60	- Record what works, what fails, and what frustrates
61
62	When: quarterly, or before major launches
63	Who: users with disabilities using their own setup
64
65	## What to Test First
66
67	### Priority 1: Core Tasks
68	- Can users complete the primary tasks the product exists for?
69	- Test the critical path end to end
70	- Any failure here is a launch blocker
71
72	### Priority 2: Input and Navigation
73	- Keyboard-only navigation through the core flow
74	- Screen reader navigation through the core flow
75	- Touch interaction on mobile for the core flow
76
77	### Priority 3: Content and Comprehension
78	- Is content understandable at the target reading level?
79	- Are error messages helpful?
80	- Is help available and findable?
81
82	### Priority 4: Edge Cases and Preferences
83	- Zoom to 200%
84	- System preferences (reduced motion, high contrast, dark mode)
85	- Long content, empty states, error states
86
87	## Screen Reader Testing Basics
88
89	For teams new to screen reader testing:
90
91	### Start With VoiceOver (Mac)
92	- Turn on: Cmd + F5
93	- Navigate: VO + arrow keys (VO = Ctrl + Option)
94	- Headings: VO + Cmd + H
95	- Links: VO + Cmd + L
96	- Forms: VO + Cmd + J
97	- Turn off: Cmd + F5
98
99	### Start With NVDA (Windows)
100	- Download free from nvaccess.org
101	- Navigate: Tab, arrow keys
102	- Headings: H
103	- Links: K
104	- Forms: F
105	- Stop speech: Ctrl
106
107	### What to Listen For
108	- Does every interactive element have a name?
109	- Are state changes announced (expanded, selected, checked)?
110	- Does focus move to the right place after actions?
111	- Can you understand the page reading only the headings?
112
113	## Assessment Questions
114
115	1. Is automated testing running on every build?
116	2. Is manual expert testing happening before each release?
117	3. Has the product been tested by people with disabilities?
118	4. Are core tasks tested with keyboard and screen reader?
119	5. Is there a clear priority for what to test first?

People who liked this also viewed

6 picks

Type