TL;DR: XR accessibility means designing an immersive app so that people with different bodies, senses and abilities can actually complete the task inside it: seated users, people with one usable hand, people with low vision or no stereo depth perception, people who are deaf or hard of hearing, and people who cannot tolerate artificial movement. Most of it is cheap when it is decided in the spec and expensive when it is retrofitted. The practical approach is to design each task so there is more than one way to do it, and to test with the people who are most likely to be shut out.
Here is a question worth asking about any XR project before it is built: who in your organization will be unable to use this, and what happens to them?
For a consumer game, the answer is lost players. For an enterprise training program, a clinical tool or a public-facing experience, the answer is worse. Someone gets excluded from a required course, a patient cannot complete an assessment, or a visitor stands at the edge of the room while everyone else takes a turn. Those outcomes carry reputational, operational and sometimes legal weight, and they are almost always the result of design decisions nobody noticed they were making.
Why screen accessibility does not carry over
If your team already builds accessible web and mobile software, that experience helps, but it does not transfer directly. Screen accessibility rests on conventions that do not exist in a headset: a document structure that a screen reader can walk, keyboard focus, text that can be resized by the operating system, and a flat surface at a predictable distance.
XR adds demands that screens never made. The app may expect someone to stand, turn around, reach above their head, crouch, grip with both hands, judge depth, hear where a sound is coming from or tolerate the sensation of moving without walking. Every one of those is an assumption about a body, and every one excludes someone.
The standards landscape reflects this. Web guidance such as WCAG was written for pages and documents, and it only partly maps onto a 3D scene. The W3C has published XR accessibility user requirements, and game accessibility guidelines cover a lot of the same ground from the player side. They are useful checklists, but none of them is a complete compliance target for a headset app the way WCAG is for a website. If your organization has formal accessibility obligations, the honest move is to ask your counsel how they apply to immersive software, and to build to the intent rather than hunt for a certificate.
The five kinds of exclusion that show up most
Reach, posture and mobility
The most common failure is an app that assumes a standing adult with full range of motion. Controls placed high, objects on the floor, interactions that require turning all the way around or a task that takes twenty minutes on your feet all quietly exclude wheelchair users, people with back or joint conditions, people recovering from injury and anyone who simply cannot stand that long.
The fixes are mostly design, not technology:
- Support seated use for every task, not just a seated menu. If a scenario needs someone to look behind them, give them a snap-turn so they can do it from a chair.
- Let people recalibrate their height so the world is not built around the average standing eye line.
- Bring objects to the user. A reach or grab distance setting, or a way to pull a distant object closer, removes most "I cannot reach it" problems.
- Keep frequent controls low and close to the body, which also helps everyone's arms, as we cover in XR interaction design.
Hands and fine motor control
Many XR apps assume two working hands, a steady grip and the ability to hold a trigger down. That excludes people with limb differences, tremors, arthritis or an arm in a sling.
Ask for one-handed completion of every task, remappable controls, toggles in place of hold-to-act, and generous target sizes. Where it fits the context, gaze plus dwell or voice can replace a grab. The same thinking applies to situational limits: the firefighters ERIS XR was built for routinely wear gloves, which changes what a hand can reliably do. Designing for a gloved hand and designing for a hand with limited dexterity turn out to overlap a great deal.
Vision
Low vision, color vision differences and the absence of stereo depth perception are all common, and all of them break XR apps that rely on small text, color coding or depth cues alone.
- Text needs a size setting and enough contrast against whatever sits behind it, which in passthrough mixed reality is the real, unpredictable room.
- Never carry meaning with color alone. A red and green status should also differ in shape, icon or label.
- Do not make depth the only cue. People without stereo vision judge distance from size, shadow and motion. A task that depends purely on binocular depth needs a second cue.
- Glasses matter. Check that the chosen headset takes a spacer or prescription inserts, which is part of choosing an XR headset.
Hearing
Spatial audio is one of XR's strengths, and it is also a barrier if it is the only channel. Instructions spoken by a virtual trainer, an alarm behind the user, or a character's dialogue all need a visual equivalent.
Captions in XR are harder than on video because there is no fixed bottom of the screen. They need to follow the user's view, identify who is speaking and indicate the direction of a sound that is out of sight. If your training uses AI characters, their speech needs captioning as it is generated, not only for scripted lines.
Comfort and cognition
Some people cannot tolerate artificial movement at all. Others are sensitive to flashing, intense effects or sudden loud sounds, and some find a dense, busy scene overwhelming. These are accessibility needs, not preferences, and the failure mode is silent: people opt out without saying why.
Provide teleport and snap-turn options, a way to reduce effects, clear and short instructions, a pause that genuinely pauses, and the ability to leave and resume without losing progress. We cover the movement side in detail in VR motion sickness.
Multiple ways to do the same thing
If there is one principle to hold a partner to, it is redundancy. Every essential task should be completable more than one way: by controller or by hand, standing or seated, by sound or by sight, by grab or by selection from a list.
This is also how to keep the cost down. Retrofitting accessibility means reworking scenes, controls and content that were built around a single assumption. Designing for alternatives from the start mostly means the interaction layer is built with a small number of swappable input and output paths, and each new scene uses them. The cost difference between those two routes is the single biggest reason to raise this at the brief stage, which we recommend in how to write a software project brief.
Redundancy also helps people with no disability at all. Captions help in a loud workshop. A seated mode helps the tired trainee at the end of a shift. One-handed controls help the technician holding a real tool in the other hand. Accessible XR is usually just more robust XR.
When the user did not choose to be there
Accessibility carries more weight when the person in the headset has no choice. Clinical and assessment tools are the clearest example. Nystag runs VR eye-tracking diagnostics on the Vive Focus 3, and the people using tools like that are patients in a clinic, some of whom may feel unwell. Instructions have to be simple, the setup has to accommodate a wide range of people, and the operator needs a clear way to help without taking the headset back.
Mandatory training is similar. If an XR module is a required part of someone's job, a person who cannot use it needs an equivalent path that is not a lesser or stigmatized version. Sometimes that is an accessible mode inside the headset. Sometimes it is a non-immersive version of the same scenario on a screen. Deciding which, before rollout, is part of the operational planning we describe in enterprise XR rollouts, where it belongs alongside device logistics and sign-in.
Public and shared experiences add another layer. In location-based AR such as Planes XR, users are outdoors on their own phones, in varied light and with varied eyesight. In a shared mixed-reality space such as MR Camera, several people with different needs are working together in the same scene, so any accessibility setting has to be personal to each user without breaking the shared view.
How to test it
A checklist catches the obvious gaps. It does not tell you whether a real person can finish the task.
- Test with disabled users, recruited and paid for their time, not only with the internal team. Five real users with relevant needs will find more than a long review of a recording.
- Run the heaviest, longest scenario seated, one-handed, with sound off and with comfort settings on, and see where it breaks.
- Measure completion and time, not enjoyment. An accessible mode that technically exists but takes three times longer is a finding.
- Keep a route for feedback once the app is live, because the people it excludes are the least likely to be in the pilot group.
What it costs
We do not put a percentage on it, because it depends almost entirely on timing. Accessibility decided in the spec is mostly design work and a modest amount of extra engineering in the interaction layer, and it is a small share of an XR build budget. Accessibility added after content production often means reworking scenes that were built around a standing, two-handed, hearing, stereo-sighted user, and that is where it gets expensive. AI tooling now makes some pieces cheaper, such as generated captions and faster iteration on alternative control schemes, but deciding which alternatives each task needs is still a human judgment made with real users.
Questions to ask before you commission an XR build
- Can every essential task be completed seated? Ask to see it, not hear about it.
- Can every task be completed with one hand? Are controls remappable, and are there toggles instead of holds?
- What happens if the user cannot hear? Are there captions for all speech, with speaker and direction?
- What happens if the user cannot see color or depth? Which cues are redundant?
- What comfort settings exist, and which are on by default?
- Who will you test with? Look for a plan that includes disabled users.
- What is the equivalent path for someone who cannot use the headset at all?
A partner who treats these as edge cases is telling you who will be left out of your program.
The bottom line
XR asks more of a human body than any screen does, which means it has more ways to exclude people. Almost all of them come from unexamined assumptions: standing, two hands, full hearing, stereo vision and a strong stomach. Put the alternatives into the spec, build the interaction layer so each task has more than one route, and test with the people most likely to be shut out. The result is an app more of your people can use, and usually a sturdier one for everybody else.
Planning an XR build for a workforce, a clinic or the public, and want it to work for everyone who has to use it? Book a demo and we'll walk through seated, one-handed, captioned and comfort paths for your use case before content production starts. See our XR work: ERIS XR and Planes XR for ARCortex, Nystag clinical VR eye-tracking on the Vive Focus 3, and MR Camera shared mixed reality.