Barrierefreie Diagramme und Datenvisualisierungen

Ein Diagramm ist für sehende Nutzer ein hochverdichtetes Bild: Position, Länge, Fläche und Farbe transportieren gleichzeitig Bedeutung. Genau diese Verdichtung ist das Problem, denn sie verlässt sich oft auf einen einzigen Kanal - die Farbe. Ein Liniendiagramm mit fünf farbigen Linien ohne weitere Unterscheidung, eine Ampel-Heatmap aus Rot, Gelb und Grün, ein Kreisdiagramm, dessen Segmente sich nur farblich abheben: All das funktioniert visuell tadellos und fällt für einen erheblichen Teil der Nutzer aus. WCAG 1.4.1 Verwendung von Farbe verlangt deshalb, dass Farbe nicht das einzige visuelle Mittel sein darf, um Information zu vermitteln, eine Aktion anzuzeigen oder ein Element zu unterscheiden (W3C/WAI).

Die Datenlage zeigt, wie verbreitet das Problem ist. Im WebAIM Million Report hatten 2024 rund 81% (WebAIM Million, 2024) aller untersuchten Startseiten Text mit zu geringem Kontrast - der mit Abstand häufigste erkennbare Fehler. Insgesamt wiesen 95,9% (WebAIM Million, 2024) der Startseiten erkennbare WCAG-Verstöße auf, im Schnitt 56,8 (WebAIM Million, 2024) pro Seite. Farbe und Kontrast sind damit kein Randthema, sondern der wunde Punkt schlechthin. In Deutschland betrifft das viele Menschen unmittelbar: Ende 2023 lebten hier rund 7,9 Mio. (Statistisches Bundesamt, 2024) schwerbehinderte Menschen, weltweit haben rund 2,2 Mrd. (WHO, 2023) Menschen eine Sehbeeinträchtigung.

Der wirksamste Hebel ist die doppelte Kodierung: Jede Information, die über Farbe vermittelt wird, wird zusätzlich über einen zweiten Kanal vermittelt. In der Praxis sind das Muster (Punkte, Schraffuren, Raster) auf Flächen, unterschiedliche Linienstile (durchgezogen, gestrichelt, gepunktet) und Marker (Kreis, Quadrat, Dreieck) bei Datenpunkten. Am robustesten ist die direkte Beschriftung am Datenpunkt selbst: Wer den Wert oder die Kategorie direkt an Balken oder Linie schreibt, macht die Legende und damit die Farbzuordnung weitgehend entbehrlich. Diese Muster setzen wir im Rahmen unserer [Leistungen1 systematisch um.

Ein einfacher Praxistest hilft, die Abhängigkeit von Farbe zu erkennen: Wer ein Diagramm in Graustufen umwandelt und es trotzdem noch lesen kann, hat die doppelte Kodierung richtig umgesetzt. Bleiben Segmente oder Linien dann ununterscheidbar, fehlt der zweite Kanal. Dieselbe Logik der nicht ausschließlich farblichen Unterscheidung behandeln wir ausführlich im Beitrag zu [Farbkontrasten in der Barrierefreiheit1.

Ein Diagramm ist Nicht-Text-Inhalt im Sinne von WCAG 1.1.1 und braucht damit eine Textalternative, die denselben Zweck erfüllt (W3C/WAI). Für einfache Diagramme reicht ein kurzer alt-Text, der die Kernaussage benennt - nicht das Aussehen. Bei komplexen Charts wie Infografiken, Verlaufskurven oder Vergleichsmatrizen reicht ein kurzer alt-Text nicht; sie brauchen zusätzlich eine ausführliche Beschreibung, die alle bedeutungstragenden Informationen enthält, soweit sie für den Zweck der Darstellung relevant sind (W3C/WAI). Diese Langbeschreibung steht idealerweise sichtbar auf derselben Seite, sodass alle Nutzer von ihr profitieren.

Wichtig ist die Abgrenzung: Die Kernaussage gehört in den kurzen alt-Text (etwa Säulendiagramm Umsatz je Quartal, Höchstwert im vierten Quartal), die Details in die Langbeschreibung oder in den Tabellen-Fallback. Ein alt-Text, der jeden einzelnen Wert auflistet, überfordert und wird beim Vorlesen unleserlich; ein alt-Text, der nur Diagramm sagt, ist wertlos. Die Verknüpfung von Bild und Beschreibung gelingt technisch sauber über Mechanismen wie aria-describedby - eine Technik, die wir im Beitrag zu [ARIA-Rollen, Zuständen und Live-Regions1 genauer einordnen. Wie alt-Texte allgemein gut formuliert werden, behandelt unser Beitrag zu [barrierefreien Bildern und Alt-Texten2.

Die robusteste Alternative zu einer reinen Bildbeschreibung ist oft, die zugrunde liegenden Daten zusätzlich als barrierefreie Tabelle anzubieten. Wo ein Diagramm exakte Werte transportiert - Umsätze, Messreihen, Vergleichszahlen -, ist eine Tabelle die genaueste Form der Textalternative: Sie macht jeden einzelnen Wert zugänglich, ist mit dem Screenreader Zelle für Zelle navigierbar und lässt sich kopieren oder weiterverarbeiten. Damit dieser Fallback wirklich trägt, muss die Tabelle selbst sauber ausgezeichnet sein - mit th, scope und caption, wie wir es im Beitrag zu [barrierefreien Datentabellen und komplexen Inhalten1 ausführlich beschreiben.

Jeder Diagrammtyp bringt eigene Barrieren mit. Beim Kreisdiagramm liegt das Risiko darin, dass sich Segmente nur über die Farbe abheben und kleine Anteile kaum erkennbar sind; hier helfen Muster je Segment, direkte Prozentangaben am Rand und eine begrenzte Zahl an Kategorien. Liniendiagramme werden unleserlich, sobald mehrere Linien dieselbe Farbfamilie nutzen oder dicht beieinander verlaufen - unterschiedliche Linienstile und Endpunkt-Beschriftungen statt einer reinen Farblegende sind die robustere Lösung. Balkendiagramme sind meist am unkompliziertesten, scheitern aber an zu geringem Kontrast zum Hintergrund oder an Werten, die nur per Höhe ablesbar sind statt zusätzlich beschriftet zu werden.

Heatmaps und Ampeldarstellungen sind ein Sonderfall, weil sie Bedeutung fast ausschließlich über den Farbton transportieren - genau das, was WCAG 1.4.1 als alleiniges Mittel ausschließt (W3C/WAI). Hier sollten Zellen zusätzlich beschriftet oder mit Symbolen versehen werden, etwa einem Haken, einem Ausrufezeichen oder einem Wert. Bei Streudiagrammen empfiehlt sich, Datengruppen nicht nur farblich, sondern über Form und Füllung der Punkte zu trennen. In allen Fällen gilt: Je dichter die Darstellung, desto wichtiger werden die direkte Beschriftung und ein begleitender Tabellen-Fallback, damit die Information auch ohne präzise Farb- und Detailwahrnehmung vollständig ankommt.

Interaktive Diagramme - mit Tooltips, Zoom, Filtern oder umschaltbaren Datenreihen - sind besonders anspruchsvoll, weil sie zusätzlich zur Wahrnehmbarkeit die Bedienbarkeit verlangen. Ein Tooltip, der nur bei Maus-Hover erscheint, ist per Tastatur nicht erreichbar und verstößt gegen WCAG 2.1.1 Tastatur. Bedienelemente wie Filter und Umschalter brauchen erreichbare Namen, einen sichtbaren Fokus und eine sinnvolle Reihenfolge. Die Grundlagen dafür behandeln wir in den Beiträgen zu [Tastaturnavigation in der Webentwicklung1 und zur [Screenreader-Optimierung der Website2.

Eine bewährte Strategie ist, für interaktive Visualisierungen stets einen statischen, vollständig zugänglichen Kern bereitzustellen: die Daten als Tabelle, die Kernaussage als Text. Die Interaktivität ist dann eine Verbesserung für alle, die sie nutzen können - aber keine Voraussetzung, um an die Information zu kommen. Aus der Begleitung von 50+ (Projekterfahrung) Projekten wissen wir, dass die meisten Diagramm-Probleme nicht im Chart selbst entstehen, sondern darin, dass die Rohdaten nirgends als Text verfügbar sind.

Barrierefreie Datenvisualisierung berührt vor allem WCAG 1.4.1 Verwendung von Farbe, 1.1.1 Nicht-Text-Inhalt und bei grafischen Elementen 1.4.11 Nicht-Text-Kontrast (W3C/WAI). Da automatische Prüfwerkzeuge nur etwa ein Drittel bis die Hälfte der WCAG-Anforderungen überhaupt testen können (W3C/WAI), zeigt sich erst im manuellen Test, ob ein Diagramm seine Aussage vermittelt. Wer Charts von Anfang an mit doppelter Kodierung, ausreichendem Kontrast, sauberer Textalternative und einem Tabellen-Fallback baut, schafft eine verlässliche Grundlage für das [WCAG-Audit1 - und macht Daten für alle nutzbar.