Game Accessibility Guidelines and Standards: WCAG, XAGs, and Legal Requirements

WCAG 2.2 for Game Developers

The Web Content Accessibility Guidelines version 2.2, published by the W3C, is the international reference standard for web accessibility. It defines 87 success criteria across three conformance levels: A (minimum baseline), AA (the level most laws and regulations reference), and AAA (enhanced accessibility). WCAG was designed for web content broadly, not games specifically, but a significant number of its criteria apply directly to the non-gameplay portions of web games: menus, settings screens, dialogue, text content, and any UI that is not the real-time game canvas.

Perceivable criteria that apply to games: Text alternatives for non-text content (1.1.1, Level A) means providing alt text for images and icons in your UI. Captions for audio content (1.2.2, Level A) means subtitling all spoken dialogue. Contrast minimums (1.4.3, Level AA) mean all UI text must have at least a 4.5:1 contrast ratio against its background. Text resize (1.4.4, Level AA) means text must be scalable to 200% without loss of functionality. Content reflow (1.4.10, Level AA) means content should adapt to a 320px viewport width without horizontal scrolling, which affects how your game UI handles mobile screens.

Operable criteria that apply to games: Keyboard accessibility (2.1.1, Level A) means all functionality must be operable through a keyboard interface. No keyboard trap (2.1.2, Level A) means keyboard focus must never get stuck in a component that cannot be exited with standard keys. Seizure prevention (2.3.1, Level A) means no content can flash more than three times per second. Focus visible (2.4.7, Level AA) means the keyboard focus indicator must be visible at all times during keyboard navigation. Pointer cancellation (2.5.2, Level A) means actions should trigger on the up-event, not the down-event, so users can cancel accidental clicks by moving the pointer away before releasing.

Understandable criteria: Language of page (3.1.1, Level A) requires specifying the page language in the HTML lang attribute. Consistent navigation (3.2.3, Level AA) means navigation patterns should be consistent across all pages and screens. Error identification (3.3.1, Level A) means input errors in forms and settings should be described in text.

Where WCAG falls short for games: WCAG has no criteria for real-time interaction difficulty, no framework for input remapping, no guidance on aim assist or motor accommodation in gameplay, and no concept of adjustable game speed. It was designed for static or mildly interactive content, and games exceed its scope in fundamental ways. This is why game-specific guidelines exist to supplement WCAG, not replace it.

Xbox Accessibility Guidelines (XAGs)

Microsoft published the Xbox Accessibility Guidelines in 2020 and has updated them regularly since. They were developed in partnership with disabled gamers, accessibility specialists, game studios, and Xbox's own accessibility team. While designed for Xbox, the XAGs apply to any game on any platform because they address universal game design challenges. Microsoft encourages all developers, not just Xbox developers, to adopt them.

The XAGs define 23 guidelines across several categories. The most relevant ones for web game developers are:

XAG 101: Text display. All text should be resizable. Minimum text size is 28px at 1080p (or equivalent relative size). Provide a background behind text for contrast. Avoid text on busy or animated backgrounds. For web games, this means using rem units, providing a text size slider in settings, and applying a solid or semi-transparent background behind all UI text overlaid on the game canvas.

XAG 102: Contrast. UI elements and text should meet minimum contrast ratios, and a high-contrast mode should be available. This aligns with WCAG 1.4.3 and 1.4.11 but extends it to game-specific elements like health bars, minimap markers, and interactive object highlights.

XAG 103: Color and shape. Never convey information through color alone. Use shape, pattern, text, or icons alongside color. This is the single most impactful guideline for colorblind players and aligns with WCAG 1.4.1. Teams, item rarities, danger zones, interactive vs. non-interactive elements, and any gameplay state communicated by color must have a redundant non-color indicator.

XAG 106: Screen narration. All UI elements should be compatible with screen narration (screen readers or built-in text-to-speech). For web games, this means using semantic HTML for menus, ARIA labels for custom controls, and ARIA live regions for dynamic content updates.

XAG 107: Input. All inputs should be remappable. Support multiple input devices simultaneously. Provide options for toggle vs. hold. Avoid requiring simultaneous button presses (chord inputs) as the only way to perform an action. Allow players to adjust input sensitivity, dead zones, and response curves.

XAG 108: Essential actions. Essential actions should be performable with a single input (one button press, one key, one touch). Complex inputs like simultaneous button presses or multi-finger gestures should always have a simplified alternative.

XAG 109: Adjustable timing. Any time-constrained action should have adjustable or removable time limits. This applies to QTEs, timed puzzles, dialogue auto-advance, and any mechanic where the player must act within a fixed window.

XAG 110: Haptics. If haptic feedback is used, provide visual or audio alternatives. This matters less for web games today since haptic support in browsers is limited, but the Vibration API exists and games that use it should provide alternatives.

XAG 116: Difficulty options. Provide adjustable difficulty with granular controls. Let players adjust specific parameters (enemy speed, damage taken, puzzle time limits) rather than only offering preset difficulty levels. Include options to skip challenging sequences or sections.

Game Accessibility Guidelines (Community Checklist)

The Game Accessibility Guidelines at gameaccessibilityguidelines.com is a community-maintained checklist that organizes accessibility features by implementation difficulty: basic, intermediate, and advanced. It is more practical and less formal than WCAG or the XAGs, which makes it a good starting point for developers new to accessibility.

Basic tier (do these first): Allow difficulty to be adjusted. Ensure controls are remappable. Provide subtitles with a solid background. Avoid using color alone to convey information. Include interactive tutorials. Allow players to progress through text at their own pace. Avoid flickering images. These features serve the broadest audience and cost the least to implement.

Intermediate tier: Provide a practice mode or area. Include a colorblind mode. Support screen reader or narration for menus. Allow game speed adjustment. Provide auto-aim or aim assist. Include one-handed control options. These features require more development effort but serve significant player populations.

Advanced tier: Support external accessibility hardware (switch devices, eye trackers). Provide audio description tracks. Allow complete interface customization. Support braille displays. These features serve smaller populations but can be essential for those players.

European Accessibility Act (EAA)

The European Accessibility Act became fully enforceable in June 2025. It requires digital products and services sold to consumers in the EU to meet accessibility standards defined in EN 301 549, which itself aligns closely with WCAG 2.1 Level AA. The EAA applies to websites, mobile applications, and digital services. Games delivered through the web fall under its scope when they qualify as digital services offered to EU consumers.

The practical impact for web game developers: if your game is accessible to EU players through a web browser, the EAA applies. Your game's menus, settings, text content, and navigation should meet WCAG 2.1 AA. The gameplay itself is harder to regulate, and enforcement has focused on perceivable and operable criteria rather than gameplay mechanics. However, the safest approach is to apply accessibility features across the entire experience.

Penalties vary by EU member state. Some countries impose fines per violation per day; others can order products removed from the market. The enforcement landscape is still developing as of mid-2026, but the trend is clearly toward stricter enforcement, not looser.

Section 508 and the ADA (United States)

Section 508 of the Rehabilitation Act requires federal agencies and organizations receiving federal funding to make their digital content accessible, conforming to WCAG 2.0 Level AA (an older version, but the requirement is effectively WCAG 2.1 AA in practice). This applies directly if your game is used by a government agency, educational institution, or federally funded organization.

The Americans with Disabilities Act (ADA) has been interpreted by federal courts to apply to commercial websites and web applications, although there is no explicit statute covering web content. The DOJ issued updated guidance in 2024 confirming that web accessibility falls under Title III of the ADA. Web games offered as commercial products to the public are not explicitly exempt, and ADA lawsuits against inaccessible web applications have increased steadily since 2018.

The practical approach for US-based web game developers: meet WCAG 2.1 AA for all non-gameplay UI, and implement reasonable accessibility features for gameplay. "Reasonable" is a judgment call, but remappable controls, subtitles, adjustable difficulty, and colorblind support are widely considered baseline expectations.

How to Apply These Standards to Your Game

The overlap between these frameworks is substantial. If you implement the following features, you will satisfy the vast majority of requirements across WCAG, XAGs, the Game Accessibility Guidelines, EAA, and ADA expectations:

For visual accessibility: minimum 4.5:1 contrast for text, scalable UI to 200%, never use color alone for information, provide a colorblind mode, respect prefers-reduced-motion, and add a high-contrast mode. For motor accessibility: remappable controls, toggle vs. hold options, adjustable input timing, and aim assist. For cognitive accessibility: replayable tutorials, consistent navigation, adjustable game speed, objective markers, and plain language text. For audio accessibility: full captions (not just subtitles), separate volume channels, and visual sound indicators.

Start with the Game Accessibility Guidelines' basic tier. Then layer on WCAG AA compliance for your UI. Then adopt XAG recommendations for gameplay mechanics. This progression moves from lowest cost and broadest impact to highest cost and most specialized impact, which is the most efficient use of development resources.