Screen Reader Support for Browser Games: ARIA, Focus Management, and Live Regions

What Screen Readers Can and Cannot Do in Games

Screen readers (NVDA on Windows, VoiceOver on macOS/iOS, TalkBack on Android, JAWS on Windows) read the content of HTML elements, announce their roles and states, and let users navigate by keyboard. They work well with structured content: headings, lists, buttons, links, form controls, tables, and ARIA-annotated custom components. They do not work with canvas elements, because a canvas is a bitmap image to the browser, with no semantic structure for the screen reader to interpret.

This creates a clear division in web game accessibility. Everything built with HTML/CSS, which includes main menus, settings screens, pause menus, inventory screens, character sheets, dialogue boxes, quest logs, crafting interfaces, shops, leaderboards, game-over screens, and loading screens, can be fully screen-reader accessible. The game canvas itself, where the real-time action rendering happens, cannot be directly read by a screen reader and must be supplemented with off-screen ARIA elements that describe the game state in text.

For turn-based games, text adventures, visual novels, card games, puzzle games, and other genres where the game state can be fully described in text, screen reader support can make the entire game playable by blind players. For real-time action games, screen reader support provides access to all menus and UI, while the gameplay itself may need additional audio cues (spatial audio, sound effects for events, text-to-speech for game state) to be playable without vision.

Semantic HTML for Game Menus

The simplest and most effective screen reader optimization is using the correct HTML elements for their intended purpose. A menu option should be a button element, not a div with a click handler. A heading should be an h2 or h3, not a styled span. A list of items should be a ul with li children, not a stack of divs. Screen readers announce the role of each element ("button," "heading level 2," "list, 5 items"), which gives blind users context about what they are interacting with. A div with a click handler announces nothing, forcing the user to guess what the element does.

Game menu structure should follow a heading hierarchy. The main menu is an h1 or h2 ("Main Menu"). Sections within it are h3 ("Play," "Settings," "Credits"). Settings subsections are h4 ("Audio," "Video," "Controls"). This hierarchy lets screen reader users jump between headings to navigate the menu quickly, which is far faster than tabbing through every element sequentially.

Use native HTML controls wherever possible. A volume slider should be an input type="range", not a custom div-based slider. A checkbox for "Enable Subtitles" should be an input type="checkbox", not a custom toggle. Native controls have built-in screen reader announcements ("slider, 75%," "checkbox, checked"), keyboard interaction (arrow keys for sliders, Space for checkboxes), and state management. Custom controls require ARIA attributes to replicate this behavior, and most implementations miss something. Native controls are more accessible, more reliable, and less work.

ARIA Roles and Attributes for Game UI

When native HTML elements are insufficient (for custom game UI components that have no HTML equivalent), ARIA provides the vocabulary to make them accessible. The key ARIA attributes for game UI are:

role: defines what the element is. role="menu" for a game menu, role="menuitem" for items within it, role="dialog" for modal panels (pause screen, confirmation dialogs), role="tablist" and role="tab" for tabbed interfaces (inventory categories), role="grid" for grid layouts (item grids, tile maps). The role tells the screen reader how to present the element and what keyboard interactions to expect.

aria-label and aria-labelledby: provide accessible names for elements that do not have visible text labels. An icon-only button needs aria-label="Settings" so the screen reader announces "Settings button" instead of nothing. A game HUD element showing "HP: 75/100" might use aria-label="Health: 75 out of 100" for a clearer announcement.

aria-live: marks a region whose content changes dynamically and should be announced by the screen reader when it updates. This is critical for game state information. An element with aria-live="polite" announces changes after the screen reader finishes its current announcement. An element with aria-live="assertive" interrupts immediately, which is appropriate for urgent game events (low health warning, enemy approaching, timer running out).

aria-expanded, aria-selected, aria-checked: communicate the state of interactive elements. A collapsible section uses aria-expanded="true" or "false." A selected inventory item uses aria-selected="true." A toggled setting uses aria-checked="true." These attributes must be updated in JavaScript when the state changes, or the screen reader will announce stale information.

aria-hidden="true": hides decorative or redundant elements from the screen reader. Purely visual decorations (particle effects described in a separate text element, background art, animated borders) should have aria-hidden="true" so the screen reader skips them. This reduces clutter in the audio experience and lets blind users focus on meaningful content.

Focus Management

Focus management determines which element the screen reader is currently reading and which element receives keyboard input. In web games, poor focus management is the most common screen reader accessibility failure. When a menu opens, focus should move to the first item in that menu. When a menu closes, focus should return to the element that opened it. When a modal dialog appears (pause screen, confirmation prompt), focus should be trapped within the dialog until it is dismissed, preventing the user from tabbing to elements behind the dialog that they cannot see.

Use element.focus() to programmatically move focus when game state changes. When the player opens the inventory, call the first inventory item's focus() method. When the player closes the inventory, call the "open inventory" button's focus() method to return focus to where it was. When a dialogue box appears, focus the first response option. When dialogue ends, return focus to the game.

Focus trapping for modal dialogs prevents the tab key from moving focus outside the dialog. Implement this by listening for keydown on the dialog element and, when the user presses Tab on the last focusable element, wrapping focus back to the first focusable element (and vice versa for Shift+Tab). This is a standard web accessibility pattern and libraries like focus-trap provide ready-made implementations.

Focus indicators (the visible outline showing which element has focus) must be visible at all times during keyboard navigation. The CSS outline property provides the default focus indicator. Never apply outline: none globally; instead, use the :focus-visible pseudo-class to show focus indicators only during keyboard navigation (hiding them for mouse clicks), or provide a custom focus style that is more visible than the browser default.

Live Regions for Game State

ARIA live regions are the primary mechanism for communicating dynamic game information to screen readers. A live region is an HTML element with the aria-live attribute that the screen reader monitors for content changes. When the content changes, the screen reader announces the new content.

Create a hidden (visually hidden, not display: none) element for game announcements. Use CSS to position it off-screen: position: absolute; width: 1px; height: 1px; overflow: hidden; clip: rect(0,0,0,0). Set aria-live="polite" on this element. When a game event occurs that the player needs to know about, update the element's textContent. The screen reader will announce the new text.

Examples of game events to announce via live regions: "Health low, 20% remaining" (use aria-live="assertive" for urgency), "Quest completed: Find the red key" (polite), "New item acquired: Healing Potion" (polite), "Enemy approaching from the east" (assertive), "Score: 1500" (polite, update periodically, not every frame), "Game paused" and "Game resumed" (polite), "Level 3 starting" (polite).

Do not update live regions every frame. Screen readers cannot process 60 announcements per second, and attempting this will cause a garbled, unusable audio stream. Update live regions only when meaningful state changes occur: health drops below a threshold, a new enemy appears, a pickup is collected, a level is completed. For continuously changing values like score, update the live region at most once per second or when the value crosses a milestone (every 100 points, every level-up).

Testing with Screen Readers

Test with an actual screen reader, not just the accessibility tree in DevTools. NVDA (free, Windows) and VoiceOver (built into macOS) are the two essential screen readers for testing web content. Install NVDA, turn it on, close your eyes, and try to navigate your game menus using only the keyboard and audio. Every point where you get stuck, confused, or lose context is an accessibility failure.

Common failures discovered during screen reader testing: buttons that announce nothing (missing aria-label), menus that do not receive focus when opened (missing focus management), dynamic content that is not announced (missing aria-live), decorative elements that are read aloud unnecessarily (missing aria-hidden), focus getting stuck in the canvas element (missing focus trap or bypass), and settings changes that are not confirmed audibly (missing state announcement).

VoiceOver on macOS uses different keyboard commands than NVDA on Windows. Test on both if your audience includes both platforms. The core navigation pattern is similar (Tab to move between interactive elements, arrow keys to navigate within components), but the specific modifier keys and reading modes differ.