How to Test Your Game for Screen Reader Accessibility

Screen reader support is the most underappreciated corner of game accessibility. Subtitles get attention. Colorblind palettes get attention. Large text gets attention. Screen readers — the interface that lets blind and low-vision players actually launch the game — almost never do. The good news is that covering just the menus (not gameplay) is achievable in a few days of work, and the bad news is that most games have not done even that much. Here is how to test your game, find the gaps, and fix them.

What a Screen Reader Needs From You

A screen reader is a piece of software that reads UI elements aloud as the user navigates with the keyboard. It works by asking the OS accessibility API: "What is the currently focused element? What is its label? What kind of element is it (button, slider, text input)?"

For a web page, the browser exposes all of this automatically via the DOM. For a game, the engine has to implement the bridge from its internal UI system to the platform's accessibility API. Out of the box, Unity, Unreal, and Godot (before 4.3) do not do this. Your menu is a black box to the OS, and a screen reader traversing your game hears silence or worse, "unknown" for every element.

The minimum a screen reader needs to work is:

• Focus tracking. When focus moves, the OS accessibility tree must update to reflect the new focused element.
• Element labels. Every focusable element has a text label.
• Element roles. The OS knows whether each element is a button, a slider, a checkbox, etc.
• State changes. When a checkbox toggles or a slider moves, the OS is notified.
• Live regions. Dynamic text updates (like "Saving..." messages) are announced.

Step 1: Run Your Game With a Screen Reader On

Before you write any code, experience your game the way a blind player would:

• Windows: Install NVDA, a free open-source screen reader. Launch it, then launch your game.
• macOS: Cmd+F5 toggles VoiceOver.
• Android: Settings → Accessibility → TalkBack.
• iOS: Settings → Accessibility → VoiceOver.
• Steam Deck: No built-in screen reader; test with the Deck plugged into a desktop and running NVDA on the host.

Navigate the main menu using only Tab, arrow keys, and Enter. Do not look at the screen. Can you hear what each menu option is? Can you tell which one is focused? Can you configure audio volume without sight?

For most games, the answer is a humbling "no". NVDA says nothing, or says "unknown frame", or announces the whole window as one element. This is the baseline you are starting from.

Step 2: Add an Accessibility Layer

The mainstream approach in 2026 is AccessKit, a cross-platform Rust library with bindings for C, C++, C#, and other languages. It provides a unified API that translates your UI elements into the right platform accessibility API automatically. Unity, Unreal, and Godot can all integrate with it.

Godot 4.3 and later has built-in screen reader support through an internal AccessKit integration. If you are on a newer Godot version, you can enable it with a project setting:

# project.godot
[accessibility]

general/accessibility_support=true

For Unity, use the AccessKit Unity integration or build a thin wrapper over UIAutomation on Windows and AX API on macOS. Unreal has a built-in SlateAccessibility system you can enable in Project Settings → Accessibility.

Step 3: Label Every Focusable Element

Once the platform bridge is in place, you need to make sure every focusable element has a useful label. Auto-derived labels from button text work for buttons but fail for icon-only buttons, image tiles, and custom widgets.

// Unity example with a custom Label component
public class AccessibleButton : MonoBehaviour
{
    [SerializeField] string accessibilityLabel;
    [SerializeField] string accessibilityHint;  // optional tooltip-like hint

    void Start()
    {
        if (string.IsNullOrEmpty(accessibilityLabel))
        {
            // Fall back to visible text if no explicit label set
            var text = GetComponentInChildren<TMP_Text>();
            accessibilityLabel = text != null ? text.text : gameObject.name;
        }
        AccessibilityBridge.Register(this, accessibilityLabel, accessibilityHint);
    }
}

Walk through every screen in your game and tag every button, slider, dropdown, and list item. Icon-only buttons need explicit labels ("Inventory", "Settings", "Close"), not just "Button 3". Sliders need a label and a current value announcement ("Music volume: 60%").

Step 4: Announce State Changes

When the game state changes in a way that affects the player, announce it:

AccessibilityBridge.Announce("Save complete");
AccessibilityBridge.Announce("Volume: 60 percent");
AccessibilityBridge.Announce("Checkpoint reached");

These are called "live region updates" in accessibility parlance. They do not move focus; they just emit a spoken announcement. Use them sparingly for important events but not for routine updates that would overwhelm the player.

Step 5: Test Every Target Platform

Different screen readers have different quirks. A game that works with NVDA on Windows may fail with VoiceOver on Mac because of subtle differences in how the two tools interpret the accessibility tree. Test the same flows on each platform you ship to:

• Launch the game
• Navigate main menu with Tab/Arrow keys
• Open Settings, change volume, save and return
• Start a new game or load an existing save
• Return to main menu via pause menu
• Quit the game

If all six work end-to-end with audio only, you have achieved the minimum accessibility bar that makes your game usable by blind players.

Step 6: Automate What You Can

Screen reader testing is largely manual, but you can automate the "is every element labeled" check. Add an assertion in your test suite:

[Test]
public void All_Menu_Buttons_Have_Accessibility_Labels()
{
    SceneManager.LoadScene("MainMenu");
    var buttons = Object.FindObjectsOfType<Button>();
    foreach (var b in buttons)
    {
        var acc = b.GetComponent<AccessibleButton>();
        Assert.IsNotNull(acc, $"Button '{b.name}' missing AccessibleButton");
        Assert.IsFalse(string.IsNullOrEmpty(acc.accessibilityLabel));
    }
}

This catches regressions when a new button lands without an accessibility label. Run it in CI on every PR.

Step 7: Get Feedback From Actual Users

The highest-value step is finding blind playtesters and asking them to try your game. Organizations like Can I Play That, AbleGamers, and various Discord communities can connect you with players who use screen readers daily and can tell you in ten minutes what is broken.

Offer them a free copy of the game in exchange for feedback. Budget a week of work to address their findings. The result is a game that works for an audience you previously excluded, and players who are the most loyal fans you will ever have because they almost never get games that work at all.

"Blind players will not wishlist your game if they cannot read the Steam page. They will not buy it if they cannot navigate the store. And they will not play it if they cannot launch it. Accessibility is table stakes."

Related Issues

For broader accessibility testing across physical disabilities see accessibility testing for indie games. For UI snapshot testing that catches visual regressions (a useful complement to a11y testing) read visual snapshot testing for game UI regressions.

Ten minutes with NVDA is more useful than ten days of reading accessibility guidelines. Turn it on.