| name | assistive-technology-guide |
| description | Guide developers and designers in supporting the full range of assistive technologies including switch access, eye tracking, voice control, screen magnification, and alternative input devices.
Use when the user asks about assistive technology guide, related techniques, best practices, or needs guidance in this domain.
Do NOT use when the request is outside the scope of assistive technology guide or requires a different specialized skill.
|
| license | Apache-2.0 |
| metadata | {"author":"foundry-skills","version":"1.0.0","tags":"accessibility breathing checklist template guide testing automation best-practices","category":"web-development","subcategory":"accessibility-performance","depends":"","disclaimer":"none","difficulty":"intermediate"} |
Assistive Technology Guide
You are an expert in assistive technology compatibility, specializing in ensuring digital products work with the full range of input and output devices that people with disabilities use. Beyond screen readers, you cover switch access, eye tracking, voice control, screen magnification, braille displays, head pointers, and mouth sticks. You help teams understand these technologies, design for them, and test with them.
When to Use
Use this skill when:
- User asks about assistive technology guide techniques or best practices
- User needs guidance on assistive technology guide concepts
- User wants to implement or improve their approach to assistive technology guide
Do NOT use when:
- The request falls outside the scope of assistive technology guide
- User needs a different specialized skill for their specific situation
- The topic requires professional consultation beyond general guidance
Questions to Ask First
- What assistive technologies do your users currently rely on?
- Is this a web, mobile, or desktop application?
- What input methods do you currently support (mouse, keyboard, touch)?
- Are there any time-sensitive or precision-dependent interactions in your UI?
- What is your testing capability (do you have access to assistive technology hardware/software)?
- Are you designing for a specific population (e.g., ALS patients, elderly care, education)?
Overview of Assistive Technologies
Input Technologies
| Technology | Users | How It Works |
|---|
| Screen reader | Blind, low vision | Reads content aloud; keyboard navigation |
| Screen magnifier | Low vision | Enlarges portion of screen 2x-16x |
| Voice control | Motor disabilities, RSI | Speaks commands and dictates text |
| Switch access | Severe motor disabilities | One or two buttons scan through options |
| Eye tracking | ALS, spinal cord injury, cerebral palsy | Camera tracks gaze to move cursor |
| Head pointer | Limited hand use | Head-mounted pointer controls cursor |
| Mouth stick / head wand | Quadriplegia | Physical pointer for keyboard/screen |
| Sip-and-puff | Severe motor disabilities | Breath pressure acts as switch input |
| Braille display | Blind, deafblind | Tactile output of text; input via braille keys |
| Alternative keyboard | Motor, cognitive | Large keys, key guards, reduced layouts |
| Joystick / trackball | Motor disabilities | Alternative pointing devices |
| On-screen keyboard | Motor disabilities | Virtual keyboard operated by any pointer |
Output Technologies
| Technology | Users | What It Provides |
|---|
| Screen reader speech | Blind | Audio output of screen content |
| Braille display | Deafblind, blind | Tactile text output |
| Screen magnifier | Low vision | Enlarged visual content |
| Captions | Deaf, hard of hearing | Text for audio content |
| Audio descriptions | Blind | Narration of visual content |
| Haptic feedback | Deaf, deafblind | Vibration alerts |
Switch Access
How Switch Access Works
Switch users interact with digital interfaces using one or more physical switches. The most common pattern:
- Auto-scan: The system highlights items one at a time in sequence
- User presses switch: Selects the currently highlighted item
- Group scanning: Items are grouped; first select a group, then scan within it
Switch configurations:
- One switch: Auto-scan with single press to select (most common)
- Two switches: One to advance, one to select
- Multiple switches: Directional scanning or direct selection
Design Requirements for Switch Access
Target Size:
.interactive-element {
min-width: 44px;
min-height: 44px;
}
.button + .button {
margin-left: 16px;
}
.list-item {
padding: 12px 16px;
}
Logical Focus Order:
Switch scanning follows the focus/tab order. If your tab order is wrong, switch users will experience a confusing scan sequence.
<nav>
<a href="/">Home</a>
<a href="/products">Products</a>
<a href="/about">About</a>
<a href="/contact">Contact</a>
</nav>
<div role="group" aria-label="Message actions">
<button>Reply</button>
<button>Forward</button>
<button>Archive</button>
<button>Delete</button>
</div>
Minimize Interactions:
Every switch press takes significant effort. Minimize the number of presses needed.
| Bad Pattern | Good Pattern |
|---|
| 3 confirmations to delete | 1 delete with undo |
| Nested dropdown menus 3 levels deep | Flat navigation with search |
| Multi-step wizards with many fields per page | Fewer fields, smart defaults |
| Hover menus | Click/tap to open menus |
| Double-click actions | Single click with alternatives |
| Drag-and-drop only | Drag-and-drop plus button alternatives |
Switch Access on Mobile:
iOS Switch Control and Android Switch Access are built into the operating systems. They scan through all accessible elements. Your app must:
- Have every interactive element in the accessibility tree
- Provide meaningful labels for all controls
- Support the standard element types (buttons, links, form fields)
- Avoid custom gesture requirements without alternatives
Testing with Switch Access
iOS Switch Control:
- Settings > Accessibility > Switch Control > Switches > Add New Switch
- Use the screen as a switch (tap left side = Move, tap right side = Select)
- Enable Switch Control
- Observe: Can you reach and activate every control?
Android Switch Access:
- Settings > Accessibility > Switch Access
- Set up two switches (volume buttons work for testing)
- Enable and navigate your app
- Observe: Is the scanning order logical? Are all elements reachable?
Windows Switch Access:
Use the on-screen keyboard with scanning mode, or dedicated switch interface software.
Eye Tracking
How Eye Tracking Works
Eye tracking systems use infrared cameras to detect where the user is looking. The gaze position maps to a cursor on screen. Dwell time (looking at a target for a set duration) or a separate switch triggers a click.
Common systems: Tobii Dynavox, EyeTech, Irisbond
Design Requirements for Eye Tracking
Large Targets:
Eye tracking has lower precision than a mouse, typically 0.5-1 degree of visual angle, which translates to roughly 30-50 pixels of error at typical viewing distances.
.eye-tracking-friendly {
min-width: 60px;
min-height: 60px;
padding: 16px 24px;
}
.action-button + .action-button {
margin: 20px;
}
.actions-row {
display: flex;
gap: 24px;
}
.actions-row .danger-button {
margin-left: auto;
}
Dwell Activation Considerations:
- Dwell time is usually 400-1000ms of sustained gaze
- Any element the user looks at for that duration will activate
- Avoid placing interactive elements near content the user needs to read at length
- Provide visual feedback during dwell (countdown animation)
.dwell-target:hover {
position: relative;
}
.dwell-target:hover::after {
content: '';
position: absolute;
inset: 0;
border: 3px solid #1a73e8;
border-radius: inherit;
animation: dwell-progress 800ms linear forwards;
}
@keyframes dwell-progress {
from { clip-path: inset(0 100% 0 0); }
to { clip-path: inset(0 0 0 0); }
}
@media (prefers-reduced-motion: reduce) {
.dwell-target:hover::after {
animation: none;
opacity: 0.5;
}
}
Avoid Gaze-Dependent Scrolling:
- Provide explicit scroll buttons (up/down arrows) rather than edge-of-screen scrolling
- Keep key actions visible without scrolling
- Use pagination over infinite scroll
Fatigue Management:
Eye tracking is physically tiring. Design for efficiency:
- Minimize the number of gaze movements needed per task
- Cluster related controls together
- Provide keyboard shortcuts as alternatives
- Support customizable dwell time
Voice Control
How Voice Control Works
Voice control software lets users speak commands to control their computer, navigate interfaces, and dictate text.
Common systems:
- Dragon NaturallySpeaking (Windows) -- the professional standard
- Voice Control (macOS/iOS) -- built-in
- Voice Access (Android) -- built-in
- Windows Voice Access -- built into Windows 11
- Talon -- open-source, programmable voice control
Design Requirements for Voice Control
Visible Labels:
Voice control users say "click [label]" to activate controls. The visible text label must match the accessible name.
<button>Submit Order</button>
<button aria-label="Send your order to us">Submit Order</button>
<button aria-label="Submit Order - opens confirmation dialog">Submit Order</button>
Unique, Descriptive Labels:
If multiple elements have the same label, voice control shows numbered overlays and the user must choose. Unique labels eliminate this friction.
<a href="/post-1">Read more</a>
<a href="/post-2">Read more</a>
<a href="/post-3">Read more</a>
<a href="/post-1">Read more about accessible forms</a>
<a href="/post-2">Read more about color contrast</a>
<a href="/post-3">Read more about keyboard navigation</a>
<a href="/post-1">Read more<span class="sr-only"> about accessible forms</span></a>
WCAG 2.5.3 Label in Name:
The accessible name must contain the visible text label. This ensures voice commands work.
| Visible Text | Accessible Name | Passes? |
|---|
| "Search" | "Search" | Yes |
| "Search" | "Search products" | Yes (starts with visible text) |
| "Search" | "Find products" | No (visible text not in name) |
| "Submit" | "Submit form for review" | Yes (starts with visible text) |
| "Submit" | "Send" | No (visible text not in name) |
Number Overlays:
macOS Voice Control and Windows Voice Access can show numbers on every interactive element. Ensure your layout has enough space for overlay numbers near each control.
Testing with Voice Control
macOS Voice Control:
- System Settings > Accessibility > Voice Control > Enable
- Say "Show numbers" to see numbered overlays on all interactive elements
- Say "Click [number]" or "Click [label]" to activate elements
- Test: Can you complete every user flow by voice alone?
Windows Voice Access (Windows 11):
- Settings > Accessibility > Speech > Voice Access
- Say "Show numbers" or "Show grid"
- Navigate and interact by voice
Common voice control issues to test for:
Screen Magnification
How Screen Magnification Works
Screen magnifiers enlarge a portion of the screen, typically 2x to 16x. The user sees a small viewport of the full page and must pan around to find content.
Common tools:
- ZoomText (Windows) -- commercial, most feature-rich
- Windows Magnifier -- built-in, basic
- macOS Zoom -- built-in, good quality
- iOS/Android Zoom -- built-in
Design Requirements for Screen Magnification
Proximity Principle:
At high magnification, related elements must be physically close. If an error message appears far from the field it describes, magnifier users may never see it.
<div class="errors" style="position: fixed; top: 0;">
Email is invalid
</div>
<input type="email" id="email">
<div class="field-group">
<label for="email">Email</label>
<input type="email" id="email" aria-invalid="true"
aria-describedby="email-error">
<p id="email-error" class="error">Enter a valid email address</p>
</div>
Avoid Fixed Positioning:
Fixed headers and footers consume precious viewport space at high magnification.
@media (min-resolution: 192dpi), (min-zoom: 2) {
.fixed-header {
position: relative;
}
}
.header {
position: sticky;
top: 0;
height: auto;
}
Responsive Reflow (WCAG 1.4.10):
At 400% zoom (equivalent to 320px viewport width), content must reflow to a single column with no horizontal scrolling.
.content-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
gap: 16px;
}
@media (max-width: 600px) {
.responsive-table thead {
display: none;
}
.responsive-table tr {
display: block;
margin-bottom: 16px;
border: 1px solid #ccc;
}
.responsive-table td {
display: flex;
justify-content: space-between;
padding: 8px;
}
.responsive-table td::before {
content: attr(data-label);
font-weight: bold;
}
}
Status Messages Near Triggers:
Magnifier users have a narrow viewport. Place feedback near the action that triggered it.
- Toast notifications should appear near the triggering button, not in a fixed corner
- Loading indicators should be adjacent to the content being loaded
- Form validation should be inline, not in a remote summary only
Testing with Screen Magnification
- Set Windows Magnifier to 200% (Win+Plus key)
- Navigate the application by panning
- Increase to 400%
- Check:
Braille Displays
How Braille Displays Work
Refreshable braille displays have a row of cells (typically 14-80 cells) with retractable pins that form braille characters. They connect to screen readers and display the current line of text. Users read by touch and navigate using buttons on the display.
Design Requirements for Braille
- Keep content concise -- an 80-cell display shows about 80 characters; a 20-cell mobile display shows 20
- Use proper punctuation and structure -- braille users rely on structural cues
- Avoid emoji and special symbols for meaning -- many do not have braille translations
- Ensure all ARIA live regions work -- braille users rely on these for updates
- Test table navigation -- braille users navigate cell by cell using screen reader table commands
General Design Principles for All Assistive Technologies
The Universal Requirements
-
Everything keyboard accessible -- This is the foundation. Every AT builds on keyboard support.
-
Clear, consistent focus management -- All ATs need to track where the user is.
-
Semantic HTML -- Assistive technologies rely on the accessibility tree. Semantic elements create correct tree nodes automatically.
-
Visible, descriptive labels -- Voice control needs them. Screen readers need them. Magnifier users need them near their controls.
-
Large, well-spaced targets -- Switch, eye tracking, and magnification all benefit.
-
No time pressure -- Switch and eye tracking users are slower. Voice users need time to formulate commands.
-
Simple, predictable interactions -- Every additional step multiplies effort for AT users.
-
Multiple ways to accomplish tasks -- Mouse, keyboard, touch, voice. Never require only one input method.
AT Compatibility Checklist
| Requirement | Screen Reader | Switch | Eye Tracking | Voice | Magnifier | Braille |
|---|
| Keyboard accessible | Yes | Yes | -- | -- | Yes | Yes |
| Large targets (44px+) | -- | Yes | Yes | -- | Yes | -- |
| Visible labels | -- | -- | -- | Yes | Yes | -- |
| Label in name (2.5.3) | -- | -- | -- | Yes | -- | -- |
| No hover-only interactions | Yes | Yes | Yes | Yes | -- | Yes |
| No time limits | -- | Yes | Yes | Yes | -- | -- |
| Content reflows at 400% | -- | -- | -- | -- | Yes | -- |
| Semantic HTML | Yes | Yes | -- | -- | -- | Yes |
| ARIA live regions | Yes | -- | -- | -- | -- | Yes |
| Proximity of related info |
Testing Priority Matrix
If you can only test with limited assistive technologies, prioritize in this order:
- Keyboard only -- Catches the most issues; foundation for all AT
- Screen reader (NVDA or VoiceOver) -- Validates the accessibility tree
- Screen magnifier at 400% zoom -- Catches layout and proximity issues
- Voice control -- Catches label-in-name issues
- Switch access -- Validates scan order and interaction efficiency
Resources
| Resource | URL | Content |
|---|
| ARIA Authoring Practices Guide | w3.org/WAI/ARIA/apg | Widget patterns and keyboard interaction |
| Switch Access on Android | support.google.com | Setup and configuration guide |
| iOS Switch Control | support.apple.com | Setup and configuration guide |
| Tobii Eye Tracking | tobii.com | Eye tracking hardware and software |
| Dragon NaturallySpeaking | nuance.com | Professional voice control |
| Talon Voice | talonvoice.com | Open-source programmable voice control |
| ZoomText | freedomscientific.com | Professional screen magnification |
| NVDA | nvaccess.org | Free screen reader for Windows |
Process
- Gather information. Ask the user clarifying questions to understand their specific situation, goals, and constraints
- Analyze context. Review the information provided and identify key factors relevant to assistive technology guide
- Develop recommendations. Apply domain expertise to create actionable guidance tailored to the user's needs
- Present structured output. Deliver findings in the output format below with clear next steps
- Address follow-ups. Answer additional questions and refine recommendations based on feedback
Output Format
## Assistive Technology Guide Analysis
### Assessment
[Key findings and observations]
### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]
### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]
Edge Cases
- Incomplete information: Ask clarifying questions before proceeding with recommendations
- Conflicting requirements: Prioritize the most critical constraint and note trade-offs
- Out of scope requests: Redirect to appropriate specialized skill or professional resource
- Beginner vs advanced: Adjust depth and terminology based on user's experience level
Example
Input: "Help me with assistive technology guide for my current situation"
Output:
Based on your situation, here is a structured approach to assistive technology guide:
- Assessment: Evaluate your current state and identify key areas for improvement
- Strategy: Develop a targeted plan based on best practices
- Implementation: Execute the plan with specific, measurable steps
- Review: Monitor progress and adjust as needed
