Alle achtzehn Monate verspricht ein Pressezyklus für Mixed-Reality-Hardware eine inklusive Zukunft. Der Marktstart des Apple Vision Pro 2024 versprach sie. Auch der Marktstart von Meta Quest 3 und dem günstigeren Quest 3S versprach sie erneut. Die WebXR-Spezifikation — der W3C-Standard für AR und VR, das im Browser gerendert wird — macht dieses Versprechen seit 2018. Die Realität Mitte 2026 ist ernüchternder: Es gibt genau ein Consumer-Headset auf dem Markt mit einer ernsthaften, nativen Barrierefreiheitsoberfläche, und die plattformneutrale Browserschicht darunter ist nach wie vor ein strukturelles Vakuum, in dem Alternativtexte, Fokusmanagement und Semantik für assistive Technologien eigentlich leben sollten. Dieser Beitrag gibt einen Überblick darüber, wo die Technologie heute tatsächlich steht — was funktioniert, was Makulatur ist, und was Entwicklerinnen und Entwickler 2026 ausliefern sollten und was nicht.
Die Perspektive ist analytisch, nicht evangelistisch. Es wird nicht argumentiert, dass XR von Natur aus mehr oder weniger barrierefrei ist als das zweidimensionale Web. Vielmehr wird festgestellt, dass die Entwickler-Story für XR-Barrierefreiheit 2026 ungefähr so aussieht wie die Entwickler-Story für Web-Barrierefreiheit im Jahr 2002: ein aufkommender Standard, dem die meisten konkreten Formulierungen noch fehlen, zwei dominante Plattformen, die sich unterschiedlich schnell entwickeln, und eine kleine Gruppe von Menschen mit Behinderungen, die den Großteil des praktischen Wissens in ihrer eigenen Erfahrung tragen.
Die Hardware-Landschaft 2026
Drei Geräte dominieren heute das Consumer-Segment des Mixed-Reality-Markts — und sie nehmen drei unterschiedliche Positionen zur Barrierefreiheit ein. Apple Vision Pro mit visionOS 2.4 ist das einzige der drei Geräte mit einer ernsthaften Barrierefreiheitsoberfläche im Betriebssystem selbst — VoiceOver im 3D-Raum, Switch-Steuerung, Anpassung des Hand-Trackings, Eye-Tracking als primäre Eingabe und eine Spatial-Audio-Implementierung, die Menschen mit Behinderungen wiederholt als die nutzbarste in dieser Kategorie beschrieben haben. Meta Quest 3 und der günstigere Quest 3S teilen ein Betriebssystem — Horizon OS — mit einer dünneren Barrierefreiheitsschicht: Hochkontrastmodus, Controller-Remapping, ein Farbkorrekturfilter, Sprachbefehle zur Navigation und ein Screenreader (Mitte 2024 eingeführt), der innerhalb der System-Shell funktioniert, in Drittanbieter-Apps jedoch nicht zuverlässig. Die Sony PlayStation VR2 liefert in ihrer VR-Shell praktisch keine nativen Barrierefreiheitsfunktionen, erbt jedoch die breitere PS5-Barrierefreiheitsschicht bei Flat-Screen-Inhalten.
Die Preise haben sich merklich verschoben. Der ursprüngliche Vision Pro wurde zu ca. 3.499 USD eingeführt; der Quest 3 kostet ca. 499 USD und der Quest 3S ca. 299 USD. Diese Lücke ist für ein Argument zur Barrierefreiheit relevant, denn das Gerät mit der stärksten Disability-Input-Story ist gleichzeitig das Gerät, das sich die überwiegende Mehrheit der Menschen mit Behinderungen ohne einen vom Arbeitgeber finanzierten Weg über angemessene Vorkehrungen nicht leisten kann. Das Bild des Markts Mitte 2026 ist im Klartext: Das barrierefreie Headset ist teuer, und das erschwingliche Headset ist auf Systemebene größtenteils in dem Sinne barrierefrei, dass es die Nutzung nicht aktiv verhindert.
Die Kategorie jenseits dieser drei — passthrough-only-Smartglasses wie Ray-Ban Meta, Display-Brillen der Xreal-Air-Klasse und die verschiedenen Enterprise-Headsets in chirurgischen und industriellen Arbeitsabläufen — steht weitgehend außerhalb der Consumer-XR-Barrierefreiheitsdiskussion. Die meisten dieser Geräte laufen nicht unter einem desktop-artigen Betriebssystem, stellen keine System-Barrierefreiheits-API bereit und werden in einem regulatorischen Umfeld eingesetzt, das sie als tragbares Zubehör und nicht als Computer behandelt.
Die WebXR-Spezifikation — und was sie noch nicht sagt
WebXR ist die W3C-Spezifikation, die einem Browser ermöglicht, einer Website Zugriff auf ein angeschlossenes AR- oder VR-Gerät zu gewähren. Sie stellt ein Session-Objekt, einen Rendering-Kontext (meist überlagert auf WebGL2 oder WebGPU) und ein Input-Source-Modell für Hände, Controller und Blick bereit. Die Browser-Unterstützung ist Mitte 2026 in Chromium-basierten Browsern am stärksten (Chrome, Edge, Brave und eine Reihe mobiler XR-Browser), in Firefox über einen Enterprise-Build partiell vorhanden und in Safari historisch schwach — visionOS Safari unterstützt die Spezifikation, jedoch nur innerhalb immersiver Sessions und mit den von Apples Hand-Tracking-Pipeline bereitgestellten Input-Semantiken. WebKits WebXR-Position hat sich in den letzten zwölf Monaten merklich bewegt, ist aber nach wie vor weniger ausgereift als das Chromium-Pendant.
Die Spezifikation beschreibt, was das Headset leisten kann — Stereo-Frames rendern, Pose-Daten melden, Grip- und Aim-Transformationen bereitstellen, Select-Events von einem Controller oder einer Pinch-Geste empfangen. Zur Barrierefreiheit sagt sie nahezu nichts. Es gibt kein Äquivalent eines Alt-Attributs für ein Objekt im 3D-Raum. Es gibt kein formales Fokusmodell, durch das eine assistive Technologie schrittweise navigieren kann. Es gibt keinen spec-konformen Weg, einen virtuellen Button so zu beschriften, dass ein Screenreader ihn ankündigen kann. Das einzige Element der heutigen WebXR-Spezifikation, das einer Barrierefreiheits-Schnittstelle am nächsten kommt, ist das profiles-Array der Input-Source, das einer Website ermöglicht, zu erkennen, ob die Eingabe eine Hand, ein Controller oder ein Blick-Cursor ist — und dieses Array existiert aus Gründen des Content-Renderings, nicht für assistive Technologien.
Das ist keine Kritik am W3C — es ist eine Bestandsaufnahme, wo die Arbeit getan wurde und wo nicht. Der Entwurf der WebXR Accessibility User Requirements (XAUR) existiert beim W3C, und die Immersive Web Working Group hat die meisten relevanten Lücken anerkannt. XAUR ist jedoch ein Anforderungsdokument, keine normative Spezifikation — und die Lücke zwischen „wir wissen, was die Spezifikation braucht“ und „die Spezifikation schreibt es normativ vor“ ist in der Praxis der Raum, in dem die meisten Menschen mit Behinderungen heute leben.
Apple Vision Pro: Barrierefreiheit im Detail
Der Vision Pro bietet heute die stärkste Barrierefreiheits-Story auf dem Consumer-XR-Markt — und der Abstand zu allen anderen ist nicht subtil. Die primäre Eingabe des Headsets ist Eye-Tracking: Die Nutzerin oder der Nutzer schaut auf ein Ziel, und der Blick-Kegel definiert das fokussierte Element — kombiniert mit einer kleinen Menge Handgesten, die von nach unten gerichteten Kameras erfasst werden. Für Menschen mit Behinderungen hat Apple mehrere Oberflächen hinzugefügt, die das, was innerhalb von visionOS möglich ist, grundlegend verändern.
Eye-Tracking als primäre Eingabe bedeutet, dass Nutzerinnen und Nutzer mit schwerer motorischer Beeinträchtigung der oberen Gliedmaßen das gesamte Betriebssystem ohne Hand- oder Armbewegung steuern können, sofern ihr Blick zuverlässig genug ist, um für die Verweildauer auf einem Ziel zu fixieren. Alternativen zum Hand-Tracking ermöglichen es, einfache Fingertipps, Handgelenksbewegungen oder ausschließlich kopfbasierte Gesten zu verwenden, wenn das standardmäßige Pinch-and-Tap unzuverlässig ist — eine besonders wichtige Oberfläche für Nutzende mit neuromuskulären Erkrankungen, die die feine Fingerkontrolle beeinträchtigen. VoiceOver im 3D-Raum liest das fokussierte Element in immersiven Kontexten vor und nutzt Spatial Audio, um die räumliche Position des Elements relativ zum Kopf der Nutzerin oder des Nutzers anzuzeigen — eine grundlegend andere Erfahrung als ein Flat-Screen-Screenreader, die die kognitive Last des Aufbaus eines mentalen Modells der Szene tatsächlich reduziert, wenn sie funktioniert.
Spatial Audio für Barrierefreiheit geht über VoiceOver hinaus. Audio-Hinweiszeichen für Systemereignisse — Benachrichtigungen, Fokusänderungen, Öffnen von Dialogfeldern — sind im 3D-Raum positioniert, sodass sehbeeinträchtigte oder blinde Nutzerinnen und Nutzer sie lokalisieren können, ohne den Blick zu schweifen. Switch-Steuerung funktioniert in immersiven Sessions, obwohl die Eingabe über dasselbe Apple-Barrierefreiheits-Setup wie auf iPadOS oder macOS verbunden werden muss. Audiodeskription wird in der Apple TV App für immersive Videos bereitgestellt. Und Head-Pointing existiert als kürzlich hinzugefügte Alternative für Nutzerinnen und Nutzer, deren Augen nicht zuverlässig tracken, obwohl es langsamer und ermüdender als die augengesteuerte Standardmethode ist.
Nichts davon ist perfekt. VoiceOver in Drittanbieter-Apps setzt nach wie vor voraus, dass die Entwicklerinnen und Entwickler SwiftUI- oder RealityKit-Komponenten korrekt verdrahten, und der Drittanbieter-App-Katalog ist klein. Die Anpassung des Hand-Trackings erfordert das Durchlaufen mehrerer Einstellungsebenen und ist nicht leicht auffindbar. Die Eye-Tracking-Kalibrierung selbst kann bei Nutzerinnen und Nutzern mit Strabismus, Nystagmus oder post-schlaganfallbedingter Blick-Dysmetrie wiederholt fehlschlagen. Aber verglichen mit jedem anderen Consumer-Headset auf dem Markt 2026 ist die Vision-Pro-Barrierefreiheitsoberfläche die einzige, bei der ein Mensch mit Behinderung vernünftigerweise erwarten kann, das Gerät nutzen zu können.
Meta Quest 3 und 3S: Barrierefreiheit im Detail
Horizon OS hat in den letzten achtzehn Monaten aufgeholt, aber der Abstand zu visionOS ist real. Quest 3 und Quest 3S werden mit einem systemseitigen Screenreader geliefert, der Shell-UI-Elemente — Home, Bibliothek, Store, Einstellungen — ankündigt und in Metas eigenen Apps reasonably zuverlässig funktioniert. Außerhalb der Shell ändert sich das Bild: Die meisten Drittanbieter-VR-Apps rendern ihre UI innerhalb ihrer eigenen Engine (in den meisten Fällen Unity oder Unreal) und speisen keinen Text in den System-Screenreader ein. Eine blinde Person kann den Quest Store öffnen, kann aber das, was sie kauft, in der Regel nicht zuverlässig nutzen.
Sprachbefehle für die Shell-Navigation („Bibliothek öffnen“, „Nach Hause“) und innerhalb einer kleinen Anzahl von Apps existieren. Hochkontrastmodus und ein Farbkorrekturfilter sind auf Systemebene vorhanden. Controller-Remapping funktioniert in der Shell-UI und in der kleinen Gruppe von Apps, die Metas Input-Abstraktionsschicht verwenden, anstatt Controller-Tasten direkt abzulesen. Hand-Tracking existiert als Eingabemodus, und die jüngste Firmware hat das Gesten-Set verbessert, aber das Quest-Hand-Tracking-System wurde als controller-freie Alternative für Nutzerinnen und Nutzer ohne Behinderung konzipiert, nicht als Barrierefreiheits-Eingabe — es gibt kein Dwell-Click, keinen Head-Pointer-Fallback und kein Äquivalent des Vision-Pro-Einfinger-Taps.
Die bedeutendste Lücke für ein Entwicklerpublikum ist das Fehlen einer veröffentlichten Barrierefreiheits-API für Horizon OS. Wer heute eine Unity-basierte Quest-App erstellt, kann die systemweiten Barrierefreiheitseinstellungen nicht auslesen, die App nicht beim System-Screenreader registrieren und dem System keine beschrifteten Fokusziele bereitstellen, die über Apps hinweg erhalten bleiben. Die Quest-Barrierefreiheits-Roadmap, die Meta Anfang 2025 veröffentlicht hat, sieht eine solche API vor — aber Mitte 2026 ist sie noch nicht ausgeliefert.
Die Schnittstelle von ARIA und WebXR — und das gebrochene Versprechen der Spracheingabe
Die ARIA-Spezifikation — die Menge an Attributen, mit der Entwicklerinnen und Entwickler Rollen, Zustände und Eigenschaften an assistive Technologien kommunizieren können — wurde für zweidimensionale Dokumente konzipiert. Rollen wie button, dialog, tab und navigation setzen ein Fokusmodell voraus, das sich entlang des Dokumentenbaums bewegt. WebXR hat im WebGL- oder WebGPU-Sinne keinen Dokumentenbaum — es gibt einen Szenengraphen, der jedoch innerhalb der Anwendung lebt, nicht im Barrierefreiheitsbaum des Browsers. Die Schnittstelle von ARIA und WebXR ist Mitte 2026 weitgehend ein Fehlen: Der Browser kann die Struktur der 3D-Szene nicht sehen, der Screenreader kann sich nicht durch sie navigieren, und die Entwicklerin oder der Entwickler kann virtuelle Objekte nicht deklarativ beschriften, so wie HTML-Buttons beschriftet werden können.
Es gibt partielle Workarounds. Eine WebXR-Website kann eine parallele DOM-basierte Barrierefreiheitsoberfläche rendern — eine versteckte HTML-Struktur, die die interaktiven Elemente der 3D-Szene mit korrekten ARIA-Rollen und -Labels spiegelt und den Fokus aktualisiert, wenn sich die 3D-Auswahl ändert. Dieses Muster funktioniert, ist jedoch aufwändig; es verdoppelt die Entwicklungskosten und tendiert dazu, mit der Weiterentwicklung der 3D-Szene außer Sync zu geraten. Die W3C Immersive Web Working Group hat einen normativen Vorschlag für ein „zugängliches 3D-Element“ diskutiert, der Szenengraphen-Knoten dem Barrierefreiheitsbaum zugänglich machen würde, aber die Diskussion hat das Stadium eines Spezifikationsentwurfs noch nicht erreicht.
Die andere Schnittstelle, die inzwischen existieren sollte und nicht existiert, ist Voice-first-Eingabe. Sprache war jahrelang die rhetorische Antwort auf die Frage: „Wie wird eine Person mit motorischer Behinderung eine 3D-Szene ohne Hände navigieren?“ Die Realität 2026 ist, dass Spracheingabe innerhalb von immersivem XR fehleranfällig ist. Das Mikrofon liegt nah am Mund der Nutzerin oder des Nutzers, befindet sich jedoch in einem Headset, dessen Tonabnahme auf Raumklang-Rendering optimiert ist, nicht auf Spracherfassung. Konfidenzintervalle bei der Sprachbefehlerkennung im Vision Pro und im Quest liegen deutlich unter dem Vergleichswert auf einem Smartphone. Das Versprechen von „Einfach sprechen“ hat sich nicht erfüllt — der assistive-Technologie-Workflow innerhalb von XR ist nach wie vor gestengesteuert und blickgesteuert, mit Sprache als unzuverlässiger Ergänzung statt als primärer Modalität.
Die dritte Schnittstelle, mit dem längsten Nachhall, ist die Frage der Gesten- vs. Stocknavigation. Blinde Menschen navigieren im physischen Raum mit einem weißen Langstock, einem Blindenführhund oder Echolokations-Hinweisen; das räumliche Modell, das sie aufbauen, ist an Hindernisse auf Bodenhöhe und an die Propriozeption des Körpers geknüpft. Die meisten XR-Szenen sind für sitzende oder stehende Nutzende konzipiert, deren Interaktionsziele auf Brusthöhe innerhalb eines raumgroßen Begrenzungsrahmens schweben. Der Mismatch ist nicht ästhetisch — er ist strukturell. Das „Stock“-Modell der Navigation, bei dem die Aufmerksamkeit entlang einer energiearmen Sonde durch die Szene bewegt wird, lässt sich auf keinen Eingabetyp abbilden, den die aktuellen XR-Runtimes unterstützen. Eine WebXR-Website, die einer blinden Person eine Stock-Navigation ermöglichen wollte, müsste diese Oberfläche selbst erfinden — ohne Hilfe vom Browser, der Spezifikation oder dem Betriebssystem.
Was Entwicklerinnen und Entwickler 2026 tun sollten
Wer 2026 XR-Erlebnisse baut und möchte, dass diese von Menschen mit Behinderungen genutzt werden können, bekommt eine ehrliche Antwort: Browserbasiertes WebXR sollte noch nicht als primäres Erlebnis für Menschen mit Behinderungen ausgeliefert werden — allenfalls als ergänzender Inhalt. Native visionOS-Apps sollten eingesetzt werden, wenn das Budget es erlaubt, denn das ist die einzige Plattform, auf der die Barrierefreiheitsoberfläche real ist, die systemseitigen APIs funktionieren und eine Person mit Behinderung die App mit bereits bekannten assistiven Technologien nutzen kann. Native Quest-Apps sollten mit Bedacht eingesetzt werden, in dem Wissen, dass die systemseitige Barrierefreiheitsoberfläche Shell-Interaktionen abfängt, aber keine In-App-Interaktionen — und dass die Entwicklerinnen und Entwickler für den Aufbau des Äquivalents eines Barrierefreiheitsbaums innerhalb der eigenen Engine der App verantwortlich sind.
Für WebXR im Besonderen lautet die verantwortungsvolle Haltung 2026, es als Progressive Enhancement zu behandeln. Das Erlebnis sollte zuerst als flache, barrierefreie HTML-Oberfläche aufgebaut werden, die die relevanten WCAG-2.2-Erfolgskriterien erfüllt. Das immersive XR-Erlebnis wird darauf aufgelegt für Nutzerinnen und Nutzer, die es wünschen und nutzen können — und die flache Oberfläche liefert denselben Inhalt und dieselben Ergebnisse. Eine WebXR-Website ohne flachen Fallback auszuliefern und 2026 zu erwarten, dass ein Mensch mit Behinderung einen alternativen Weg findet, ist nicht verantwortbar — einen solchen gibt es nicht.
Das größere Bild: Die XR-Barrierefreiheits-Story befindet sich an einem ähnlichen Wendepunkt wie die Web-Barrierefreiheits-Story vor zwanzig Jahren — die Standards holen auf, die Plattformen divergieren, und die Lücke zwischen dem, was Menschen mit Behinderungen brauchen, und dem, was die Spezifikation normativ verlangt, ist groß. Die Arbeiten, die in den nächsten zwei Jahren erledigt werden müssen — XAUR soll von einem Anforderungsdokument zu einer normativen Spezifikation werden, der Vorschlag für einen Barrierefreiheitsbaum für 3D soll sich stabilisieren, die Spracheingabe in Headsets soll sich verbessern, und eine Horizon-OS-Barrierefreiheits-API soll tatsächlich ausgeliefert werden — sind identifizierbar. Ob das auf dem Zeitplan geschieht, den die Nutzer-Community braucht, ist eine andere Frage — eine, die diese Publikation weiter verfolgen wird.