How to Test Your Game for Accessibility

Step 1: Run Automated Accessibility Audits

Automated tools scan your HTML and report WCAG violations. They check for missing alt text on images, insufficient color contrast, missing form labels, invalid ARIA attributes, empty buttons, missing document language, heading hierarchy violations, and other machine-verifiable criteria. These tools cannot evaluate subjective quality (is this alt text actually helpful?) or interactive behavior (does focus move correctly when this menu opens?), but they catch low-hanging fruit quickly.

Lighthouse (built into Chrome DevTools, Audits tab) runs an accessibility audit and reports violations with severity levels and links to WCAG criteria. Run Lighthouse on every screen of your game: the main menu, settings, pause screen, inventory, dialogue, game over, and any other UI state. Each screen may have different violations.

axe DevTools (browser extension by Deque) provides more detailed and accurate results than Lighthouse for accessibility specifically. It highlights the exact elements with violations, explains why each is a problem, and suggests fixes. The axe-core library can also be integrated into automated testing pipelines to run accessibility checks as part of your CI/CD process.

WAVE (web accessibility evaluation tool by WebAIM) provides a visual overlay showing accessibility issues directly on the page. It highlights contrast errors, missing labels, and structural problems with icons positioned at the offending elements. This visual approach is helpful for understanding where on the screen problems exist.

Fix every issue these tools report before moving to manual testing. If automated tools find 15 violations, fixing them first means manual testing can focus on the harder, more nuanced issues rather than rediscovering problems that a machine could have caught.

Step 2: Test with Keyboard Only

Disconnect your mouse or disable it in system settings. Navigate your entire game using only the keyboard: Tab to move between interactive elements, Enter or Space to activate buttons, arrow keys to navigate within menus, Escape to close dialogs. Do this for every screen in the game.

Check the following: Focus visibility means you can always see which element is currently focused. If the focus indicator disappears at any point, you have a CSS issue (likely a global outline: none rule). Focus order means the Tab key moves through elements in a logical order that matches the visual layout. If focus jumps from the top-left to the bottom-right and then back to the middle, the DOM order does not match the visual order and needs fixing with tabindex or DOM restructuring. No focus traps means you can always Tab or Escape out of any component. If focus gets stuck inside the canvas element or a custom widget with no exit, that is a critical failure.

All functionality accessible means every action you can perform with a mouse (clicking buttons, adjusting sliders, selecting items, navigating menus, starting the game, accessing settings, pausing) is also possible with keyboard alone. If any action requires a mouse click on a specific position without a keyboard alternative, that is an accessibility failure. Common culprits: canvas-only interactions with no keyboard binding, drag-and-drop with no keyboard alternative, hover-only tooltips with no focus equivalent.

This test also validates your remappable controls system: try rebinding controls using only the keyboard to verify the rebinding UI itself is keyboard-accessible.

Step 3: Test with a Screen Reader

Turn on a screen reader and navigate your game with your eyes closed (or with the monitor off). On Windows, use NVDA (free download). On macOS, use VoiceOver (built in, activate with Cmd+F5). On iOS, use VoiceOver (Settings > Accessibility). On Android, use TalkBack (Settings > Accessibility).

Navigate every menu, open every settings panel, read every dialogue box, browse the inventory, and interact with every UI element. Listen for: element announcements (does the screen reader say what each element is? "Play button," "Volume slider, 75%," "Settings heading level 2"), state changes (when you toggle a setting, does the screen reader announce the new state? "Subtitles, checked" or "Subtitles, not checked"), dynamic content (when game state changes like health updates, score changes, or quest completions, do ARIA live regions announce them?), and focus management (when a menu opens, does focus move to it? When it closes, does focus return to where it was?).

Write down every point where you get confused, miss information, or cannot complete an action. These are your screen reader accessibility failures. Common issues: buttons that announce nothing (add aria-label), menus that do not receive focus (add element.focus() calls), game events that are not announced (add aria-live regions), and decorative elements that are read aloud unnecessarily (add aria-hidden="true"). See the screen reader support guide for fixing these issues.

Step 4: Test with Colorblind Simulation

Open Chrome DevTools, press Ctrl+Shift+P, type "rendering," select "Show Rendering," and scroll to "Emulate vision deficiencies." Test your game under Deuteranopia (green-weak), Protanopia (red-weak), and Tritanopia (blue-weak) simulation. Play through representative gameplay under each mode.

Verify that all gameplay-critical distinctions remain visible: team markers are distinguishable, health bar states are readable, item rarities are identifiable, interactive objects stand out from backgrounds, danger indicators are visible, and any color-coded information has a non-color alternative. If any distinction disappears under simulation, the element needs either a better color choice or a non-color redundant indicator (shape, text label, icon, pattern).

Also check your colorblind mode presets if you have implemented them. Switch to each preset (Deuteranopia, Protanopia, Tritanopia) in your game settings, then enable the corresponding Chrome simulation mode. The simulated view of your colorblind preset should show all elements as clearly distinguishable. If your deuteranopia preset still has indistinguishable elements under deuteranopia simulation, the preset's palette needs adjustment.

Step 5: Test at 200% Zoom and with Muted Audio

Zoom test: Navigate to your game in the browser and press Ctrl+Plus (Cmd+Plus on Mac) until the browser shows 200% zoom. Navigate every screen. Verify: no text is clipped or truncated, no buttons overlap or go off-screen, menus remain scrollable if they exceed the viewport, interactive elements remain clickable/tappable with correct hit areas, and the game canvas is still functional. Any layout breakage at 200% is a WCAG 1.4.4 failure and indicates that fixed pixel sizing is used where relative units should be.

Muted audio test: Mute all audio (system mute, not just the game's volume slider). Play through the entire game. Note every moment where you miss information, miss a cue, or cannot complete an action because the information was delivered only through sound. Each missing visual cue represents a barrier for deaf and hard-of-hearing players. Common failures: audio-only warnings, sound-based puzzle solutions, spoken dialogue without subtitles, directional audio cues without visual indicators, and timer countdowns that only beep.

Both of these tests are simple enough to add to your regular QA checklist and catch a wide range of accessibility issues that automated tools cannot detect. They also serve as a quick regression check after UI changes: if something breaks at 200% zoom, you introduced a layout problem.

Step 6: Recruit Disabled Playtesters

User testing with disabled players is the most valuable form of accessibility testing and the one most developers skip. A blind player will find screen reader issues that your eyes-closed testing missed. A player with cerebral palsy will discover motor control assumptions you did not know you made. A player with ADHD will reveal cognitive load problems that seem fine to a neurotypical tester.

Organizations that connect game developers with disabled testers include: AbleGamers (ablegamers.org), which offers player panels and accessibility consultation, SpecialEffect (specialeffect.org.uk), which works with physically disabled gamers, Can I Play That? (caniplaythat.com), which publishes accessibility reviews and connects developers with disabled reviewers, and Game Accessibility Nexus, a community of disabled gamers and accessibility advocates.

When conducting user testing, observe without intervening. Let the tester play naturally and struggle with barriers before offering help. Take detailed notes on where they struggle, what confuses them, and what works well. Ask them to think aloud about their experience. After the session, ask what they would change and which barriers were the most frustrating. The feedback from a single testing session with a disabled player is worth more than any automated tool report.

If formal user testing is not feasible, post your game in disability gaming communities (the Accessible Gaming subreddit, disability gaming Discord servers, AbleGamers forums) and ask for feedback. Disabled gamers are often willing to test games from developers who genuinely care about accessibility, and their feedback is specific, actionable, and invaluable.