keyboard-review

Name: keyboard-review
Author: Owl-Listener

82stars25forks

How to install keyboard-review?

owl-listener/inclusive-design-skills/keyboard-review

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

Installs into the current project.

Summary

Review keyboard navigation and focus management in an existing interface. Chains: keyboard-navigation, feedback-and-status. Use when testing or reviewing keyboard accessibility specifically, before a release, or when users report keyboard issues.

Files · 1

View on GitHub

SKILL.md

1	# Keyboard Review
2
3	A focused review of keyboard accessibility — the single most important
4	interaction requirement. If keyboard doesn't work, screen readers don't
5	work, switch devices don't work, and many motor-impaired users are
6	completely blocked.
7
8	## Process
9
10	### Step 1: Tab Through Everything
11	Starting from the browser address bar, press Tab repeatedly through
12	the entire page. Document:
13	- Unreachable elements — interactive items that Tab skips
14	- Wrong order — focus jumps to unexpected locations
15	- Invisible focus — focus moves but you can't see where it is
16	- Keyboard traps — focus enters a region and can't leave
17
18	### Step 2: Test All Components
19	Using keyboard-navigation, test each component type present:
20	- Menus: Tab to open, Arrow keys to navigate, Escape to close
21	- Modals: focus trapped inside, Escape to close, focus returns on close
22	- Tabs: Arrow keys between tabs, Tab into panel content
23	- Forms: Tab between fields, Enter to submit
24	- Custom widgets: appropriate keyboard patterns for the role
25
26	### Step 3: Test Dynamic Content
27	When content changes on screen:
28	- Does focus move to the new content when appropriate?
29	- Are screen reader users informed of the change?
30	- When content is removed, does focus move to a logical place?
31	- Do loading states announce themselves?
32
33	Using feedback-and-status, verify all dynamic changes are announced
34	via aria-live regions or focus management.
35
36	### Step 4: Check Skip Links and Landmarks
37	- Is "Skip to main content" present and functional?
38	- Are ARIA landmarks present (banner, navigation, main, contentinfo)?
39	- Can a keyboard user bypass repeated navigation efficiently?
40
41	## Output
42
43	Deliver a keyboard accessibility report:
44
45	1. Pass/fail summary — can every task be completed by keyboard?
46	2. Tab order map — the actual focus sequence with issues marked
47	3. Component results — pass/fail for each interactive component
48	4. Dynamic content results — focus management for content changes
49	5. Fix list — prioritised by severity (blocker, major, minor)

People who liked this also viewed

6 picks

Type

keyboard-review

82stars25forks

View on GitHub

How to install keyboard-review?

owl-listener/inclusive-design-skills/keyboard-review

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

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Keyboard Review
2
3	A focused review of keyboard accessibility — the single most important
4	interaction requirement. If keyboard doesn't work, screen readers don't
5	work, switch devices don't work, and many motor-impaired users are
6	completely blocked.
7
8	## Process
9
10	### Step 1: Tab Through Everything
11	Starting from the browser address bar, press Tab repeatedly through
12	the entire page. Document:
13	- Unreachable elements — interactive items that Tab skips
14	- Wrong order — focus jumps to unexpected locations
15	- Invisible focus — focus moves but you can't see where it is
16	- Keyboard traps — focus enters a region and can't leave
17
18	### Step 2: Test All Components
19	Using keyboard-navigation, test each component type present:
20	- Menus: Tab to open, Arrow keys to navigate, Escape to close
21	- Modals: focus trapped inside, Escape to close, focus returns on close
22	- Tabs: Arrow keys between tabs, Tab into panel content
23	- Forms: Tab between fields, Enter to submit
24	- Custom widgets: appropriate keyboard patterns for the role
25
26	### Step 3: Test Dynamic Content
27	When content changes on screen:
28	- Does focus move to the new content when appropriate?
29	- Are screen reader users informed of the change?
30	- When content is removed, does focus move to a logical place?
31	- Do loading states announce themselves?
32
33	Using feedback-and-status, verify all dynamic changes are announced
34	via aria-live regions or focus management.
35
36	### Step 4: Check Skip Links and Landmarks
37	- Is "Skip to main content" present and functional?
38	- Are ARIA landmarks present (banner, navigation, main, contentinfo)?
39	- Can a keyboard user bypass repeated navigation efficiently?
40
41	## Output
42
43	Deliver a keyboard accessibility report:
44
45	1. Pass/fail summary — can every task be completed by keyboard?
46	2. Tab order map — the actual focus sequence with issues marked
47	3. Component results — pass/fail for each interactive component
48	4. Dynamic content results — focus management for content changes
49	5. Fix list — prioritised by severity (blocker, major, minor)

People who liked this also viewed

6 picks

Type