A tester sits down with your build on a 55-inch TV, three metres back. Thirty seconds in, they lean forward, squint, and say: "What did she just say?" Your subtitles are 18 pixels tall, white, over a snowfield. You spent four months on that cutscene and they just missed the inciting incident.
That is an accessibility bug and a quality bug at once. Most accessibility work is cheap if you do it early and brutally expensive if you retrofit it: remappable controls are a day of work when your input layer is two weeks old and a three-week refactor once it ships. Subtitle sizing is a font constant if your UI scales and a full layout pass if it does not.
So the goal is not a checklist you tick before launch. It is a ladder — an ordered list where each rung is cheap given that you climbed the one below it, and where you know in advance which rung you are stopping at.
Why a ladder and not a checklist
Checklists fail small teams for two reasons. They are undifferentiated — "supports screen readers" sits next to "has a subtitle toggle" as if those cost the same — and they arrive at the end, when every answer is "not now."
A ladder front-loads the architectural decisions. Three questions decide most of your accessibility ceiling, and all three are answered in your first prototype:
- Does every player action go through a rebindable action name, or do you read
KEY_SPACEin your jump code? - Does your UI lay out from a scalable base unit, or are positions hardcoded in pixels?
- Is any critical information conveyed by colour, audio, or timing alone?
Get those three right and the rest of the ladder is mostly settings-menu work. Get them wrong and tier 2 becomes a rewrite.
Tier 1: before your vertical slice
These are the rungs that cost almost nothing now and a lot later. Treat them as part of "done" for your input and UI systems, not as features.
| Feature | Where it lives | Rough cost if done now |
|---|---|---|
| Named input actions, fully rebindable (incl. mouse and both sticks) | input layer | 1–2 days |
| UI scales from one base unit; nothing positioned in raw pixels | UI framework | design decision, ~0 |
| Subtitles on by default, with speaker names | dialogue + UI | 1 day |
| Text floor of roughly 2.5–3% of screen height (≈27–32 px at 1080p) as your smallest readable size | UI style rules | ~0 |
| Text contrast target of 4.5:1 against its background, enforced with a backplate when the background is dynamic | UI style rules | half a day |
| No information carried by colour alone — pair every colour with a shape, icon, or label | mechanics + UI | ~0 if decided early |
| Hold actions have a toggle alternative (sprint, aim, crouch, interact) | input layer | half a day |
| Pause works everywhere, including cutscenes and dialogue | game state | 1 day |
The contrast number comes from web accessibility practice (WCAG's 4.5:1 for body text) and transfers cleanly to game UI. The screen-height percentage is a starting point, not a law — the real test is reading your own subtitles from a sofa.
The "no colour alone" rule saves you the most. If your enemy tells are a red flash versus a blue flash, some players cannot read that mechanic at all, and the fix after animation lock is a new VFX pass. Give the red attack a horizontal streak and the blue one a vertical one and you have a better mechanic — clearer for everyone, on a small screen or in a streamed video.
Tier 2: during production
These need real work but no architecture changes, assuming tier 1 holds.
- Screen shake, camera sway and flash intensity sliders, 0–100%, defaulting to 100. One multiplier threaded through your effects code. This also buys you motion-sickness mitigation, which is a much larger audience than the name suggests.
- A no-QTE path. Any input that must be mashed or hit in a narrow window gets an alternative: hold instead of mash, or a widened window. Write that into the mechanic spec, not into a late special case.
- Subtitle customisation: size (three steps), background opacity (off / 50% / solid), and speaker name toggle.
- Difficulty that is not one multiplier. Separate knobs — enemy damage, enemy health, timing windows, puzzle hints — so a player who wants a reading challenge but not a reaction challenge can have it.
- Audio separation: music, SFX, voice and UI on independent sliders, plus a mono-audio toggle for players using one ear or one speaker.
- Visual substitutes for audio cues. If a boss telegraphs with a sound, add a visible tell. Audit this by muting your game and trying to survive.
- Interaction prompts that do not depend on reaction speed, e.g. an interact radius you can stand in rather than a passing window.
Tier 3: scope-dependent
Honest answer: most two-to-five-person teams stop here, and that is fine as long as you decide it deliberately and say so on your store page.
- Full screen-reader support for menus, or a narrated UI for the main loop
- Aim assist with configurable strength and snap behaviour
- Single-stick or single-hand control layouts
- Text-to-speech / speech-to-text in multiplayer chat
- Switch-device and eye-tracking compatibility
Two public resources worth reading before you write your own tiers: the Game Accessibility Guidelines (community-maintained, split into basic / intermediate / advanced, which maps almost directly onto this ladder) and the Xbox Accessibility Guidelines (more formal, with testable criteria — useful even if you never ship on Xbox).
Where this lives in your documentation
The failure mode is a Google Doc called "accessibility.md" that nobody opens after month two. Accessibility specs only survive when they live next to the thing they constrain:
- Rebinding rules and hold/toggle alternatives belong in your control scheme doc, in the same table as the default bindings — one column for "hold alternative", one for "rebindable: yes/no".
- Text size, contrast and backplate rules belong in your UI/HUD spec as style constants, with the actual numbers, so an artist can check their mockup without asking.
- "No colour alone" and "no audio-only tell" belong in the mechanic entries for the systems they affect, as acceptance criteria.
- Each tier-2 item is a task board card with a real estimate, scheduled into a specific sprint — not a wishlist bullet.
- The tier you are committing to belongs in your milestone definition, so "beta" means something testable.
If you keep your docs in GameDesignerX, that is the natural shape: control scheme, HUD spec and mechanics entries carry the rules, the task board carries the work, the milestone carries the commitment. The tool matters less than the principle — never keep accessibility in a separate document from the design it constrains.
Testing it without a budget
You probably cannot hire a specialist consultant. You can run all of these yourself in about ninety minutes:
- Keyboard-only run. Unplug the controller. Can you reach every menu, skip every cutscene, finish a level?
- Controller-only run. Same, with no mouse. Catch menus that need a cursor.
- Mute run. Play fifteen minutes with sound off. Write down every moment you were confused.
- Greyscale run. Apply a greyscale filter (OS-level or a post-process toggle) and check that no mechanic became unreadable.
- Sofa test. Run at 1080p on a TV, three metres back. Read the subtitles and the smallest HUD number aloud.
- One-hand test. Play with your non-dominant hand only. Note which actions are impossible.
- Rebind test. Remap every action to something absurd and verify no prompt still says "press SPACE".
Each takes one person and no equipment, and produces bug reports rather than good intentions. Run them at every milestone and log the results in your issue log with an "a11y" tag, so the pattern is visible when you plan the next sprint.
The one-sentence version
Decide your ceiling early, build tier 1 into your input and UI systems before the vertical slice, schedule tier 2 as real sprint work, and write the numbers — 4.5:1, 27 px, three subtitle sizes, four difficulty knobs — into the same documents your team already reads. Everything after that is a settings menu.