Barrierefreie Diagramme und Datenvisualisierung

1. Warum Diagramme eine eigene Accessibility-Herausforderung sind

Ein Diagramm transportiert Information über mehrere gleichzeitig wahrnehmbare visuelle Kanäle: die Position von Punkten auf zwei Achsen, die Steigung einer Linie, die relative Höhe von Balken zueinander und häufig zusätzlich Farbe als dritte Dimension. Sehende Nutzer erfassen diese Kombination in Sekundenbruchteilen, ohne jeden einzelnen Datenpunkt bewusst zu lesen, ein Vorgang, der sich nicht einfach in einen linearen, seriell vorgelesenen Text übersetzen lässt.

Anders als bei einem einzelnen informativen Bild, bei dem ein präziser Alternativtext die Kernaussage meist vollständig transportieren kann, steckt in einem Diagramm häufig eine ganze Reihe unterschiedlicher, potenziell relevanter Informationen gleichzeitig: der grobe Trend, einzelne Ausreißer, ein Vergleich zwischen mehreren Datenreihen und die zugrunde liegenden konkreten Zahlenwerte. Ein einziger Alternativtext muss sich zwangsläufig für eine grobe Zusammenfassung entscheiden und lässt genau jene Details weg, die für manche Nutzer die eigentlich relevante Information darstellen.

2. Warum ein einfacher Alternativtext bei komplexen Charts nicht reicht

Ein Alternativtext wie Diagramm zeigt Preisentwicklung über zwölf Monate erfüllt zwar formal die Anforderung, einen Alt-Text zu setzen, liefert aber keinerlei tatsächlichen Informationswert, da er die eigentliche Aussage des Diagramms, nämlich Richtung, Ausmaß und Zeitpunkt der Preisänderung, komplett offenlässt. Für WCAG 1.1.1 ist ein solcher Text zwar technisch vorhanden, verfehlt aber den eigentlichen Zweck der Anforderung, nämlich eine gleichwertige Information für Nutzer bereitzustellen, die das Bild nicht sehen können.

Selbst ein deutlich ausführlicherer Alternativtext stößt an eine praktische Grenze: Ein Alt-Attribut wird von den meisten Screenreadern als ein einziger, ununterbrochener Textblock vorgelesen, ohne Möglichkeit, gezielt zu einzelnen Datenpunkten zu springen oder eine konkrete Zahl nachzuschlagen, was bei einem Diagramm mit zwanzig oder mehr Datenpunkten schnell unpraktikabel wird.

3. Versteckte Datentabelle als Fallback-Pattern

Das robusteste Pattern für komplexe Diagramme ist eine vollständige, semantisch korrekte HTML-Tabelle mit denselben Rohdaten, die dem Diagramm zugrunde liegen, visuell verborgen für sehende Nutzer, aber vollständig zugänglich für Screenreader und per Tastatur navigierbar. Eine solche Tabelle liefert genau das, was ein Alt-Text strukturell nicht kann: einzeln ansteuerbare Zeilen und Spalten, korrekt ausgezeichnete Kopfzeilen und beliebig genaue Zahlenwerte statt einer groben Zusammenfassung.

Wichtig ist dabei, die Tabelle nicht mit display none zu verstecken, da dieses CSS-Attribut das Element auch aus dem Accessibility Tree entfernt und damit für Screenreader unerreichbar macht. Stattdessen kommt eine visuell versteckende, aber semantisch erhaltende Klasse zum Einsatz, die das Element aus dem sichtbaren Layout entfernt, ohne es aus der Wahrnehmung von unterstützender Technologie zu entfernen.

<figure aria-labelledby="preis-chart-titel">
  <figcaption id="preis-chart-titel">Preisverlauf der letzten 12 Monate</figcaption>

  <!-- Visuelles Chart, für Screenreader per aria-hidden ausgeblendet -->
  <div id="preis-chart" aria-hidden="true"></div>

  <!-- Versteckte, aber vollständig zugängliche Datentabelle -->
  <table class="sr-only">
    <caption>Rohdaten zum Preisverlauf-Diagramm</caption>
    <thead>
      <tr><th scope="col">Monat</th><th scope="col">Preis in Euro</th></tr>
    </thead>
    <tbody>
      <tr><td>Januar</td><td>89,90</td></tr>
      <tr><td>Februar</td><td>84,50</td></tr>
      <tr><td>Maerz</td><td>84,50</td></tr>
    </tbody>
  </table>
</figure>

4. ARIA-Beschreibung von Trends: aria-describedby richtig einsetzen

Neben der vollständigen Datentabelle hilft eine kurze, textuelle Trendzusammenfassung, die über aria-describedby mit dem Diagramm-Container verknüpft wird, damit ein Screenreader beim Fokussieren des Diagramms sofort die wichtigste Kernaussage vorliest, bevor er optional zur ausführlichen Tabelle weitergeht. Diese Zusammenfassung sollte konkrete Werte statt vager Formulierungen enthalten, etwa der Preis ist von 89,90 Euro im Januar auf 79,90 Euro im Dezember gefallen, ein Rückgang von rund elf Prozent, statt lediglich der Preis ist gesunken.

Die Kombination aus aria-describedby für die Kurzzusammenfassung und einer verlinkten, vollständigen Tabelle für die Detailwerte bildet damit eine gestufte Informationsarchitektur ab, die sowohl schnellen Überblick als auch präzise Detailrecherche erlaubt, statt sich zwischen beiden Bedürfnissen entscheiden zu müssen.

5. figure, figcaption und details: die Bausteine für strukturierte Charts

Das figure-Element mit einem figcaption-Kindelement liefert die semantisch korrekte Klammer für ein Diagramm und dessen Beschriftung und wird von Screenreadern als zusammengehörige Einheit mit Titel angekündigt, was bereits vor jeder ARIA-Ergänzung eine solide semantische Grundlage schafft. Innerhalb dieser figure lässt sich die versteckte Datentabelle entweder dauerhaft im Accessibility Tree belassen oder über ein details-Element optional einblendbar gestalten, sodass auch sehende Tastaturnutzer bei Bedarf gezielt auf die Rohdaten zugreifen können.

Ein details-Element mit einem summary wie Daten als Tabelle anzeigen bietet dabei den zusätzlichen Vorteil, dass es nativ per Tastatur bedienbar ist, ohne eigenes JavaScript für das Ein- und Ausblenden zu benötigen, und dass es sowohl sehenden als auch blinden Nutzern gleichermaßen zugutekommt, statt eine Lösung ausschließlich für eine Nutzergruppe zu bauen.

6. Praxisbeispiel: ein barrierefreies Preisverlauf-Chart im Produktfrontend

Für ein Preisverlauf-Chart im Produktfrontend, etwa gerendert mit Chart.js in einem Hyvä-Theme, kombiniert die barrierefreie Umsetzung ein aria-hidden gesetztes Canvas-Element mit der bereits beschriebenen, versteckten Datentabelle direkt darunter im DOM. Wichtig ist zusätzlich, dass jede farbliche Kodierung im Chart, etwa Rot für Preiserhöhung und Grün für Preissenkung, im Alt-Text oder der Trendzusammenfassung textuell wiederholt wird, damit die Information nicht ausschließlich über Farbe transportiert wird.

Ein solches Setup lässt sich vollständig über die bestehende Chart-Bibliothek und ergänzendes HTML umsetzen, ohne dass eine zusätzliche, separate Accessibility-Bibliothek eingebunden werden muss, was insbesondere für Hyvä-Projekte relevant ist, die bewusst auf ein möglichst schlankes JavaScript-Gepäck setzen.

7. Praxisbeispiel: Lagerbestand-Visualisierung im Magento-Admin

Im Magento-Backend sind Diagramme meist Teil eines Dashboards, etwa ein Balkendiagramm zum Lagerbestand kritischer Artikel je Lagerort. Anders als im Frontend richten sich solche Diagramme an ein internes Fachpublikum, das die Daten regelmäßig und unter Zeitdruck prüfen muss, weshalb hier die versteckte Datentabelle nicht nur ein Accessibility-Fallback ist, sondern auch für sehende Nutzer mit Screen-Magnifier oder starkem Zoom eine wertvolle, kompakte Alternative zur grafischen Darstellung darstellt.

Für Admin-Dashboards lohnt sich zusätzlich, kritische Schwellenwerte, etwa einen Lagerbestand unter der Nachbestellgrenze, nicht nur farblich als roten Balken zu markieren, sondern zusätzlich als Text oder Symbol auszuzeichnen, damit Administratoren mit Farbsehschwäche dieselbe kritische Information ohne Farbwahrnehmung erhalten.

8. Farbcodierung in Diagrammen: Kontrast und Redundanz

Werden mehrere Datenreihen ausschließlich über unterschiedliche Farben unterschieden, etwa mehrere Linien in einem Liniendiagramm, wird die Unterscheidung für Nutzer mit Farbsehschwäche und für Screenreader-Nutzer gleichermaßen unmöglich, sofern keine weitere Kodierung ergänzt wird. Eine robuste Lösung kombiniert Farbe immer mit einem zweiten, redundanten visuellen Merkmal, etwa unterschiedlichen Linienmustern, Symbolen an den Datenpunkten oder direkten Beschriftungen am Ende jeder Linie statt einer separaten Legende.

Zusätzlich sollte jede verwendete Farbe im Diagramm ein ausreichendes Kontrastverhältnis zum Hintergrund aufweisen, mindestens im Bereich von 3 zu 1 für grafische Elemente gemäß WCAG 1.4.11, da ein Diagramm mit blassen Pastellfarben auf weißem Hintergrund selbst für Nutzer ohne diagnostizierte Sehbeeinträchtigung schwer lesbar werden kann.

9. Testing: wie man Chart-Zugänglichkeit mit Screenreadern prüft

Die praxisnaheste Prüfmethode besteht darin, mit ausgeschaltetem Monitor oder geschlossenen Augen ausschließlich mit NVDA oder VoiceOver durch den Diagrammbereich zu navigieren und zu prüfen, ob sich die Kernaussage des Diagramms ohne visuelle Wahrnehmung nachvollziehen lässt: Wird der Titel korrekt angekündigt, lässt sich die versteckte Tabelle erreichen und liest der Screenreader beim Betreten des figure-Elements eine sinnvolle Trendzusammenfassung vor.

Ergänzend lohnt sich eine automatisierte Prüfung mit axe-core oder einem vergleichbaren Werkzeug, das zumindest technische Grundfehler wie ein fehlendes figcaption oder ein aria-hidden auf einem fokussierbaren Element zuverlässig erkennt, auch wenn die inhaltliche Qualität einer Trendzusammenfassung letztlich nur manuell beurteilbar bleibt. Die folgende Tabelle vergleicht die vorgestellten Patterns.

10. Zusammenfassung

11. FAQ: Barrierefreie Diagramme: Das Wichtigste auf einen Blick