Ist eine WebGL-Website überhaupt barrierefrei möglich?

Ja. Nicht die Grafik wird zugänglich, sondern eine parallele HTML-Ebene daneben, plus abschaltbare Bewegung und ein Fallback. Die Show bleibt im Canvas, die Substanz liegt im DOM.

Muss meine 3D-Website das BFSG erfüllen?

Wenn du als Unternehmen Verbrauchern etwas anbietest, etwa einen Shop, eine Buchung oder viele digitale Dienstleistungen, sehr wahrscheinlich ja, seit dem 28. Juni 2025.

Reicht ein Alt-Text für den Canvas?

Nein. Ein statischer Alt-Text beschreibt ein Bild. Ein interaktives 3D-Erlebnis braucht bedienbare Gegenstücke, keine Bildunterschrift.

Was ist der häufigste Fehler?

Wichtige Information nur in die Szene zu legen, ohne zweiten Weg. Und eine Auto-Rotation, die sich nicht abschalten lässt.

WebGL und Barrierefreiheit: Wie 3D-Websites BFSG-konform werden

3D im Browser verkauft. Ein Konfigurator, der sich drehen lässt, ein Produkt von allen Seiten, eine Szene, die auf das Scrollen reagiert: Das bleibt hängen. Für einen Screenreader bleibt davon nichts.

Er liest deine Website und findet an der Stelle deines aufwendigen WebGL-Erlebnisses genau eine Information: canvas. Kein Text, keine Struktur, keine Bedienung. Ein schwarzes Loch mitten auf der Seite.

Der übliche Reflex ist dann, 3D wegzulassen. Das ist der Fehler. Du musst dich nicht zwischen Erlebnis und Zugänglichkeit entscheiden. Du musst beides bauen, nebeneinander.

Warum der Canvas eine Blackbox ist

WebGL zeichnet Pixel auf eine Fläche. Es erzeugt keine Semantik: keine Überschriften, keine Buttons, keinen fokussierbaren Text. Assistive Technologie arbeitet aber genau damit. Sie liest den DOM-Baum, nicht das Bild.

Wo ein Screenreader bei einem echten Button “Button, Angebot anfordern” vorliest, findet er beim Canvas nichts, das er ansagen könnte. Die Tastatur läuft ins Leere, weil im Canvas nichts fokussierbar ist. Und Text, den du in die 3D-Szene rendern lässt, ist kein Text mehr, sondern Farbe. Das Problem ist nicht, dass WebGL schlecht wäre. Es liefert schlicht keine der Informationen, die Barrierefreiheit braucht.

Das Prinzip: eine zweite, unsichtbare Ebene

Die Lösung dreht das Problem um. Statt die Grafik zugänglich zu machen, baust du parallel zur 3D-Szene eine echte HTML-Struktur auf, die dieselben Aktionen anbietet. Jedes interaktive Objekt bekommt ein echtes Gegenstück im DOM: einen <button>, einen <a>, ein fokussierbares Element mit aria-label. Screenreader und Tastatur bedienen diese Ebene, deine Three.js-Logik reagiert darauf.

<!-- Sichtbar: die 3D-Szene -->
<canvas id="scene" aria-hidden="true"></canvas>

<!-- Parallel: die barrierefreie Steuerung -->
<div class="scene-controls">
  <button aria-label="Modell nach links drehen"    data-action="rotate-left"></button>
  <button aria-label="Farbe auf Anthrazit wechseln" data-action="color-anthracite"></button>
</div>

<!-- Ansage von Zustandsaenderungen -->
<p class="visually-hidden" aria-live="polite" id="scene-status"></p>

button.addEventListener('click', () => {
  rotateModel(-45);
  document.getElementById('scene-status').textContent =
    'Modell 45 Grad nach links gedreht.';
});

Der Canvas bekommt aria-hidden="true", damit der Screenreader nicht über eine leere Fläche stolpert. Die Bedienung liegt in echten Elementen, die visuell an der richtigen Stelle sitzen dürfen, aber semantisch vollwertig sind. Über eine aria-live-Region sagst du an, was in der Szene passiert. Wer sieht, dreht das Modell mit der Maus. Wer nicht sieht, drückt einen Button und hört das Ergebnis. Gleiche Funktion, zwei Wege.

Bewegung ist der größte Hebel, und der einfachste

Bevor du über Screenreader nachdenkst, kümmere dich um Bewegung. Auto-Rotation, Kamerafahrten, Parallax: Für manche Menschen sind das keine netten Details, sondern Auslöser für Schwindel, Übelkeit oder im Extremfall Anfälle. Die Lösung ist eine Einstellung, die Betriebssysteme längst liefern, du musst sie nur respektieren.

const ruhig = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
if (!ruhig) starteAutoRotation();   // sonst bleibt die Szene statisch

Wer “Bewegung reduzieren” im System aktiviert hat, bekommt eine ruhige Szene statt einer Endlosdrehung. In react-three-fiber nimmt dir A11yUserPreferences aus react-three-a11y genau diese Abfrage ab. Das ist der Punkt mit dem besten Verhältnis von Aufwand zu Wirkung: wenige Zeilen, deckt WCAG 2.3.3 und 2.2.2 ab, hilft spürbar.

Tastatur, und ein Fokus, den man sieht

Ist die Szene bedienbar, muss sie es per Tastatur sein. Jedes Gegenstück aus der parallelen Ebene gehört in die Tab-Reihenfolge, auslösbar mit Enter und Leertaste. Und der Fokus muss sichtbar sein, nicht nur im DOM, sondern in der Szene: Springt jemand mit Tab auf “Bauteil A”, hebe Bauteil A auch im 3D-Modell hervor, mit einer Outline oder einem Highlight. So bleiben die visuelle und die semantische Ebene synchron. Ein Fokus, den nur der Browser kennt, aber niemand sieht, hilft keinem.

Die Tools, ehrlich eingeordnet

Drei Wege, und keiner ist ein Selbstläufer:

react-three-a11y (pmndrs) für react-three-fiber: liefert den <A11y>-Wrapper, Rollen wie Button, ToggleButton oder Link, Fokus-Management und den A11yAnnouncer für Ansagen. Es baut die parallele Ebene weitgehend für dich. Der Haken: das letzte Release ist von 2022. Es funktioniert, aber du betrittst kein aktiv gepflegtes Fundament.
Babylon.js bringt mit seinem Accessibility-Paket einen HTML-Twin: Babylon erzeugt automatisch einen parallelen DOM-Baum aus Szene und GUI, inklusive ARIA. Wer ohnehin Babylon nutzt, hat den kürzesten Weg.
Reines Three.js hat nichts eingebaut. Hier baust du die parallele Ebene selbst, so wie oben. Mehr Arbeit, volle Kontrolle.

Kein Tool macht deine Szene per Knopfdruck konform. Sie nehmen dir Mechanik ab. Die Konzeptarbeit, also welche Information über welchen Weg zugänglich sein muss, bleibt bei dir.

Was das BFSG konkret verlangt

Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz. Es setzt den European Accessibility Act in deutsches Recht um und betrifft viele Anbieter im B2C, vom Online-Shop bis zur buchbaren Dienstleistung. Der technische Maßstab ist die EN 301 549, die im Kern auf WCAG 2.1 Stufe AA verweist. Für eine 3D-Website heißt das:

Jede Information und jede Aktion, die es nur in der 3D-Szene gibt, ist auch ohne die Szene erreichbar.
Alles ist per Tastatur bedienbar, der Fokus ist sichtbar.
Bewegung lässt sich anhalten und respektiert prefers-reduced-motion.
Text im Canvas hat eine echte Textentsprechung.
Kontraste erfüllen die AA-Schwellen, auch bei Bedienelementen.
Es gibt eine gleichwertige Alternative, wo ein Teil nicht vollständig zugänglich zu machen ist.

Der Fallback ist keine Niederlage

Manche 3D-Erlebnisse bekommst du nicht zu hundert Prozent barrierefrei, ohne sie zu zerstören. Das ist kein Grund, es zu lassen, und keiner, es zu verstecken. Der saubere Weg ist eine gleichwertige, nicht-visuelle Alternative: eine Textbeschreibung, eine 2D-Ansicht, eine klassische Auswahlliste mit denselben Optionen wie der Konfigurator. Barrierefreiheit verlangt nicht, dass jeder denselben Weg geht. Sie verlangt, dass jeder ans Ziel kommt.

Ich baue 3D-Weberlebnisse, die beeindrucken und trotzdem für alle funktionieren. Das ist kein Widerspruch, sondern eine Frage der Architektur: die Show im Canvas, die Substanz im DOM. Wer beides von Anfang an zusammendenkt, muss später nichts nachrüsten und steht auch vor dem BFSG ruhig da.