assistive-technology-scenarios

Name: assistive-technology-scenarios
Author: Owl-Listener

82stars25forks

How to install assistive-technology-scenarios?

owl-listener/inclusive-design-skills/assistive-technology-scenarios

$npx -y skills add Owl-Listener/inclusive-design-skills --skill assistive-technology-scenarios

Installs into the current project.

Summary

Write usage scenarios that include assistive technology and diverse interaction methods. Use when writing scenarios, use cases, user journeys, or storyboards. Triggers on: assistive technology, AT, screen reader, switch, voice control, magnifier, braille display, head pointer, ey

Files · 1

View on GitHub

SKILL.md

1	# Assistive Technology Scenarios
2
3	Write scenarios that show real people using real assistive technology
4	to complete real tasks — so the team designs for actual usage, not
5	imagined ideal conditions.
6
7	## Why This Matters
8
9	If your scenarios only describe people using a mouse and a large
10	monitor, your design will only work for people using a mouse and a
11	large monitor. Scenarios shape what teams consider. What they consider,
12	they design for.
13
14	## Common Assistive Technologies
15
16	### Vision
17	- Screen reader (JAWS, NVDA, VoiceOver, TalkBack): reads content
18	aloud, navigates by headings, links, and landmarks via keyboard
19	- Screen magnifier (ZoomText, built-in zoom): enlarges a portion
20	of the screen, user sees only a fraction at a time
21	- Braille display: converts text to braille in real time, used
22	alongside a screen reader
23	- High contrast mode: system-level colour override for readability
24
25	### Motor
26	- Switch device: one or two buttons that scan through options —
27	much slower than keyboard, every extra step matters
28	- Voice control (Dragon, Voice Control, Voice Access): speaks
29	commands to navigate and type
30	- Head pointer / eye tracking: cursor controlled by head movement
31	or eye gaze — precision is limited
32	- Mouth stick / stylus: physical pointer for touchscreens or
33	keyboards
34
35	### Hearing
36	- Captions: real-time or pre-recorded text for audio content
37	- Visual alerts: flashing screen or visual indicator replacing
38	audio notifications
39	- Hearing loop / Bluetooth: direct audio to hearing aids
40
41	### Cognitive
42	- Text-to-speech: reads content aloud (not a screen reader —
43	the user can see the screen but processes better by hearing)
44	- Reading ruler / line guide: highlights one line at a time
45	- Simplified view: browser extensions or settings that strip
46	clutter
47	- Password managers: reduce memory burden for authentication
48
49	## How to Write AT Scenarios
50
51	### Include the Setup
52	Don't just name the disability. Describe the person, their technology,
53	and their environment.
54
55	"Priya is a data analyst who uses JAWS screen reader with Firefox on
56	a Windows laptop. She's fast with keyboard shortcuts and has two
57	monitors — one for her spreadsheets, one for the tool she's reviewing.
58	She's at her desk with noise-cancelling headphones."
59
60	### Show the Interaction Step by Step
61	Describe how the person actually moves through the interface with
62	their technology:
63
64	"Priya tabs to the navigation menu. JAWS announces 'Navigation,
65	5 items.' She presses the down arrow to find 'Reports' and presses
66	Enter. The page loads and JAWS announces the H1: 'Monthly Reports.'
67	She presses H to jump through headings until she finds 'March 2026.'"
68
69	### Show Where It Breaks
70	The scenario should surface design failures:
71
72	"Priya reaches the data table but JAWS announces each cell without
73	column headers. She hears '42,500' but doesn't know which metric or
74	which month. She tabs past the table looking for a text summary but
75	there isn't one."
76
77	## Scenario Coverage
78
79	For any product, write scenarios for at least:
80	- One screen reader user completing the core task
81	- One keyboard-only user completing the core task
82	- One user with low vision using magnification
83	- One user with a cognitive difference
84	- One user in a situational impairment context
85
86	## Template
87	```
88	Name: [Name]
89	Role/context: [Who they are beyond their disability]
90	Technology: [Devices, AT, browser, settings]
91	Environment: [Where, when, what else is happening]
92	Task: [What they're trying to accomplish]
93	Steps: [How they interact, step by step, using their AT]
94	Pain points: [Where the design fails or creates friction]
95	Success: [What a good outcome looks like for this person]
96	```
97
98	## Assessment Questions
99
100	1. Does the scenario name specific assistive technology, not just
101	the disability?
102	2. Does it describe step-by-step interaction, not just the goal?
103	3. Does it surface specific design failures?
104	4. Would a developer reading this know what to fix?

People who liked this also viewed

6 picks

Type

assistive-technology-scenarios

82stars25forks

View on GitHub

How to install assistive-technology-scenarios?

owl-listener/inclusive-design-skills/assistive-technology-scenarios

$npx -y skills add Owl-Listener/inclusive-design-skills --skill assistive-technology-scenarios

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Assistive Technology Scenarios
2
3	Write scenarios that show real people using real assistive technology
4	to complete real tasks — so the team designs for actual usage, not
5	imagined ideal conditions.
6
7	## Why This Matters
8
9	If your scenarios only describe people using a mouse and a large
10	monitor, your design will only work for people using a mouse and a
11	large monitor. Scenarios shape what teams consider. What they consider,
12	they design for.
13
14	## Common Assistive Technologies
15
16	### Vision
17	- Screen reader (JAWS, NVDA, VoiceOver, TalkBack): reads content
18	aloud, navigates by headings, links, and landmarks via keyboard
19	- Screen magnifier (ZoomText, built-in zoom): enlarges a portion
20	of the screen, user sees only a fraction at a time
21	- Braille display: converts text to braille in real time, used
22	alongside a screen reader
23	- High contrast mode: system-level colour override for readability
24
25	### Motor
26	- Switch device: one or two buttons that scan through options —
27	much slower than keyboard, every extra step matters
28	- Voice control (Dragon, Voice Control, Voice Access): speaks
29	commands to navigate and type
30	- Head pointer / eye tracking: cursor controlled by head movement
31	or eye gaze — precision is limited
32	- Mouth stick / stylus: physical pointer for touchscreens or
33	keyboards
34
35	### Hearing
36	- Captions: real-time or pre-recorded text for audio content
37	- Visual alerts: flashing screen or visual indicator replacing
38	audio notifications
39	- Hearing loop / Bluetooth: direct audio to hearing aids
40
41	### Cognitive
42	- Text-to-speech: reads content aloud (not a screen reader —
43	the user can see the screen but processes better by hearing)
44	- Reading ruler / line guide: highlights one line at a time
45	- Simplified view: browser extensions or settings that strip
46	clutter
47	- Password managers: reduce memory burden for authentication
48
49	## How to Write AT Scenarios
50
51	### Include the Setup
52	Don't just name the disability. Describe the person, their technology,
53	and their environment.
54
55	"Priya is a data analyst who uses JAWS screen reader with Firefox on
56	a Windows laptop. She's fast with keyboard shortcuts and has two
57	monitors — one for her spreadsheets, one for the tool she's reviewing.
58	She's at her desk with noise-cancelling headphones."
59
60	### Show the Interaction Step by Step
61	Describe how the person actually moves through the interface with
62	their technology:
63
64	"Priya tabs to the navigation menu. JAWS announces 'Navigation,
65	5 items.' She presses the down arrow to find 'Reports' and presses
66	Enter. The page loads and JAWS announces the H1: 'Monthly Reports.'
67	She presses H to jump through headings until she finds 'March 2026.'"
68
69	### Show Where It Breaks
70	The scenario should surface design failures:
71
72	"Priya reaches the data table but JAWS announces each cell without
73	column headers. She hears '42,500' but doesn't know which metric or
74	which month. She tabs past the table looking for a text summary but
75	there isn't one."
76
77	## Scenario Coverage
78
79	For any product, write scenarios for at least:
80	- One screen reader user completing the core task
81	- One keyboard-only user completing the core task
82	- One user with low vision using magnification
83	- One user with a cognitive difference
84	- One user in a situational impairment context
85
86	## Template
87	```
88	Name: [Name]
89	Role/context: [Who they are beyond their disability]
90	Technology: [Devices, AT, browser, settings]
91	Environment: [Where, when, what else is happening]
92	Task: [What they're trying to accomplish]
93	Steps: [How they interact, step by step, using their AT]
94	Pain points: [Where the design fails or creates friction]
95	Success: [What a good outcome looks like for this person]
96	```
97
98	## Assessment Questions
99
100	1. Does the scenario name specific assistive technology, not just
101	the disability?
102	2. Does it describe step-by-step interaction, not just the goal?
103	3. Does it surface specific design failures?
104	4. Would a developer reading this know what to fix?

People who liked this also viewed

6 picks

Type