Ask a team what they built for accessibility and you will usually hear about screen reader support. Ask how far it got and the answer is normally a partial implementation that nobody has tested with an actual screen reader user, shipped once and never revisited.
That is not a failure of intent, it is a failure of ordering. Screen reader integration is the most expensive item on the accessibility list and it serves the smallest of the four groups. Starting there guarantees a bad first experience with the whole category, and the conclusion teams draw is that accessibility is costly, when what was actually costly was the order they attempted it in.
Why The Backlog Is Usually Sorted Wrong
Accessibility work has an unusually wide spread between cost and reach. Remappable controls are close to trivial in any engine with an input abstraction, and they serve players with limited hand strength, players using one hand, players on adaptive controllers, and a large group with no disability at all who simply want a different layout. Screen reader support needs an accessibility tree, focus management, live region announcements, and a testing loop most studios have never run.
Sorted by impact-to-effort, the list inverts. The features that reach the most players for the least work are remappable controls, subtitles that are on by default and carry speaker labels, a toggle option for every sustained action, and color that never carries meaning on its own. None of those require new architecture, and all of them are cheaper before the interface is finished than after.
The Four Categories, And Where They Overlap
Accessibility needs split into visual, motor, cognitive and audio. The split is useful for coverage but misleading if you treat the categories as separate audiences. A single player often has needs in more than one, and the features that pay off best are the ones serving several at once.
Subtitles are the clearest example. They are an audio accommodation, but they also reduce cognitive load by giving players a second channel for dialogue they only half caught, and they help anyone playing muted in a shared space. Toggle instead of hold is a motor accommodation that also removes a cognitive burden during a busy fight. When a feature appears in two categories, it belongs near the top of the list.
What The Browser Gives You For Free
Web games start ahead of native builds here, and most teams never collect the advantage. The browser already ships an accessibility tree that screen readers understand, an operating system level zoom that works without your code doing anything, a reduced-motion preference exposed to CSS, and a font size setting the page can respect. A native team builds equivalents from scratch.
The catch is that a canvas is opaque to all of it. The moment you render the entire interface into a single canvas element, every one of those free affordances is gone. Keeping menus, HUD text and settings as real DOM elements layered over the canvas is the highest leverage architectural decision in web game accessibility, and it costs almost nothing if you make it early. The longer breakdown of the four categories and the standards behind them goes through the ARIA patterns that make this work.
A Build Order That Survives A Deadline
Prioritize by audience size against implementation cost and build in this order: full key and gamepad remapping, subtitles on by default with speaker labels, toggle options for sustained actions, colorblind-safe palettes where state is never encoded in hue alone, respect for the reduced-motion preference, then screen reader and ARIA work for the interface layer.
Test the cheap way first. Convert the palette to grayscale and see which elements collapse into each other. Play a level using only the keyboard. Turn the sound off and check whether the game is still legible. Each of those takes minutes and finds problems no checklist would have surfaced.
None of this needs a dedicated accessibility sprint or a specialist hire. It needs the list sorted by who it reaches and what it costs, the top of that list actually built, and the decision about canvas versus DOM made before it gets expensive to revisit. The teams who find accessibility cheap are not spending more than the teams who find it expensive. They are spending in a different order.
