Accessibility Options Toolkit and Automated Audit for Unity Games

The problem: small studios skip accessibility because it is a lot of plumbing

Many players need accessibility options to play at all: subtitles for deaf and hard of hearing players, remapping and hold-to-toggle for players with limited mobility, colour-blind modes, larger text, reduced flashing and camera shake. Large studios now ship long accessibility menus and have dedicated specialists. Indie and small studios, including the many mobile and PC studios in Pakistan and elsewhere, usually do not. Each option is not hard on its own, but together they are weeks of plumbing, and nobody on a small team knows which guidelines apply or how to check them.

The result is games that exclude players for reasons that could have been fixed cheaply, often discovered only after launch in reviews.

What already exists and the gap

• Game Accessibility Guidelines is a widely cited free reference listing basic, intermediate and advanced recommendations for developers.
• Xbox Accessibility Guidelines from Microsoft give detailed, testable guidance for games on its platforms.
• Unreal Engine includes some built-in support such as colour vision deficiency correction; Unity has added accessibility APIs for mobile screen readers in recent versions.
• Can I Play That? reviews games from the perspective of disabled players, showing what players expect.

The guidance is good; the implementation and checking are left to each team. The gap is an open source Unity package that provides the common options ready to use and an audit that checks a project against the guidelines automatically, the same way web developers use axe-core to check pages.

What you build

Developers import the package, drop the accessibility menu prefab into their settings screen, tag subtitle audio and UI text, and bind actions through the Input System. Players get a consistent menu with subtitles, remapping, colour filters, text scaling and motion options that persist across sessions. The audit runs in the editor or in CI and produces a report: which texts are too small or low contrast, which actions cannot be remapped, which scenes flash too fast, and which guideline each finding relates to.

The technically interesting part

Automated checking of a game is harder than checking a web page. Contrast must be measured between rendered text and whatever is actually behind it, which may be a moving 3D scene, so you need to render and sample, not just read colours from components. Flash detection means analysing frame luminance changes over time during play and comparing against a threshold based on published photosensitivity guidance. Colour-blind filters must be implemented as post-processing shaders that do not break the game's own effects. Deciding what can be checked automatically and what must stay a manual checklist is a design decision you should explain clearly.

Show evaluators the audit catching planted problems in a sample game, then the fixed version passing.

How to evaluate it

• Audit accuracy: plant at least 30 known issues across the sample games and report detection rate and false positives.
• Integration effort: time for 5 developers to add the menu and run an audit on their own project, with a short questionnaire.
• Player experience: at least 6 players who rely on accessibility settings try a sample game before and after; record task completion and their comments.
• Performance: frame time cost of colour filters and subtitle rendering on a mid-range PC and phone.

Suggested plan

1. Weeks 1 to 4: study the Game Accessibility Guidelines and Xbox guidelines, pick the options and checks in scope.
2. Weeks 5 to 9: settings menu, persistence, subtitles and text scaling.
3. Weeks 10 to 14: input remapping with conflict detection and presets; colour filter shaders.
4. Semester 2, weeks 1 to 5: editor audit for text size, contrast and remappability.
5. Weeks 6 to 9: runtime flash detection, reports and CI integration.
6. Weeks 10 to 14: sample game retrofits, player and developer studies, release on GitHub and the Unity Asset Store.

Path to a product

Release a free open source core to build trust, then sell a Pro version on the Unity Asset Store with advanced checks, CI reports and support. The first customers are indie studios preparing for console certification or a Steam launch. A second revenue stream is paid accessibility audits for studios, using your tool plus a manual review, with testers who use accessibility settings themselves paid for their time.

Scope warning

Do not try to build a screen reader, sign language avatars or audio description. Do not claim the audit certifies a game as accessible; it catches common problems. A reliable options menu, working remapping and an audit with honest accuracy numbers are the project.

Learn what you need on Sefism

• Unity Manual and Scripting API : the Input System, UI and editor scripting you will use throughout.
• How to Meet WCAG 2.2 (Quick Reference) : contrast and flashing thresholds that many game guidelines borrow.
• axe-core : a model for how an automated accessibility checker reports findings.
• Game Programming Patterns : the command pattern behind remappable input.
• Open source roadmap : releasing and maintaining a package other developers depend on.

Get help with this idea

Accessibility work is judged by the people who need it, so recruit players early and let their feedback shape your priorities. Bring your proposal and we can agree the scope, pick a stack your team can finish with, and design an evaluation your panel will respect. You build it; we help you make the calls.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session

New here? Create a free account first.