Accessibility Options Are a Design Discipline

The lazy way to think about accessibility options is as a tax paid at the end of development — a settings screen bolted on after the game is finished, to satisfy a checklist nobody in the studio much cares about. The honest way to think about it is the opposite: an accessibility menu is a direct readout of how well the team actually understood its own systems, because you cannot let a player remap, resize, reweight or remove a mechanic you don’t fully understand yourself. A studio that ships deep accessibility options has, necessarily, done the harder design work first. The menu is just where the proof becomes visible.

What “difficulty” was actually hiding

For most of the medium’s history, accessibility and difficulty were the same slider, and that conflation did real damage to both ideas. A single number labelled Easy, Normal or Hard bundled together things that have nothing to do with each other — enemy damage output, reaction-time windows, text legibility, whether subtitles exist at all, whether colour is the only channel carrying information a colourblind player needs. Turning that one dial down to make a game “easier” for a player with, say, a motor impairment that makes fast inputs difficult also strips challenge from players who wanted the harder combat but needed larger subtitles or remappable controls, because the options were never actually separated in the first place. Difficulty is a design choice, not a moral one — and lumping every kind of access need into that one moral-sounding dial was itself the design failure, long before any individual game’s balance was.

The Last of Us Part II separated the dials properly

Naughty Dog’s The Last of Us Part II, released in 2020, is the case that reset expectations for the rest of the industry because it treated accessibility as systems design rather than a favour. The game shipped with more than sixty individually adjustable options, split cleanly by need rather than bundled by difficulty tier: full text-to-speech and audio-cue navigation for blind and low-vision players, including a high-contrast display mode that outlines enemies, allies and interactive objects in solid colour against a desaturated world; full remapping and toggle-instead-of-hold options for players with limited mobility; independent sliders for enemy aggression, puzzle-solving assistance, and traversal assistance that let a player keep the combat’s full lethality while removing a platforming section’s timing pressure, or the reverse. The response from disability advocates and accessibility-focused outlets was, credibly, that the game had done more in one release than the rest of the industry had managed across a decade, and the options were widely praised at the following year’s award ceremonies specifically as a design achievement rather than a corporate-responsibility box ticked.

The discipline the menu actually requires

The reason this is hard, and the reason so few studios manage it fully, is that a genuinely modular accessibility suite requires every system in the game to already be built as separable layers rather than one entangled mass. A combat encounter that lets a player disable enemy flanking without also breaking the encounter’s pacing has to have flanking implemented as a discrete, toggleable behaviour from day one, not stitched together after the fact from code that assumes flanking always happens. A high-contrast mode that outlines interactive objects has to know, at a data level, which objects in the world are interactive and which are set dressing — information a lot of level-design pipelines never bother to formally separate because the human eye usually sorts it out unassisted. Building that separation isn’t accessibility work bolted onto game design. It’s the same rigour that produces a legible, well-tuned combat system in the first place, applied one layer deeper than most teams bother to go.

Celeste proves the same discipline scales down to a tiny team

Matt Makes Games’ Celeste, released in 2018 by a team of a handful of people, is worth naming precisely because it proves this isn’t a resource problem solvable only by a Naughty-Dog-sized budget. Celeste’s Assist Mode lets a player independently adjust game speed, grant extra air dashes, or turn on invincibility for specific rooms, all while keeping the core platforming identical in feel to the version speedrunners were mastering the same month the accessible options shipped. The team was explicit, in public interviews around launch, that the mode existed because the game’s difficulty was genuinely part of its emotional message about self-acceptance, and gatekeeping that message behind a fixed skill floor would have undercut the point of telling it. That’s accessibility reasoned about as narrative and mechanical philosophy, not as compliance, from a studio with a fraction of a AAA budget — proof the constraint was never really about headcount.

Subtitles are the accessibility feature everyone underrates

The plainest example of the discipline hiding in plain sight is the subtitle track, which most players treat as a solved problem and most studios still get wrong in ways that reveal exactly the same underlying issue. A subtitle system that only transcribes dialogue, with no speaker tags, no indication of direction or tone, and no way to distinguish overlapping lines in a crowded scene, is failing deaf and hard-of-hearing players in a way that has nothing to do with resources and everything to do with treating captioning as a transcription task rather than a communication one. The games that get this right — building in colour-coded speaker names, directional indicators showing which off-screen character is talking, bracketed descriptions of significant non-dialogue sound — are doing exactly the same job the rest of this piece describes: separating information that was previously bundled into a single audio channel back out into independently legible layers. A subtitle track built that way isn’t a smaller version of the audio experience. It’s a different, complete channel that happens to run in parallel with it, and building it that way from the start costs a fraction of what retrofitting it does after the audio mix has already shipped assuming everyone can hear it.

The industry’s own testing infrastructure had to catch up

Part of why this took until the past decade to become common practice is that studios simply didn’t have accessibility consultants embedded in production the way they now increasingly do. Organisations like AbleGamers and consultants specialising in disability access have moved, over roughly the past ten years, from being an occasional post-launch patch source to being brought into pre-production on major releases, reviewing systems while they’re still flexible enough to change cheaply. That timing matters enormously for the argument this piece is making: an accessibility feature designed in during pre-production is architecture, requiring no more effort than any other system decision made at that stage. The identical feature bolted on after a game has shipped, retrofitted into code that was never built expecting it, is enormously more expensive and usually shows the seams — a remapping menu that excludes half the game’s inputs because they were hardcoded, a colourblind filter that recolours the UI but not the in-world markers the UI was meant to match. The industry’s growing habit of consulting early is itself evidence for the discipline argument: the studios doing this well aren’t spending more money overall, they’re spending it at the point in the pipeline where the same work is cheap instead of the point where it’s expensive.

Where the industry still treats it as an afterthought

The counter-cases are instructive too. Studios that ship a single “Accessibility” tab containing nothing but a colourblind filter and a subtitle-size slider are, whether they intend to or not, telegraphing that the underlying systems were never built with separable layers in mind — the options available are the options that happened to be easy to expose, not the options players actually needed. That’s not a moral failing so much as an architectural one, and it usually traces back to the same root cause as a lot of late-stage jank: systems built quickly, under deadline pressure, without the modularity that would have made both accessibility and general maintainability easier later. Crunch and the myth of the heroic deadline tends to produce exactly this kind of brittle, entangled codebase, and a thin accessibility menu is one of the more honest symptoms of it, because there was simply never time to build the separable version.

The false economy of “nobody will notice”

The objection worth taking seriously, because it’s the one actually offered internally at studios that skip this work, is that accessibility options are effort spent on a minority of the audience while the majority never touches the settings menu at all. That framing gets the economics backwards twice over. First, plenty of the options built for access needs turn out to be generally useful — a toggle-instead-of-hold option built for players with limited stamina in their hands is also just a better default for anyone playing on a controller with worn analogue sticks, and a high-contrast enemy outline built for low-vision players is frequently adopted by sighted players simply because it makes fast-paced combat easier to read at a glance. Second, and more fundamentally, the same modular systems that make an option available to a player with a specific need are the systems that make the studio’s own QA process faster, because a tester who can isolate one mechanic — enemy aggression, say — without every other system’s behaviour tangled into it can actually find the bug in that mechanic instead of guessing which of six entangled systems produced it. The “nobody will notice” framing assumes the work is pure cost with no return elsewhere in the pipeline, and that assumption is the actual afterthought, not the accessibility menu itself.

The argument this actually wins

The case for treating accessibility as design discipline rather than compliance isn’t only moral, though the moral case is sufficient on its own. It’s that the same modularity a studio needs to expose a deep accessibility suite is the modularity that makes a game easier to patch, easier to balance, and easier to extend with new content later, because every system was already built assuming other people — a designer on a different team, a QA tester, a player with different needs — would need to reach in and adjust one layer without breaking the others. God of War Ragnarok’s audio-cue and navigation assistance systems, built on the same architecture Sony Santa Monica used for its main-quest guidance features, are the clearest recent proof that accessibility work and core usability work are, underneath the settings menu, the same job. A studio that treats the accessibility tab as an afterthought is usually also the studio whose base systems were never built cleanly enough to expose it any other way, and the menu, thin as it is, tells you that before a single hour of the actual game does.