Ein Blog-Hero-Bild mit einem alt-Attribut ist ein gelöstes Problem. Ein STEM-Diagramm ist es nicht. Drei Eigenschaften wissenschaftlicher Abbildungen brechen die Annahmen, die in alt, aria-label und das Sprachmodell des Screenreaders eingebaut sind.

Erstens ist die Informationsdichte hoch genug, dass ein einzelner Satz sie nicht transportieren kann. Ein Benzolring besteht aus sechs Kohlenstoffatomen, sechs Wasserstoffatomen, alternierenden Doppelbindungen, einem delokalisierten Pi-System, einer planaren Geometrie und einer Bindungslänge von 1,39 Ångström. Die Alternativtext-Konvention verlangt „einen kurzen Textersatz“; Benzol braucht einen Absatz. Es auf einen Satz zu komprimieren verliert entweder die Strukturinformation („ein Benzolmolekül“) oder erzeugt einen unlesbaren Bandwurmsatz, den der Screenreader mit 180 Wörtern pro Minute buchstabieren muss.

Zweitens tragen die Beziehungen zwischen Elementen ebenso viel Bedeutung wie die Elemente selbst. In einem Freikörperdiagramm ist der Pfeil vom Kasten zur Wand kein Dekor — er ist die Normalkraft, und sein Winkel relativ zum Gravitationsvektor ist die Antwort auf die Aufgabe. Eine flache Beschreibung kann „der Winkel zwischen diesen beiden Pfeilen beträgt 90 Grad, und deshalb löst sich die Aufgabe“ nicht kodieren, weil eine flache Beschreibung keine Struktur hat. SVG, sorgfältig eingesetzt, hat sie.

Drittens müssen STEM-Studierende das Diagramm navigieren, nicht nur hören. Lernende, die einen Graphen einer kubischen Funktion durcharbeiten, wollen den Alternativtext nicht von Anfang bis Ende hören — sie wollen am lokalen Maximum landen, fragen „was ist hier die Steigung“, dann zum Wendepunkt weitergehen. Das ist ein anderes Interaktionsmodell als das, mit dem Screenreader standardmäßig ausgeliefert werden. Es zu bauen erfordert Tastatur-Handler an einzelnen SVG-Knoten, einen ARIA-beschriebenen Inhaltsbaum und einen Fallback für die assistiven Technologie-Stacks, die nicht mithalten können.

Fast jedes veröffentlichte STEM-Lehrbuch liefert seine Diagramme noch immer als PNG oder JPG aus. Ein Rasterbild ist ein undurchsichtiges Pixelraster: Es hat einen einzigen Einstiegspunkt für assistive Technologie, das alt-Attribut, und einen Fallback, das longdesc-Attribut, das Browser seit zehn Jahren still deprecieren. Im Bild gibt es keine Struktur, die ein Screenreader adressieren könnte. Das Diagramm ist eine Black Box mit einem Label auf der Vorderseite.

SVG invertiert das Modell. Jede Form in einem SVG-Dokument ist ein DOM-Knoten — adressierbar, fokussierbar, beschriftbar. Ein als SVG dargestellter Benzolring hat sechs circle-Elemente für die Kohlenstoffe, sechs line-Elemente für die Bindungen und ein umgebendes g-Element, das das Ganze benennt. Jeder dieser Knoten kann role-, aria-label-, aria-labelledby-, aria-describedby- und tabindex-Attribute tragen. Der Screenreader sieht einen Barrierefreiheitsbaum mit benannten Bereichen statt eines einzelnen undurchsichtigen Blobs.

Das minimal barrierefreie SVG trägt drei Dinge an seinem Wurzel-svg-Element: role=“img”, aria-labelledby zeigend auf ein title-Kindelement und aria-describedby zeigend auf ein desc-Kindelement oder auf einen externen Absatz per ID. Jedes ist klein. Jedes leistet Arbeit, die die anderen beiden nicht können.

Eine wichtige Warnung: role=“img” am Wurzel-svg ändert, was assistive Technologie mit den Kindelementen macht. Mit role=“img” behandeln NVDA und JAWS das gesamte SVG als ein einzelnes beschriftetes Bild und legen die inneren Knoten nicht offen — auch wenn diese inneren Knoten tabindex haben. Um beide Verhaltensweisen zu erhalten — ein zusammenfassendes Label oben und adressierbare Kinder innen — sollte die Wurzelrolle nicht gesetzt (oder role=“graphics-document” aus dem W3C-Graphics-ARIA-Modul gesetzt) und das Label an ein Kind-g-Element statt an die Wurzel gelegt werden. Browser und Screenreader behandeln diese Kombination uneinheitlich. Die Matrix in Abschnitt 6 dokumentiert, was wo funktioniert.

Das longdesc-Attribut war die ursprüngliche Antwort auf „ein alt-Attribut reicht nicht.“ Browser entfernen die Unterstützung seit Jahren still; Firefox hat sie ab Version 90 eingestellt, Safari hat sie nie implementiert, Chrome behandelt sie als No-op. Wer 2026 noch longdesc=“benzene-desc.html” schreibt, liefert Markup aus, das nichts liest. Der Ersatz ist nicht ein einzelnes Attribut, sondern ein Drei-Schichten-Muster, das eine eingebettete Beschreibung, ein sichtbares aufklappbares Panel und maschinenlesbare Metadaten kombiniert.

Schicht eins ist das eingebettete desc-Element innerhalb des SVG. Zwei bis vier Sätze. Von Screenreadern gelesen, wenn der SVG-Wurzelknoten angekündigt wird. Dies ist das neue longdesc — eine Beschreibung, die Teil des SVG-Dokuments ist und mit dem SVG mitreist, wohin es auch geht.

Schicht zwei ist ein sichtbares aufklappbares Beschreibungs-Panel neben dem Diagramm, das allen Lesenden zugänglich ist, nicht nur Screenreader-Nutzenden. Eine Zusammenfassungszeile und eine Aufklapp-Schaltfläche, die eine längere textliche Erläuterung öffnet — üblicherweise drei bis zehn Sätze für ein Chemiemolekül, länger für ein Zellstrukturdiagramm mit zwanzig beschrifteten Organellen. Das sichtbare Panel löst ein Problem, das das eingebettete desc nicht kann: Studierende, die das Diagramm sehen, es aber nicht entschlüsseln können (seheingeschränkte Lernende, Lernende mit Legasthenie, alle, die das Material zum ersten Mal lernen) brauchen die Langbeschreibung ebenfalls. Sie hinter einer Schaltfläche zu platzieren versteckt sie nicht vor Screenreadern — diese zählen die Aufklappfunktion auf, der Nutzende aktiviert sie und die Beschreibung wird in den Puffer gelesen.

Schicht drei sind strukturierte Metadaten via JSON-LD. Ein CreativeWork-Objekt, dessen accessibilityFeature-Array aufzählt, was das Diagramm bietet: longDescription, alternativeText, structuralNavigation, describedMath, tactileGraphic (wenn ein druckbares taktiles Bild verfügbar ist). Suchmaschinen, Content-Empfehlungssysteme und Barrierefreiheits-Konformitätsscanner verarbeiten diese Metadaten alle. Sie tun nichts für die unmittelbare Screenreader-Leseerfahrung, machen das Diagramm aber als barrierefreien Inhalt auffindbar — was wichtig ist, wenn Lernende zwischen drei Lehrbüchern wählen und eines davon seine Barrierefreiheitsfunktionen in maschinenlesbarer Form bewirbt.

Statische Diagramme sind der einfache Fall. Der schwierige Fall ist das animierte Diagramm — ein in 3D rotierendes Mitochondrium, eine Sinuswelle, die entlang der x-Achse aufgezeichnet wird, eine chemische Reaktion, bei der sich Bindungen über vier Sekunden bilden und brechen. Die übliche Antwort ist eine Videodatei mit einem Audiodeskriptions-Track, aber das gibt die Adressierbarkeit von SVG auf: In dem Moment, in dem die Animation in ein Video gebacken wird, hört jeder sorgfältig beschriftete Knoten auf, ein DOM-Knoten zu sein, und wird wieder ein Pixel.

Die barrierefreie Alternative besteht darin, die Animation als SVG (oder Canvas mit einem Offscreen-Barrierefreiheitsbaum) beizubehalten und Audiodeskriptionen auszugeben, während die Animation fortschreitet — gesteuert durch dieselben DOM-Mutationen, die die visuelle Änderung steuern. Das Muster: Ein MutationObserver beobachtet das SVG auf Änderungen — ein neues transform-Attribut, eine erscheinende Bindung, ein rotierender Vektor — und schreibt bei jeder signifikanten Änderung eine kurze Textaktualisierung in eine globale aria-live=“polite”-Region. Die visuelle Animation treibt eine Audiokommentierung an, die aus derselben Quelle der Wahrheit in Echtzeit generiert wird.

Die Implementierung hat drei bewegliche Teile. Der erste ist die Animation selbst, ausgedrückt als Folge von Timeline-Keyframes — dieselben Daten, die der SVG-Renderer verarbeitet. Der zweite ist eine Annotationsschicht: Jeder Keyframe trägt einen kurzen Text, der beschreibt, was sich an diesem Moment ändert („Bindung bildet sich zwischen C1 und C2“, „Welle kreuzt die Nulllinie von unten“). Der dritte ist der Audiodeskriptions-Treiber, der die Timeline abonniert, jeden annotierten Keyframe aufgreift und seinen Text einige hundert Millisekunden vor dem visuellen Ereignis in die Live-Region schreibt. Die Vorlaufzeit entspricht dem, was professionelle Audiodeskription für Film macht: Die Beschreibung wird kurz vor dem visuellen Ereignis gehört, nicht danach.

Drei Fehlermodi sind häufig genug, um sie zu nennen. Erstens: Burst-Aktualisierungen. Eine Animation, die 60 Mutationen pro Sekunde auslöst, überflutet den Synthesizer des Screenreaders — die Ankündigungen stapeln sich, hinken der Animation hinterher und werden unverständlich. Nur die semantisch signifikanten Keyframes annotieren, nicht jeden Frame, und auf ca. eine Ankündigung pro 1.500 ms drosseln. Zweitens: Den Start verpassen. Eine Live-Region, die vor Beginn der Animation nicht existierte, wird ihre erste Aktualisierung nicht zuverlässig ankündigen (vgl. den Grundlagentext zum aria-live-Framework wegen des zugrunde liegenden Scheduler-Problems). Die Live-Region leer beim Laden der Seite einbinden. Drittens: Kein Pause-Steuerelement. Nutzende müssen die Audiodeskription pausieren, verlangsamen oder schrittweise durchgehen können. Eine kleine Steuerleiste bauen — Abspielen, Pausieren, Vorheriges Ereignis, Nächstes Ereignis — und ihre Schaltflächen mit demselben Timeline-Treiber verbinden.

Ein mathematischer Funktionsgraph, den sehende Studierende mit dem Cursor scrubben können, ist nicht barrierefrei, bis nicht-sehende Studierende ihn mit der Tastatur scrubben können. Der Mechanismus ist bekannt und in der Praxis schlecht umgesetzt: Jeder signifikante Datenpunkt auf der Kurve erhält tabindex=“0”, ein aria-label, das seine Koordinaten und ein eventuell benanntes Merkmal beschreibt („lokales Maximum bei x = -1, y = 4“), und einen Tastatur-Handler, der auf Pfeiltasten für die feinkörnige Bewegung zwischen benachbarten Punkten reagiert.

Die richtige Granularität ist wichtiger, als allgemein angenommen. Durch jeden gezeichneten Pixel einer kubischen Kurve zu tabben ist feindlich — der Nutzende hört tausende „x = 0,1, y = 0,001“-Ankündigungen, bevor etwas Interessantes erscheint. Nur durch die benannten Merkmale zu tabben (lokale Maxima, Minima, Wendepunkte, x-Achsenschnittpunkte, y-Achsenschnittpunkte) ist zu spärlich. Der pragmatische Kompromiss: zwei Navigationsebenen. Die Tab-Taste durchläuft nur benannte Merkmale — üblicherweise drei bis sieben auf einer Kurve — und die Pfeiltasten, sobald ein Merkmal fokussiert ist, bewegen sich links und rechts entlang der Kurve in einer lernenden-definierten Schrittweite und kündigen die Koordinate bei jedem Schritt an. Pos1 und Ende springen zur linken und rechten Grenze der Kurve. Bild auf und Bild ab springen zum nächsten benannten Merkmal.

Bei einem Mehrserien-Diagramm — einem Kinetik-Plot in der Chemie, einem Physik-Oszillationsgraphen mit zwei Wellenformen — eine Serienwechsel-Achse hinzufügen. Aufwärts- und Abwärtspfeiltasten wechseln zwischen Serien bei der aktuellen x-Koordinate; Links und Rechts bewegen sich entlang der aktuellen Serie. Die Konvention spiegelt die Navigation in Tabellenleseprogrammen wider und nutzt ein mentales Modell, das viele Nutzende bereits haben.

Ein Detail, das oft übersehen wird: Der fokussierte Datenpunkt braucht einen sichtbaren Fokusindikator. Nicht-sehende Nutzende brauchen ihn nicht, aber sehende Screenreader-Nutzende schon, ebenso wie begleitende Lehrende, die der Studierenden über die Schulter schauen. Mit :focus-visible-Styling einen Fokusring um das fokussierte SVG-Element rendern — dieselbe Konvention wie Schaltflächen-Fokusringe, auf SVG-Knoten angewendet, die der Browser standardmäßig nicht formatiert.

Die härteste Wahrheit in diesem Artikel: Der barrierefreie SVG-Stack verhält sich nicht gleichartig über Browser und Screenreader, und die Lücken sind keine Fehler im Markup. NVDA auf Firefox ist die zuverlässigste Kombination — die einzige, bei der jedes Muster in diesem Artikel so verhält, wie es die W3C-SVG-Barrierefreiheitszuordnung beschreibt. Jede andere Kombination hat mindestens eine bekannte Lücke.

Safari auf macOS mit VoiceOver ist der problematischste der großen Stacks. WebKits SVG-Barrierefreiheitsbaum hat dokumentierte Lücken darin, wie innere g-Elemente mit ARIA-Labels exponiert werden: Die Labels sind im DOM vorhanden und mit dem Barrierefreiheits-Inspektor inspizierbar, aber VoiceOver lädt sie beim Navigieren mit VO-Rechtspfeil nicht immer. Das Verhalten ist inkonsistent — manchmal werden die inneren Labels angekündigt, manchmal wird nur das SVG-Root-Label gelesen, ohne ein clientseitiges Muster. Das WebKit-Bugzilla hat dazu seit 2020 offene Issues. Die pragmatische Implikation: Wenn ein STEM-Diagramm auf dem Mac funktioniert, ist das eine notwendige, keine hinreichende Bedingung. Vor dem Ausliefern auf Windows mit NVDA testen.

Chrome auf Windows mit JAWS ist der zweitzuverlässigste Stack — nahe an NVDA + Firefox, mit einem Vorbehalt: JAWS behandelt SVG role=“img” aggressiver als NVDA und kollabiert innere Knoten häufiger. Die Behebung besteht darin, role=“graphics-document” aus dem W3C-Graphics-ARIA-Modul am Wurzel-svg zu verwenden, was JAWS korrekt behandelt. NVDA behandelt es ebenfalls korrekt. Firefox und Chrome liefern beide die notwendigen Plattform-API-Zuordnungen.

Mobilgeräte sind ein separates Problem. iOS VoiceOver erbt WebKits SVG-Lücken; Android TalkBack auf Chrome behandelt innere Knoten zuverlässig, unterstützt aber noch keine W3C-Graphics-ARIA-Rollen, sodass es auf role=“img”-Verhalten zurückfällt. Für einen Lehrbuch-Verlag, der sowohl Desktop als auch Mobilgeräte adressiert, ist die sichere Wahl, zwei SVG-Modi auszuliefern: einen strukturell navigierbaren Modus für Desktop und einen „Zusammenfassung plus Langbeschreibung“-Modus, der die innere Navigation auf Mobilgeräten deaktiviert. Der Modusschalter wird durch User Agent und Nutzerpräferenz gesteuert, sitzungsübergreifend gespeichert.

Eine Lesart der Matrix: NVDA + Firefox als Basis-Konformitätsziel festlegen, die Safari- und TalkBack-Fallbacks dokumentieren und das Fehlen einer inneren Knotenankündigung auf einem Mac nie als Beweis dafür werten, dass das SVG nicht barrierefrei ist. Das Diagramm kann vollständig barrierefrei sein — die Plattform legt die geschriebenen Labels nur nicht offen. Der Barrierefreiheits-Inspektor im Safari-Entwickler-Menü zeigt, was im Baum ist, auch wenn VoiceOver es nicht vorliest, und ist das richtige Werkzeug, um „fehlerhaftes Markup“ von „fehlerhafte Plattform“ zu unterscheiden.

Die meisten veröffentlichten Leitfäden zur Barrierefreiheit von STEM-Diagrammen enden bei der title-und-desc-Schicht. Das sind die leichten 30 Prozent. Die verbleibenden 70 Prozent — das Langbeschreibungs-Panel, die von DOM-Mutationen getriebene Audiodeskriptions-Timeline, die zweistufige Tastaturnavigation, die plattformspezifischen Fallbacks — ist ebenso sehr Interaktionsdesign wie Markup. Der Screenreader ist ein Nutzender; eine nicht sehende Lernende, die einen Screenreader verwendet, um einen Funktionsgraphen im Tempo einer sehenden Kommilitonin zu navigieren, ist ein anderer Nutzender mit anderen Bedürfnissen.

Die Rendite ist groß und ungleich verteilt. Ein Lehrbuchverlag, der den vollständigen Stack über ca. 600 Diagramme in einem Kalkuluslehrbuch ausliefert, bedient jede nicht sehende Lernende, die dieses Lehrbuch nutzt, jede seheingeschränkte Lernende, die das Aufklapp-Panel zu schätzen weiß, jede legasthene Lernende, die die Langbeschreibung lesen, aber das Bild nicht entschlüsseln kann, jede Lernende mit Deutsch als Zweitsprache, die die strukturierte Beschreibung leichter findet als die visuellen Konventionen des Fachgebiets, und jede sehende Lehrperson, die Audiozusammenfassungen für Podcasts erstellt. Dasselbe Markup bedient fünf verschiedene Zielgruppen. Die Kosten betragen einige Stunden pro Diagramm, amortisiert über Jahrzehnte studentischer Nutzung.

Der aktuelle Stand der Technik ist ungleichmäßig, weil sich die Barrierefreiheitsbaum-Implementierungen zwischen den Betriebssystemen, die Studierende tatsächlich nutzen, unterscheiden. NVDA und JAWS auf Windows haben die meisten SVG-Lücken geschlossen. Safari auf macOS nicht. Bis die Plattformen konvergieren, besteht das Produktionsmuster darin, für das strikteste Ziel zu erstellen — NVDA + Firefox — und die Fallbacks für Plattformen mit bekannten Lücken zu dokumentieren. Das ist mehr Arbeit als das alt-Attribut-Modell früher verlangte. Es ist auch der einzige Weg, ein STEM-Lehrbuch auszuliefern, das die Lesenden, die es unterrichten soll, nicht ausschließt.