manual-testing

Name: manual-testing
Author: mgifford

27stars2forks

How to install manual-testing?

mgifford/accessibility-skills/manual-testing

$npx -y skills add mgifford/accessibility-skills --skill manual-testing

Installs into the current project.

Summary

Load this skill whenever you are planning, executing, or reviewing manual accessibility testing. Manual testing with real assistive technologies is essential — automated tools catch only ~30–40 % of WCAG issues. Absolutely always include keyboard-only testing and at least one scr

Files · 1

View on GitHub

SKILL.md

1	# Manual Accessibility Testing Skill
2
3	> Canonical source: `examples/MANUAL_ACCESSIBILITY_TESTING_GUIDE.md` in `mgifford/ACCESSIBILITY.md`
4	> This skill is derived from that file. When in doubt, the example is authoritative.
5
6	Apply these rules when planning or reviewing manual accessibility testing.
7
8	---
9
10	## Severity Scale (this skill)
11
12	\| Level \| Meaning \|
13	\|---\|---\|
14	\| Critical \| Issue completely blocks a core task for one or more disability groups \|
15	\| Serious \| Significantly impairs access; workaround unreasonable to expect \|
16	\| Moderate \| Creates friction; workaround exists and is not too burdensome \|
17	\| Minor \| Best-practice gap; marginal impact on access \|
18
19	---
20
21	## Core Principle
22
23	Manual testing reveals issues that automated tools cannot detect, including:
24
25	* Screen reader announcement quality and user experience
26	* Keyboard navigation flow and logical sequence
27	* Focus management in dynamic interfaces
28	* Context and orientation for assistive technology users
29	* Forced colors mode (Windows High Contrast) — automated tools cannot simulate OS-level color overrides
30	* Real-world usability barriers
31
32	---
33
34	## Critical: When Manual Testing Is Required
35
36	Perform manual testing:
37
38	* Before each release — test critical user flows end to end
39	* After UI changes — test all affected components
40	* For new features — test complete user workflows
41	* When automated tests pass — validate actual user experience
42	* When accessibility bugs are reported — reproduce and verify fixes
43
44	Getting started: test keyboard-only first (easiest entry point), then learn
45	basic screen reader commands for your platform. Practice on familiar websites
46	before testing your own. Focus on one component or flow at a time.
47
48	---
49
50	## Critical: Keyboard-Only Testing
51
52	Every interactive element must be reachable and operable by keyboard alone.
53
54	Steps:
55	1. Click in the browser address bar, then press Tab to start from page top
56	2. Tab through entire page; check each focusable element:
57	- Is focus visible (clear outline or highlight)?
58	- Is focus order logical (follows visual/reading order)?
59	- Can you activate it? (Enter for links/buttons, Space for buttons/checkboxes)
60	3. Press Shift+Tab to reverse through elements
61	4. Confirm there are no keyboard traps (can you Tab away from every element?)
62
63	Key shortcuts to verify:
64
65	\| Key \| Expected behaviour \|
66	\|---\|---\|
67	\| Tab \| Move focus forward \|
68	\| Shift+Tab \| Move focus backward \|
69	\| Enter \| Activate links, buttons, submit forms \|
70	\| Space \| Activate buttons, toggle checkboxes \|
71	\| Arrow keys \| Navigate within components (menus, tabs, radio groups) \|
72	\| Escape \| Close dialogs, cancel operations \|
73	\| Home / End \| Jump to start/end of component \|
74
75	Component-specific checks:
76
77	* Forms: all fields reachable; labels and required state announced; errors
78	appear and are announced; Enter submits; can cancel/reset if applicable
79	* Buttons: Enter and Space both activate; visual feedback on activation;
80	focus moves appropriately after activation
81	* Links: Enter activates; destination clear from link text; skip links work
82	* Dropdowns/select menus: arrow keys navigate options; Escape closes;
83	selected value announced
84	* Modal dialogs: focus moves in on open; focus trapped inside; Escape
85	closes (unless critical); focus returns to trigger on close
86	* Custom widgets (tabs, accordions, carousels): follow WAI-ARIA keyboard
87	patterns; arrow keys and Home/End work as documented; state changes are clear
88
89	---
90
91	## Critical: Screen Reader Testing
92
93	Recommended platform pairings:
94
95	* NVDA + Firefox or Chrome (Windows)
96	* JAWS + Chrome or Firefox (Windows)
97	* VoiceOver + Safari (macOS / iOS)
98	* TalkBack + Chrome (Android)
99
100	Basic test procedure:
101
102	1. Start screen reader (NVDA: Ctrl+Alt+N; VoiceOver macOS: Cmd+F5)
103	2. Navigate by headings (NVDA/JAWS: H / Shift+H) — do they form a logical outline?
104	3. Navigate by landmarks (NVDA/JAWS: D / Shift+D) — are `<nav>`, `<main>`, `<header>` identified?
105	4. Navigate by form controls (NVDA/JAWS: F / Shift+F) — are labels announced?
106	5. Read all content — is order logical? Any missing or confusing announcements?
107
108	Component-specific screen reader checks:
109
110	* Images: decorative images ignored (empty alt/`aria-hidden`); informative
111	images have descriptive alt text; complex images have longer descriptions
112	* Links: purpose clear from announcement alone; text meaningful (not
113	"click here"); external links/new windows indicated
114	* Buttons: label describes the action; pressed/tog

People who liked this also viewed

6 picks

Type

manual-testing

27stars2forks

View on GitHub

How to install manual-testing?

mgifford/accessibility-skills/manual-testing

$npx -y skills add mgifford/accessibility-skills --skill manual-testing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Manual Accessibility Testing Skill
2
3	> Canonical source: `examples/MANUAL_ACCESSIBILITY_TESTING_GUIDE.md` in `mgifford/ACCESSIBILITY.md`
4	> This skill is derived from that file. When in doubt, the example is authoritative.
5
6	Apply these rules when planning or reviewing manual accessibility testing.
7
8	---
9
10	## Severity Scale (this skill)
11
12	\| Level \| Meaning \|
13	\|---\|---\|
14	\| Critical \| Issue completely blocks a core task for one or more disability groups \|
15	\| Serious \| Significantly impairs access; workaround unreasonable to expect \|
16	\| Moderate \| Creates friction; workaround exists and is not too burdensome \|
17	\| Minor \| Best-practice gap; marginal impact on access \|
18
19	---
20
21	## Core Principle
22
23	Manual testing reveals issues that automated tools cannot detect, including:
24
25	* Screen reader announcement quality and user experience
26	* Keyboard navigation flow and logical sequence
27	* Focus management in dynamic interfaces
28	* Context and orientation for assistive technology users
29	* Forced colors mode (Windows High Contrast) — automated tools cannot simulate OS-level color overrides
30	* Real-world usability barriers
31
32	---
33
34	## Critical: When Manual Testing Is Required
35
36	Perform manual testing:
37
38	* Before each release — test critical user flows end to end
39	* After UI changes — test all affected components
40	* For new features — test complete user workflows
41	* When automated tests pass — validate actual user experience
42	* When accessibility bugs are reported — reproduce and verify fixes
43
44	Getting started: test keyboard-only first (easiest entry point), then learn
45	basic screen reader commands for your platform. Practice on familiar websites
46	before testing your own. Focus on one component or flow at a time.
47
48	---
49
50	## Critical: Keyboard-Only Testing
51
52	Every interactive element must be reachable and operable by keyboard alone.
53
54	Steps:
55	1. Click in the browser address bar, then press Tab to start from page top
56	2. Tab through entire page; check each focusable element:
57	- Is focus visible (clear outline or highlight)?
58	- Is focus order logical (follows visual/reading order)?
59	- Can you activate it? (Enter for links/buttons, Space for buttons/checkboxes)
60	3. Press Shift+Tab to reverse through elements
61	4. Confirm there are no keyboard traps (can you Tab away from every element?)
62
63	Key shortcuts to verify:
64
65	\| Key \| Expected behaviour \|
66	\|---\|---\|
67	\| Tab \| Move focus forward \|
68	\| Shift+Tab \| Move focus backward \|
69	\| Enter \| Activate links, buttons, submit forms \|
70	\| Space \| Activate buttons, toggle checkboxes \|
71	\| Arrow keys \| Navigate within components (menus, tabs, radio groups) \|
72	\| Escape \| Close dialogs, cancel operations \|
73	\| Home / End \| Jump to start/end of component \|
74
75	Component-specific checks:
76
77	* Forms: all fields reachable; labels and required state announced; errors
78	appear and are announced; Enter submits; can cancel/reset if applicable
79	* Buttons: Enter and Space both activate; visual feedback on activation;
80	focus moves appropriately after activation
81	* Links: Enter activates; destination clear from link text; skip links work
82	* Dropdowns/select menus: arrow keys navigate options; Escape closes;
83	selected value announced
84	* Modal dialogs: focus moves in on open; focus trapped inside; Escape
85	closes (unless critical); focus returns to trigger on close
86	* Custom widgets (tabs, accordions, carousels): follow WAI-ARIA keyboard
87	patterns; arrow keys and Home/End work as documented; state changes are clear
88
89	---
90
91	## Critical: Screen Reader Testing
92
93	Recommended platform pairings:
94
95	* NVDA + Firefox or Chrome (Windows)
96	* JAWS + Chrome or Firefox (Windows)
97	* VoiceOver + Safari (macOS / iOS)
98	* TalkBack + Chrome (Android)
99
100	Basic test procedure:
101
102	1. Start screen reader (NVDA: Ctrl+Alt+N; VoiceOver macOS: Cmd+F5)
103	2. Navigate by headings (NVDA/JAWS: H / Shift+H) — do they form a logical outline?
104	3. Navigate by landmarks (NVDA/JAWS: D / Shift+D) — are `<nav>`, `<main>`, `<header>` identified?
105	4. Navigate by form controls (NVDA/JAWS: F / Shift+F) — are labels announced?
106	5. Read all content — is order logical? Any missing or confusing announcements?
107
108	Component-specific screen reader checks:
109
110	* Images: decorative images ignored (empty alt/`aria-hidden`); informative
111	images have descriptive alt text; complex images have longer descriptions
112	* Links: purpose clear from announcement alone; text meaningful (not
113	"click here"); external links/new windows indicated
114	* Buttons: label describes the action; pressed/tog

People who liked this also viewed

6 picks

Type