Captions in a virtual reality app should have a cap height of at least 0.7 degrees. A line should run roughly 36 characters before it wraps. Contrast against the background should be at least 4.5 to 1. And if the person speaking is out of view, the caption should tell the reader which direction the sound came from.
Those four lines are not advocacy. They are success criteria, copied out of the XR Accessibility Guidelines v1.0 that the Metaverse Standards Forum Accessibility Working Group released in early July 2026 and left open for anyone to read. Until this summer, a studio could call its virtual world accessible and a client had no cheap way to check. That is what changed. Accessible is about to stop being an adjective in a pitch deck and start being a list you can fail.
The draft took four quarters longer than promised, and the reason is on the record
In its quarterly report covering April to June 2025, the working group wrote that it “aims to create a working draft of XR accessibility criteria and examples in the next quarter.” The same report logged 6 general meetings, 9 new members and a roster of 60. The draft did not arrive the next quarter. It arrived a year later.
Why it was slow is documented in the group’s own research. Good Intentions, Real Barriers, published on July 30, 2025 by Mrunmai Abhyankar of the University of Texas at Austin, reports 19 interviews with 21 participants: 10 XR creators and 11 accessibility specialists. Two of its findings explain most of the delay. The first is scheduling. One creator told the study that this work “gets deprioritized because, you know, we can barely make the thing as is, let alone add the accessibility, hitting the deadline.” The second is that the guidance everyone points to was written for something else. “WCAG is just so obtuse to try to read, you have to really understand accessibility to even interpret it,” one specialist said in the same study.
The W3C had already mapped the underlying user needs in its XR Accessibility User Requirements, a Group Note from the Accessible Platform Architectures Working Group published in August 2021, and the new guidelines name it as one of their inputs. But a note describing what disabled users need is a different artifact from a checklist a producer can run on a Thursday afternoon. The second one is what did not exist.
What is actually in it
The criteria are grouped into General (system and interface, menus, notifications, avatars), Understanding (text, audio, captions, audio descriptions, sign language, cognitive accessibility), Navigation, Interaction (physical limitations, input methods, target size, timing and difficulty) and Comfort and Safety. Most of them read like the caption rules above: short, specific, technology neutral, and phrased so that two different reviewers should land on the same verdict.
A sample from Comfort and Safety gives the flavor. The application “offers an option to turn off head-bob and other differences between controller movement and camera movement.” It “offers low-motion sickness alternatives such as teleportation.” Where there are flashing lights or similar stimuli, it warns the user ahead of time. None of those are research projects. They are settings, and a build either has them or does not.
The caveat that matters is printed by the authors themselves
Anyone about to write “conforms to the MSF XR accessibility guidelines” into a proposal should read the front matter first, because the chairs list their own known problems there. On testability: “We’d like for all our criteria to be consistently testable such that different reviewers would give the same result, but currently some criteria depend on the reviewer’s judgment.” On feasibility: some criteria, including several around sign language and blind access, “are only theoretically possible and have never been implemented in action.” Those carry a star.
The document also runs two conformance levels, Requirement and Best Practice. Requirements are the ones the group considers testable, feasible, and blocking for users when they are missing. That split is the whole practical story, and it is the part a press release would flatten. The Requirement sections are an audit a team can run against a shipped build this month. The starred criteria are a research agenda nobody has finished, and treating them as a pass or fail gate would measure your team against something no one has built yet.
A first pass that costs a day and no consultant
Open the archival v1.0 document and read two sections against your current build: Comfort and Safety, then Captions. Both are short, and most items resolve to yes or no while the headset is on. One sitting produces a real defect list instead of a feeling.
Cross-check the misses against the free Game Accessibility Guidelines, a collaboration between studios, specialists and academics that has been running since 2012 and sorts its advice into basic, intermediate and advanced tiers. The basic tier is the cheapest accessibility work in the industry and it overlaps heavily with the MSF requirements. If you want the raw material those requirements were assembled from, the XR Accessibility Guidelines Collection compiled by co-chair James Maki sits in public on GitHub and maps across the Game Accessibility Guidelines, Meta’s accessibility VRCs, the Xbox guidelines and WCAG.
Then send the misses back. The first formal review period closed on Friday, July 31, 2026, but the live working document still takes comments, and the chairs also list a feedback form and the address accessibility-chair@lists.metaverse-standards.org.
Our read, and it is a read
Falling behind on accessibility is usually sold as a compliance scare. That is the wrong reason to act, and the guidelines make the better argument themselves if you look at what the cheap requirements actually are: a toggle for head-bob, a caption contrast ratio, a warning before a flashing sequence, a startup menu that does not bury settings three levels down. Those are design decisions, not procurement. A two-person studio can close most of them in a sprint, which means the distance between an accessible XR product and an inaccessible one is mostly attention rather than budget.
One criterion is worth reading twice, because it is a standards body writing a limit on automation directly into a success criterion. The application “provides captions that are reviewed for accuracy, especially those generated by AI.” Machine captioning is now good enough that a studio can switch it on and forget it, and the people the captions exist for are the ones who find out it drifted. The guidelines say a person checks the output. That is the right instinct, and it is the same one that should govern the rest of this work: the tooling gives a small team reach it did not have, and a human still signs the result.
The commercial backdrop is not kind to any of it. Meta has been moving Horizon Worlds off the headset and toward phones, and the sector as a whole got delayed by AI while attention and capital went somewhere else. That is exactly the moment a small studio can get ahead cheaply. The buyers still commissioning immersive work in 2026 are museums, universities and training departments, and those are the buyers most likely to write an accessibility clause into a contract.
The guidelines are still a working document and their authors say so plainly. Which leaves one question worth asking inside your own team before a client asks it: if someone opened that list next to your build, which line would you rather they skipped?
Frequently Asked Questions
Are the MSF XR Accessibility Guidelines a legal standard?
No. They are guidelines from an industry working group, released as v1.0 in early July 2026 and still described by their own authors as a working document. They carry two conformance levels, Requirement and Best Practice, and some criteria are marked as experimental because they have never been implemented in a shipped product.
Where do I read them, and do I need a membership?
The archived v1.0 copy and the live working document are both public documents linked from the working group’s page at the Metaverse Standards Forum. Reading them and leaving comments needs no membership. Joining the group formally does.
What is the fastest useful check for a small team?
Read the Comfort and Safety and Captions sections against your build in one sitting. Items such as an option to turn off head-bob, a low-motion-sickness alternative like teleportation, a warning before flashing stimuli, and caption contrast of at least 4.5 to 1 all resolve to yes or no with the headset on.
How is this different from WCAG?
WCAG was written for web content, and the working group’s own interview research found practitioners consider it too web-centric for immersive work, with one specialist saying “WCAG is just so obtuse to try to read.” The MSF criteria are purpose-built for XR and cover ground web guidance never had to, including motion sickness, body position, hand tracking and spatial audio.
