PC accessibility: what to ship, and what it buys you

Updated September 2026 · ShipYourGame

Accessibility on PC gets discussed as a large, vague obligation and then skipped. In practice a small, specific set of options covers the majority of what players ask for, and most of them are a week of work if the settings layer already exists.

Steam now surfaces accessibility information on store pages, so these options are no longer invisible to a shopper deciding between you and a competitor.

The short list

Subtitles. Not just dialogue: sound captions for things the player cannot see. A speaker name, an adjustable size, and a background panel so white text does not vanish over a bright scene. This is the single most requested option in the category.

Text size. One global scale, typically 100% to 200%, that affects the whole interface rather than one label. The hard part is not the scaling, it is that most UIs break when text grows. Test at 200% early; fixing it later means re-laying out every panel.

Colour-vision support. Roughly one in twelve men has some form of colour-vision deficiency. If a colour carries meaning anywhere in your game, red and green health states, team colours, puzzle pieces, then colour alone is not enough. Two things help: never rely on hue by itself, and offer filters that either simulate or correct for protanopia, deuteranopia and tritanopia. The simulation mode is useful to you as a developer, because it shows you your own game as those players see it.

High contrast. A palette with clear semantic roles so background, surface, text, accent and focus stay distinguishable. Cheap if the UI reads colours from one place, expensive if colours are scattered across prefabs.

Reduce motion. A single flag that turns down or off screen shake, camera bob, flashes and sliding UI transitions. It is the least work on this list and it matters enormously to people with vestibular disorders. One gate, applied at every shake and transition call site.

Remappable controls. Already required for other reasons, and it is also an accessibility feature.

What it costs in code

Most of these are cheap if and only if you have a single settings object with change events. The real work is:

• Text scaling that is aware of auto-sizing components and does not compound.
• A subtitle system with timing and a queue, not just a text field you overwrite.
• Colour filters as a post-process for the world and something separate for overlay UI, because an overlay canvas is drawn after the camera effect and will not be filtered by it.
• Reduce motion applied consistently, which means finding every place you shake something.

If you are adding this to a finished game, budget for the retrofit rather than the feature: the feature is small, the retrofit is everywhere.

What to test

• Every screen at 200% text scale. Buttons should grow, not clip.
• Every colour-coded state, with the simulation filter on. Ask whether you can still tell the states apart.
• Subtitles over your brightest and busiest scene.
• Screen shake with reduce motion on, in the one place you forgot.
• With a screen reader running, if you claim screen reader support at all. Claiming it untested is worse than not claiming it.

The commercial part, stated plainly

These options widen who can finish your game, which is the actual reason to do it. They also produce a store page that lists features your competitor's page does not, and they remove a recurring source of one-star reviews that begin "I could not read the text". Both things are true at once and neither needs to be hidden.