Use when designing any player-facing feature, evaluating a game for accessibility, responding to accessibility feedback, designing difficulty or assist options, adding subtitle/caption systems, implementing input remapping, or when a player reports they can't play. Covers the four accessibility pillars (visual, auditory, motor, cognitive), implementation tiers, colorblind design, subtitle standards, input accessibility, and testing methodology. Accessibility is a design discipline, not a post-launch checklist.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use when designing any player-facing feature, evaluating a game for accessibility, responding to accessibility feedback, designing difficulty or assist options, adding subtitle/caption systems, implementing input remapping, or when a player reports they can't play. Covers the four accessibility pillars (visual, auditory, motor, cognitive), implementation tiers, colorblind design, subtitle standards, input accessibility, and testing methodology. Accessibility is a design discipline, not a post-launch checklist.
Accessibility Design
Purpose: Make games playable by the widest possible audience through deliberate, integrated design. Accessibility isn't a feature you bolt on โ it's a lens you design through. Games designed for the margins are better for everyone.
Standards: This skill draws on WCAG (Web Content Accessibility Guidelines), the Xbox Accessibility Guidelines (XAG), and the Game Accessibility Guidelines (gameaccessibilityguidelines.com). These represent industry consensus, not aspirational ideals โ major platforms now require or incentivize compliance.
Sources: The Game Accessibility Guidelines (gameaccessibilityguidelines.com), a collaborative industry/academic/specialist resource, are the practical baseline and the origin of the basic/intermediate/advanced tiering this skill's tiers follow. Contrast ratios are WCAG 2.1 (W3C). Colourblindness prevalence (~8% of men, ~0.5% of women of northern-European descent, so ~4-5% of a general population) is standard clinical epidemiology โ the frequently-quoted "10% of players" figure is too high and this skill does not use it. Input and hardware guidance follows the AbleGamers Foundation and Microsoft's Inclusive Design toolkit.
Core Principle: Accessibility Is Design
When a player says "I can't play this" โ that's a design failure, not a player limitation.
Accessibility features aren't accommodations for edge cases. They're design improvements that happen to be essential for some players and beneficial for all.
"Accessibility" Feature
Who It Was "For"
Who Actually Uses It
Subtitles
Deaf/hard-of-hearing players
Everyone on public transit, in noisy rooms, or with sleeping partners
Remappable controls
Players with motor disabilities
Everyone with a preference or non-standard controller
High contrast mode
Low-vision players
Everyone on a mobile screen in sunlight
Adjustable text size
Vision-impaired players
Everyone sitting far from a TV
Difficulty options
Cognitive accessibility
Everyone whose skill level doesn't match one preset
Motion reduction
Vestibular disorders
Everyone who gets motion sick from excessive camera shake
This is the curb-cut effect: design for the margins and the center benefits automatically.
Design rule: If a feature helps 5% of players and harms 0%, ship it.
The Four Pillars
Accessibility barriers organize into four categories based on the player need they address. Most games have gaps in all four โ prioritize by the tiers in the next section.
Pillar 1: Visual
Players who are blind, have low vision, are colorblind, or are photosensitive.
Barrier
Solution
Standard
Color-only information
Add shape, pattern, text, or position as redundant channel
WCAG 1.4.1, XAG 106
Small text
Scalable text, minimum 28px at 1080p for body text
XAG 102
Low contrast
4.5:1 ratio for text, 3:1 for large UI elements
WCAG 1.4.3 (AA)
No screen reader support
Semantic UI structure, text alternatives for images
WCAG 1.1.1
Fixed UI scale
Independent UI scaling separate from resolution
XAG 102
Photosensitive content
No flashing above 3Hz, option to disable screen effects
Text chat alternative, ping systems, visual callouts
XAG 107
Pillar 3: Motor
Players with limited mobility, dexterity, or stamina โ including temporary conditions (broken arm, RSI).
Barrier
Solution
Standard
Hardcoded controls
Full remapping for ALL inputs, no exceptions
XAG 104
Hold-to-activate only
Toggle/hold option for every sustained input (sprint, aim, crouch)
XAG 104
Rapid button mashing
Alternative input (hold, auto-complete, reduced threshold)
GAG intermediate
Precision timing
Adjustable timing windows, generous input buffers
XAG 109
Complex simultaneous inputs
Simplification options, sequential alternatives
GAG advanced
Fixed sensitivity
Adjustable dead zones, sensitivity curves, acceleration
XAG 104
No one-handed play
Alternative control schemes, copilot mode
GAG advanced
Pillar 4: Cognitive
Players with cognitive disabilities, learning differences, ADHD, anxiety โ or anyone overwhelmed by complexity.
Barrier
Solution
Standard
Single difficulty preset
Multiple options, ideally granular per-parameter
XAG 109
Unforgiving timing
Pauseable gameplay, adjustable game speed
XAG 109
Unclear objectives
Objective markers, quest logs, waypoint systems
GAG basic
No save flexibility
Save anywhere, generous autosave
GAG basic
Unreplayable tutorials
Tutorial replay from menu, contextual hints
GAG basic
Information overload
Adjustable HUD density, progressive disclosure
See player-ux
Distressing content
Content warnings, option to skip/reduce intensity
GAG intermediate
Complex navigation
Minimap, breadcrumbs, "return to path" button
GAG intermediate
Cognitive accessibility has the broadest overlap with general UX quality โ this is where accessibility and player-ux (cognitive load management) directly converge.
Implementation Tiers
Prioritize by ratio of players impacted to implementation cost.
Tier 1 โ Must-Have (ship before launch)
Each line is checkable, and carries why it is Tier 1.
No information conveyed by colour alone. Every colour distinction has a
redundant channel (shape, icon, text, position). ~8% of men and ~0.5% of
women of northern-European descent have a colour-vision deficiency; free if
designed in, expensive to retrofit.
Text scales to at least 28px at 1080p โ body text, UI labels, item
descriptions. Starting value; test at your actual target viewing distance.
Contrast meets WCAG AA โ 4.5:1 for text, 3:1 for UI components.
Motion reduction option for camera shake, screen effects, parallax.
Roughly 35% of US adults over 40 have experienced vestibular dysfunction
(NIDCD); this is not a niche setting.
No flashing above 3Hz, or a reliable reduce/skip option. Photosensitive
epilepsy โ this one can cause physical harm.
Every input remappable. No hardcoded bindings. Also a platform
certification requirement on major consoles.
Toggle/hold option for every sustained input. Minimal cost, large RSI
and mobility impact.
Subtitles with speaker identification. ~15% of adults have some hearing
loss.
Independent volume sliders for music, SFX, and voice at minimum.
Difficulty options โ three presets, or granular parameters. Benefits the
widest range of players of anything on this list.
Pauseable at any time during gameplay. Exception: competitive
multiplayer. Essential for parents, interruptions, and anxiety.
Clear objective/waypoint system, toggleable off for players who prefer
to navigate unaided.
Tutorials are clear and dismissible.
Tier 2 โ Should-Have (first major update)
Colourblind simulation tested for protanopia, deuteranopia, and tritanopia
Full screen-reader support for menus
Adjustable text speed and dialogue auto-advance
Camera sensitivity, FOV, and motion-blur controls
Input timing windows adjustable (hold duration, double-tap gap, QTE windows)
Captions for non-speech audio, not just dialogue
Aim assist or targeting assist as an option
Visual indicators for directional audio cues
Save-anywhere, or generous checkpointing
Reduced-complexity UI mode
Tier 3: Best-in-Class (Industry Leadership)
Pillar
Feature
Notes
Visual
Screen reader support
Requires semantic UI architecture; plan early if targeting this
Visual
Full audio descriptions for cutscenes
Significant production cost; high impact for blind players
Motor
Full input device customization (curves, macros)
Power-user feature with accessibility benefit
Motor
Copilot mode (two controllers, one character)
Enables assisted play; social accessibility
Auditory
Text-to-speech for in-game text
Leverages platform TTS APIs
Cognitive
Adaptive difficulty (invisible)
See progression-systems for implementation patterns
All
Comprehensive accessibility menu with previews
Let players see the effect of each option before committing
Colorblind Design
Common, frequently implemented poorly, and fixable at the design level rather than through post-hoc filters.
Prevalence and Types
Type
Affects
Confusion Pairs
Prevalence (Males)
Protanopia/protanomaly
Red perception
Red-green, red-brown, red-orange
~6%
Deuteranopia/deuteranomaly
Green perception
Green-red, green-brown, green-yellow
~5%
Tritanopia/tritanomaly
Blue perception
Blue-yellow, blue-green
~0.01%
Combined: roughly 1 in 12 males and 1 in 200 females have some form of color vision deficiency.
The Design Rule
Never use color as the sole channel for information. Pair every color distinction with shape, pattern, text, position, size, or brightness. Examples: team indicators use circle vs. triangle (not just red vs. blue), rarity uses border patterns (not just color tints), status effects show names (not just colored icons).
Implementation Approaches (Worst to Best)
Approach
Problems
Hue shift (rotate palette)
Breaks art direction, creates new conflicts
Palette swap (preset palettes)
Requires maintenance, still color-dependent
Symbol overlay (shapes on top of color)
Good redundancy, but feels bolted on
Universal design (base palette works for all)
Best โ no "mode" needed, benefits everyone
Contrast Requirements
Element
Minimum Ratio
Standard
Body text
4.5:1 against background
WCAG AA
Large text (24px+ or 18px+ bold)
3:1 against background
WCAG AA
UI components and graphical objects
3:1 against adjacent colors
WCAG 1.4.11
Enhanced (Tier 3 goal)
7:1 text, 4.5:1 UI
WCAG AAA
Testing Colorblind Design
Simulate all three types during development using OS-level filters (macOS: Accessibility > Display > Color Filters; Windows: Color Filters). Test every screen where color conveys meaning โ minimaps, rarity indicators, health bars, team colors, status effects, quest markers. If you can't distinguish two elements in simulation, players can't either.
Difficulty and Assist Systems
Difficulty Is an Access Ramp
Difficulty options are the same category of design as remappable controls โ different players have different needs, and a single fixed experience excludes people. Reframe: "easy mode" โ "flexible difficulty respecting player time and ability"; "assist features" โ "player agency over their own experience."
Granular > Preset
Simple Easy/Medium/Hard presets are better than nothing, but granular options give players agency over their specific barriers:
Parameter
What It Controls
Why Separate
Damage received
Incoming damage multiplier
Player may want challenge but bruise easily
Damage dealt
Outgoing damage multiplier
Player may want long fights but not impossible ones
Timing windows
Parry/dodge/QTE timing
Motor accessibility without changing difficulty of everything else
Resource scarcity
Drop rates, ammo, healing
Exploration vs. survival tension is taste, not skill
Enemy aggression
How often enemies attack
Pace control
Navigation assist
Waypoints, pathfinding hints
Cognitive load management
Aim assist
Auto-aim strength, snap-to-target
Motor + precision accessibility
Puzzle hints
Hint frequency and directness
Cognitive accessibility without skipping content
Content Locking
Never lock story, areas, or abilities behind difficulty. Achievements, cosmetics, and leaderboard eligibility are fine difficulty gates โ narrative content is not.
Adaptive Difficulty
Invisible adjustment based on player performance โ the most accessible approach because it requires zero configuration. Track death frequency, completion time, and resource usage; adjust subtly (fewer spawns, wider timing windows, better drop rates). Never reveal the adaptation and always provide opt-out. See progression-systems for flow channel targeting.
Subtitle and Caption Design
Bad subtitles are worse than none โ they create false confidence that deaf/HoH players are getting the full experience.
Subtitle Requirements
Element
Requirement
Rationale
Speaker identification
Name label and/or consistent color per speaker
Players can't identify speakers by voice
Font size
Adjustable, minimum 24px at 1080p, recommended default 28px
No ALL CAPS for full sentences (reduces readability by ~10%)
Mixed case is faster to read
Caption Design (Beyond Subtitles)
Captions describe non-speech audio โ essential for deaf/HoH ambient narrative and threat awareness.
Audio Type
Example
Environmental
[distant thunder], [rain on metal roof]
Directional
[footsteps approaching from behind]
Music/mood
tense orchestral music builds
Gameplay SFX
[alarm blaring], [shield breaking]
Off-screen speech
Guard [off-screen]: "Did you hear something?"
Scaling Reference
Scale proportionally with resolution: 24px minimum at 1080p โ 48px at 4K. Recommended defaults: 28px at 1080p, 56px at 4K. Always offer a generous maximum (2x the default).
Input Accessibility
Remapping Requirements
Every input must be remappable โ no exceptions for "core" actions
Support per-context remapping (menu vs. gameplay can differ)
Allow multiple inputs bound to the same action
Show current bindings in tutorials (don't show "Press X" if rebound to B)
Detect and warn about conflicts, but allow them
Persist bindings across sessions
Toggle vs. Hold
Every sustained input needs a toggle/hold setting:
Action
Hold (Default)
Toggle (Accessible)
Sprint
Hold stick + button
Click once to start, once to stop
Aim down sights
Hold trigger
Click to enter, click to exit
Crouch
Hold button
Click to crouch, click to stand
Fly/hover
Hold button
Click to engage, click to disengage
Input Timing
Setting
What It Controls
Range
Dead zone
How far a stick moves before registering
0-50% (default 15-20%)
Sensitivity
Input-to-camera/cursor speed
0.1x-3.0x
Acceleration
Sensitivity increase with input duration
Off to aggressive
Input buffer
How long before an action that an input is accepted
0-500ms
QTE timing
Time window for quick-time events
0.5x-3.0x (multiplier on base window)
Copilot Mode
Two controllers control one character simultaneously โ no switching. Enables parent-child assisted play, friend-assisted play for motor disabilities, and therapeutic use. Implementation: merge inputs from both devices, resolve conflicts by last-input-wins.
Touch Accessibility
For mobile/touch-enabled games: minimum 44x44px touch targets (48x48px recommended), 8px minimum spacing between targets, tap alternatives for every swipe/pinch gesture, adjustable touch-and-hold duration (200-1000ms).
Testing Accessibility
Accessibility testing is not general playtesting โ "any 5 players" won't surface accessibility barriers.
Testing Methods
Method
What It Catches
When to Use
Automated tools
Contrast violations, missing alt text, color-only indicators
Screen reader compatibility, switch controller support
If targeting Tier 3 features
Simulation Testing Checklist
Sound muted โ can you complete every objective?
Colorblind simulation (all three types) โ can you distinguish all meaningful elements?
One hand only โ is it physically possible?
Minimum text size at TV distance โ can you read everything?
Photosensitive check โ any flashing above 3Hz?
Keyboard-only (no mouse) โ are any features inaccessible?
Easiest difficulty โ can a player struggling with timing/precision finish the game?
Recruiting Players with Disabilities
Standard playtest recruitment won't surface accessibility barriers. Partner with disability advocacy and gaming organizations, post in disability-focused gaming communities, compensate fairly, and ensure the testing environment itself is accessible. Don't combine accessibility testing with general playtesting โ the goals and recruitment differ.
See playtest-design for general methodology, but treat accessibility testing as a specialized discipline.
Accessibility Health Check
The Tier 1 and Tier 2 lists above are the checklist. Run them directly.
Anti-Patterns
Anti-Pattern
Better Approach
Single "Accessibility Mode" toggle
Individual toggles per feature โ players need some but not all
Colorblind mode = hue shift filter
Redesign palette for universal clarity; use redundant channels
"Git gud" as response to accessibility requests
Offer options; never gatekeep the experience
Unskippable cutscenes
Always skippable or pauseable
Rapid button-mashing with no alternative
Hold-to-complete or auto-complete alternative
Tiny text, no scaling
Always support text scaling with a generous range
"We'll add accessibility later"
Design accessible from the start โ retrofitting is expensive
Accessibility settings buried in sub-menus
Surface in first-run setup; dedicated section in main settings
Fixed subtitle appearance
Adjustable font size, background opacity, color, and position
Audio-only threat indicators
Pair every audio cue with a visual indicator
Auto-advancing dialogue
Player-paced advancement (press to continue)
Cross-References
Three tight links. Everything else routes through the map, so adding a skill
touches one file rather than twenty: references/routing-map.md (in
game-design).
player-ux โ The cognitive-load layer this extends
audio-design โ Audio as an accessibility channel, and its failure modes
game-feel โ Redundant feedback channels are an access requirement
