Barrierefreie Datenvisualisierungs-Werkzeuge 2026:
ein praxistauglicher Stack
Fünf Bibliotheken dominieren die moderne Datenvisualisierungs-Diskussion, aber nur einige von ihnen behandeln einen Screenreader als erstklassigen Konsumenten. Dies ist die Bewertungsübersicht einer Ingenieurin bzw. eines Ingenieurs aus der Praxis, geschrieben für Teams, die 2026 Diagramme in Produktion bringen.
1. Die fünf Achsen, die darüber entscheiden, ob ein Diagramm barrierefrei ist
Der Begriff „barrierefreies Diagramm“ verbirgt eine Reihe leise unterschiedlicher Anforderungen. Ein Balkendiagramm kann als SVG mit perfektem Farbkontrast gerendert werden und für Tastaturnutzer dennoch unerreichbar sein. Es kann tastaturnavigierbar sein und einem Screenreader dennoch nichts Nützliches mitteilen. Es kann Werte sauber vorlesen und sehbehinderte Nutzer beim ersten Tooltip dennoch im Stich lassen. Um Bibliotheken fair vergleichen zu können, wird jede gegen fünf unabhängige Achsen bewertet, die direkt abbilden, wie ein Nutzer assistiver Technologie eine Visualisierung erlebt.
Diese fünf Achsen sind keine persönliche Präferenzliste. Sie sind die praktische Übersetzung der WCAG-2.2-Erfolgskriterien (1.4.11 Kontrast bei Nicht-Text-Inhalten, 2.1.1 Tastatur, 4.1.2 Name, Rolle, Wert), der ARIA Authoring Practices-Empfehlungen zu Diagrammen und Grafiken sowie des W3C-Entwurfs der Research Questions Task Force „Data Visualization Accessibility“, der seit 2023 kursiert. Jede Diagrammbibliothek erzeugt SVG; jede rendert irgendeine Art von Legende; jede hat eine Meinung zu Farben. Was sie unterscheidet, sind die Standardeinstellungen — das Diagramm, das man erhält, wenn man den kleinstmöglichen sinnvollen Code schreibt.
1. SVG mit semantischem ARIA. Gibt die Bibliothek SVG aus (kein Canvas), und trägt dieses SVG aussagekräftige Rollen, Labels und Gruppenstrukturen statt anonymer <g>-Verschachtelungen?
2. Farbenblindensichere Paletten als Standard. Sind die kategorischen und sequenziellen Paletten CVD-getestet, oder muss man wissen, dass man sie überschreiben muss?
3. Tastaturnavigierbare Datenpunkte. Kann ein sehender Nur-Tastatur-Nutzer das Diagramm per Tab betreten, mit den Pfeiltasten zwischen Markierungen wechseln und den Wert jeder Markierung lesen?
4. Screenreader-Beschreibungshierarchie. Gibt es einen Titel, eine Ein-Satz-Zusammenfassung und Ansagen je Serie/Punkt — nicht nur einen einzelnen Alt-Text-Dump?
5. Alternative Tabellenansicht. Sind die zugrunde liegenden Daten als HTML-Tabelle verlinkt oder neben dem Diagramm gerendert, für Nutzer, die tabellarische Darstellung bevorzugen?
„Ein Diagramm, das mit perfektem Kontrast und einer farbenblindensicheren Palette, aber ohne Tastaturmodell ausgeliefert wird, ist ein Diagramm, das für die Hälfte des Publikums gerendert wurde.“
2. Die fünf Bibliotheken im Überblick
Fünf Bibliotheken decken 2026 den überwältigenden Großteil neuer Diagrammarbeit ab: Vega-Lite, Plotly, Observable Plot, Apache ECharts und D3 mit eigenem Code. Sie befinden sich an unterschiedlichen Punkten der Abstraktionsachse — Vega-Lite ist am deklarativsten, D3 am imperativsten — und jede verfolgt einen anderen Ansatz zur Barrierefreiheit. D3 wird gesondert behandelt, weil „D3 + eigener Code“ ein grundsätzlich anderes Engineering-Versprechen ist: die Barrierefreiheit, die man erhält, ist die Barrierefreiheit, die man schreibt.
Keine dieser Bibliotheken ist feindlich gegenüber Barrierefreiheit. Alle erzeugen SVG (Plotly und ECharts können auch Canvas ausgeben; hier wird der SVG-Modus bewertet). Alle akzeptieren beliebige Farbpaletten. Die Frage ist, was man erhält, wenn man den kleinstmöglichen sinnvollen Code schreibt, und wie viel Umverdrahtung nötig ist, um von diesem Standard zu einem Diagramm zu gelangen, das WCAG 2.2 AA tatsächlich erfüllt.
Die „null Punkte“-Bewertung für D3 ist keine Kritik an der Bibliothek — sie ist die ehrliche Beschreibung dessen, was man von einem Vanilla-D3-Build bekommt. D3 sind Primitive. Barrierefreiheit in einem D3-Diagramm ist das, was der Autor schreibt. Ein D3-Diagramm, das von einer Ingenieurin oder einem Ingenieur mit ARIA-Kenntnissen erstellt wird, kann das barrierefreieste Diagramm auf der Seite sein; ein D3-Diagramm ohne dieses Wissen ist fast immer das am wenigsten barrierefreie Diagramm auf der Seite.
3. Die Bewertungsmatrix: Bibliothek nach Barrierefreiheitsmerkmal
Die fünf Achsen aus Abschnitt eins, bewertet gegen die fünf Bibliotheken aus Abschnitt zwei. „Ja“ bedeutet, das Standardverhalten erfüllt die Achse; „Teilweise“ bedeutet, die Bibliothek stellt die richtigen Hooks bereit, aktiviert sie aber nicht standardmäßig; „Manuell“ bedeutet, der Entwickler muss den entsprechenden Code von Grund auf selbst schreiben.
| Vega-Lite | Plotly.js | Observable Plot | Apache ECharts | D3 + eigener Code | |
|---|---|---|---|---|---|
| SVG-Ausgabe mit semantischem ARIA | Ja (SVG, benannte Gruppen) | Ja (SVG, ARIA-Labels) | Ja (SVG, Markierungsrollen) | Teilweise (Canvas Standard; SVG-Renderer opt-in) | Manuell |
| Farbenblindensichere Paletten als Standard | Ja (Tableau 10 + viridis) | Teilweise (Plotly-Standard; CVD-Palette opt-in) | Ja (Observable categorical10) | Teilweise (Standardschema nicht CVD-getestet) | Manuell |
| Tastaturnavigierbare Datenpunkte | Teilweise (Fokus auf Legende; Markierungen per Konfiguration) | Ja (Pfeiltatsten-Navigation ab 2.x) | Teilweise (tip-Plugin gibt Fokus; Markierungen manuell) | Teilweise (a11y-Modul opt-in) | Manuell |
| Screenreader-Beschreibungshierarchie | Ja (description-Spec-Eigenschaft) | Teilweise (einzelner Titel; pro Punkt opt-in) | Ja (ariaLabel + ariaDescription-Markierungen) | Teilweise (a11y-Modul gibt Alt-Text je Serie aus) | Manuell |
| Alternative Tabellenansicht | Teilweise (Datentabelle einfach zu rendern) | Teilweise (Export als CSV; keine In-DOM-Tabelle) | Teilweise (data()-Hilfsfunktion, keine Auto-Tabelle) | Teilweise (Toolbox unterstützt Datenansicht) | Manuell |
Vega-Lite und Observable Plot führen bei deklarativen Standards. Plotly führt bei eingebauter Tastaturnavigation. ECharts hat das ausgefeilteste opt-in Barrierefreiheitsmodul aller Bibliotheken auf der Liste — aber nur, wenn es aktiviert wird. D3 gibt einem nichts und alles: jede Zelle ist „Manuell“, weil die Bibliothek keine Meinung hat. Keine dieser Bibliotheken ist eine Ein-Zeilen-Lösung; alle sind mit Absicht handhabbar.
4. Gutes Diagramm, schlechtes Diagramm: dieselben Daten, zwei Wege
Die Matrix zeigt, was jede Bibliothek bietet; dieser Abschnitt zeigt, was eine Ingenieurin oder ein Ingenieur in der Praxis tatsächlich schreibt. Dieselben Daten, zwei Implementierungen. Die „schlechte“ Version wird schnell fertig und sieht auf einem 27-Zoll-Monitor gut aus. Die „gute“ Version braucht 12 Zeilen Code mehr und erfüllt jede Achse der Matrix.
// Vega-Lite — nur Standardwerte
{
"data": { "url": "complaints.csv" },
"mark": "bar",
"encoding": {
"x": { "field": "category", "type": "nominal" },
"y": { "field": "count", "type": "quantitative" },
"color": { "field": "category" }
}
}Wird gerendert. Sieht gut aus. Kein Diagrammtitel für den Screenreader. Keine Beschreibung. Kein Tastaturmodell für die Markierungen. Standardfarbschema nicht CVD-getestet für die tatsächliche Anzahl von Kategorien. Keine Rückfall-Tabelle.
// Vega-Lite — barrierefreie Standardwerte
{
"title": "Beschwerden nach Oberfläche, 2024",
"description":
"Balkendiagramm mit 4.605 Web-Barrierefreiheitsbeschwerden, nach Oberfläche sortiert. Höchstwert: Formulare (1.940).",
"data": { "url": "complaints.csv" },
"mark": { "type": "bar", "ariaRoleDescription": "bar" },
"encoding": {
"x": { "field": "category", "type": "nominal",
"axis": { "labelAngle": -30 } },
"y": { "field": "count", "type": "quantitative",
"title": "Beschwerden" },
"color": {
"field": "category",
"scale": { "scheme": "tableau10" },
"legend": { "title": "Oberfläche" }
},
"tooltip": [
{ "field": "category", "title": "Oberfläche" },
{ "field": "count", "title": "Beschwerden" }
]
},
"usermeta": { "embedOptions": { "ariaLabel": "Beschwerde-Diagramm" } }
}Titel, Beschreibung, CVD-sichere Palette, benannte Achse, benannte Tooltip-Felder, ARIA-Rollenbeschreibung für die Markierung. Gepaart mit einer <table>, die aus demselben Datensatz gerendert wird, erfüllt dies jede Achse der Matrix, ohne die deklarative Grammatik zu verlassen.
Das gute Diagramm ist kein anderes Diagramm. Es ist dasselbe Diagramm, bei dem die impliziten Standardwerte explizit gemacht, der Titel aufgeschrieben, die Palette benannt, die Rolle jeder Markierung ausformuliert und die Daten zusätzlich als Tabelle angeboten wurden. Das ist die gesamte Kunst.
Keine der fünf Bibliotheken liefert standardmäßig einen „Diagramm als Tabelle rendern“-Modus. Das bewährte Muster lautet: dieselben Daten an zwei Komponenten binden — das Diagramm und eine HTML-<table> darunter, oft visuell verborgen, aber für assistive Technologie zugänglich, mit einem Umschalter „Datentabelle anzeigen“, der ein hidden-Attribut kippt. Dieses Muster kostet ca. 20 Zeilen Framework-Code je Diagramm und amortisiert sich innerhalb der ersten Nutzerforschungssitzung.
5. Konkrete Empfehlungen nach Anwendungsfall
Die Bibliothekswahl 2026 dreht sich vor allem um die Workflow-Eignung. Die fünf Bibliotheken sind alle handhabbar. Die Frage ist, welche zu den Diagrammen passt, die tatsächlich geliefert werden. Fünf häufige Anwendungsfälle, fünf Empfehlungen, mit genannter zweitbester Alternative.
Redaktionelle / datenjournalistische Diagramme (ein Diagramm, poliert)
Empfehlung: Observable Plot, mit Vega-Lite als knappem Zweitplatzierten. Plots markbasierte API gibt per-Markierung-ARIA-Labels kostenlos mit, die kategorische Palette ist CVD-getestet, und die SVG-Ausgabe liest sich sauber. Vega-Lite ist hier Zweitplatzierter, weil die description-Eigenschaft die sauberste Einzel-Attribut-Screenreader-Zusammenfassung aller Bibliotheken ist — aber Plot gewinnt bei den Standard-Ergonomics für einmalige Redaktionsstücke.
Von Analysten erstellte Dashboards (viele Diagramme, deklarativ)
Empfehlung: Vega-Lite, mit Observable Plot als knappem Zweitplatzierten. Vega-Lites Spezifikationsgrammatik erlaubt Analysten, 30 Diagramme in einem Notebook ohne JavaScript-Schreiben zu komponieren, und die title- und description-Eigenschaften des Schemas liefern die Screenreader-Hierarchie ohne zusätzliche Infrastruktur. Jedes Diagramm mit einer Vega-gerenderten Datentabelle paaren, um die alternative-Tabellenansicht-Achse zu erfüllen.
Wissenschaftliche / BI-Dashboards (interaktive Exploration)
Empfehlung: Plotly.js, mit ECharts als knappem Zweitplatzierten. Plotly ist die einzige Bibliothek auf der Liste, die Tastatur-Pfeiltatsten-Navigation zwischen Markierungen als Standard in der 2.x-Linie mitbringt. Falls das Publikum erwartet, hovern, zoomen und bohren zu können, ist Plotlys eingebautes Tastaturmodell das entscheidende Kriterium. ECharts zieht gleich, wenn das aria-Modul aktiviert wird — es muss aber aktiviert werden.
Hochdichte operative Dashboards (Hunderte von Punkten, leistungskritisch)
Empfehlung: Apache ECharts mit SVG-Renderer und aktiviertem aria-Modul, mit Plotly als knappem Zweitplatzierten. ECharts hat die stärkste Performance-Geschichte in dieser Gruppe für sehr dichte Diagramme, und das aria-Modul erzeugt Alt-Text je Serie, den Screenreader kompetent verarbeiten. Den Canvas-Renderer abschalten; Canvas ist schneller, aber der Accessibility-Baum verschwindet.
Maßgeschneiderte redaktionelle Diagramme, die keine Bibliothek rendert (individuell, einmalig)
Empfehlung: D3 mit handgeschriebener Barrierefreiheitsschicht. Die handgeschriebene Schicht ist nicht verhandelbar: ein <title>- und <desc>-Element am SVG-Stamm, role=“img” mit aria-label je fokussierbarer Markierung, ein Fokusmodell für jede fokussierbare Markierung und eine Schwester-<table>, gerendert aus demselben Datensatz. D3 ist das richtige Werkzeug, wenn das Diagramm genuinely nirgendwo anders existiert; es ist das falsche Werkzeug, wenn es sich um ein Balkendiagramm handelt und jemand gewohnheitsmäßig zu D3 gegriffen hat.
Das Diagramm innerhalb einer Diagrammbibliothek ist selten das Einzige auf der Seite. Tooltips, die nur per Hover erscheinen und nie bei Fokus, Legenden als <div> statt <ul>, Fokusringe, die durch das Reset-Stylesheet der Seite überschrieben werden, Farbfelder mit unzureichendem Nicht-Text-Kontrast gegen den Seitenhintergrund — das sind Fehler auf Seitenebene, die keine Diagrammbibliothek reparieren wird. Die Bibliothek liefert die Markierungen; die Seite liefert den Rest.
Fazit: Der praxistaugliche Stack ist der, den man aufschreibt
Keine der fünf Bibliotheken auf der Liste ist die falsche Antwort. Alle erfüllen die meisten Achsen mit einem kleinen Maß an Absicht. Der zuverlässigste einzelne Prädiktor für ein barrierefreies Diagramm 2026 ist nicht die Bibliothek auf der Import-Zeile — es ist, ob das Team an derselben Stelle wie das Design-System aufgeschrieben hat, was „barrierefreies Diagramm“ in dieser Organisation bedeutet. Titel. Beschreibung. Palette. Tastaturmodell. Alternative Tabelle. Fünf Zeilen in einer CONTRIBUTING.md; der Unterschied zwischen einem Diagramm, das ausgeliefert wird, und einem Diagramm, das ankommt.
Die Bibliothek wählen, die zum Workflow passt, ihre Barrierefreiheits-Standards aktivieren, jedes Diagramm mit einer Datentabelle paaren und das Seiten-Chrome rund um das Diagramm genauso sorgfältig auditieren wie das Diagramm selbst. Das Standarddiagramm jeder dieser Bibliotheken kann barrierefrei gemacht werden. Das Standarddiagramm keiner dieser Bibliotheken ist ohne Absicht barrierefrei.
„Die Bibliothek liefert die Markierungen; die Seite liefert den Rest.“