Der Kreis der davon betroffenen Anwendungen und Unternehmen ist groß und reicht von den Websites, Kundenportalen, Online Shops und Apps von B2C-Unternehmen bis zu den Webauftritten, Anwendungen, Dokumenten und Formularen öffentlicher Stellen wie Verwaltungen, Kommunen, Universitäten oder Krankenhäuser. Im Sinne eines gesellschaftlichen Interesses an gleichberechtigter Teilhabe sollte es auch unabhängig von gesetzlichen Pflichten das Ziel sein, die Barrierefreiheit von digitalen Anwendungen aktiv mitzudenken.
Dies gilt auch für Datenprodukte, also Anwendungen und Dashboards, die Daten und Analysen anwenderfreundlich und verständlich bereitstellen sollen. Der Fokus der Regulierung liegt auch hier auf Datenprodukten, die für KundInnen bzw. BürgerInnen bereitgestellt werden. Die Beispiele reichen von öffentlichen Dashboards zum Beispiel im Finanz- oder Gesundheitssektor bis hin zu Kundenchatbots im Service. Die Möglichkeiten und die Präsenz von KI in der Kundenkommunikation verstärken die Bedeutung des Themas Barrierefreiheit zusätzlich.
Viele Data-Science-Teams investieren viel Zeit in UX, Visualisierung und Performance ihrer Dashboards und Anwendungen, übersehen jedoch grundlegende Anforderungen an Tastaturbedienbarkeit, Screenreader-Kompatibilität oder Farbkontraste. Dabei müssen interaktive Data-Science- und Dashboard-Anwendungen je nach Einsatzgebiet die gleichen Accessibility-Standards erfüllen wie klassische Webanwendungen.
Warum Barrierefreiheit in Dashboards und Datenprodukten besonders wichtig ist?
Das Thema Barrierefreiheit hat in Datenprodukten eine besondere und immer größer werdende Bedeutung. Immer größer werdend, weil in einer digitalen Welt Daten, Analysen und ihre barrierefreie Aufbereitung für unterschiedliche Zielgruppen immer präsenter und wichtiger werden. Eine grundsätzlich besondere Bedeutung hat Barrierefreiheit im Kontext von Data-Science-Lösungen ohnehin, da sie in vielen Fällen einhergehen mit einer hohen Interaktivität und Dynamik und datenintensive Anwendungen oftmals inhaltlich komplexer sind. Komplexe Tabellen, interaktive Datenvisualisierungen, Filter-Logiken, Live-Updates und Co. schaffen Rahmenbedingungen die die Barrierefreiheit erschweren können.
Entwicklung von barrierefreien Dashboards: WCAG-Richtlinien geben Orientierung
Die meisten Anforderungen zum Beispiel für die Entwicklung von Shiny-Anwendungen orientieren sich an den WCAG-Richtlinien (Web Content Accessibility Guidelines) des World Wide Web Consortium.
Die WCAG basieren auf vier Grundprinzipien:
- Wahrnehmbarkeit (Text-Alternativen, Anpassbarkeit etc.)
- Bedienbarkeit (Tastaturbedienbarkeit, Eingabemodalitäten, ausreichend Zeit zur Eingabe etc.)
- Verständlichkeit (Lesbarkeit, Vorhersehbarkeit, Unterstützung bei der Fehlervermeidung)
- Robustheit (Kompatibilität)
Barrierefreiheit: Typische Probleme von Dashboards
Oft fehlt in der Entwicklung von Datenprodukten (noch) das Augenmerk auf die Barrierefreiheit und es entstehen immer wieder ähnliche Schwachstellen:
- Fehlende Tastaturbedienung
Viele Komponenten wie interaktive Diagramme, komplexe Filter, Tabs und Popups in Shiny-Applikationen funktionieren primär per Maus. Dies ist problematisch; weil Screenreader-NutzerInnen und Menschen mit motorischen Einschränkungen primär mit der Tastatur arbeiten und Diagramme die keine Tastaturereignisse unterstützen dann praktisch nicht nutzbar sind.
- Dynamische Inhalte ohne Screenreader-Unterstützung
Interaktive Dashboards aktualisieren Inhalte oft asynchron. Dies bedeutet: Nutzerinteraktionen lösen Änderungen aus, der Server berechnet neue Ergebnisse, einzelne UI-Elemente werden aktualisiert und die Seite bleibt dabei geöffnet. Die Aktualisierung erfolgt im Hintergrund, zeitversetzt und ohne einen klassischen Seitenreload. Screenreader erhalten dadurch ohne zusätzliche Hinweise keine Information darüber, dass sich Inhalte geändert haben.
- Nicht ausreichende Farbkontraste
Besonders Dashboards haben das Potenzial für Fehler im Sinne der Barrierefreiheit, was die Auswahl der verwendeten Farben und Schriftgrößen angeht. Oft bestimmen Pastellfarben, zu kleine Schrift oder rein farbliche Statusanzeigen das Bild. Dies wirkt sich negativ auf die Lesbarkeit aus.
- Fehlende semantische Struktur
Typische Probleme in der semantischen Struktur ist das Fehlen sinnvoller Überschriftenhierarchien, von eindeutigen Labels sowie der Einsatz von zu generischen Buttons ohne Kontext oder unstrukturierten Tabellen.
Angelehnt an WCAG: Checklist für barrierefreie Dashboards
- Semantische Seitenstruktur
Eine semantische Seitenstruktur bedeutet, dass der Aufbau einer Website oder Webanwendung so gestaltet ist, dass Inhalte und Bereiche nicht nur visuell, sondern auch technisch eindeutig beschrieben sind. Semantik im Web schafft Klarheit darüber, welche Bedeutung und Funktion einzelne Elemente innerhalb einer Anwendung besitzen.
Eine zugängliche Anwendung beginnt mit sauber strukturiertem HTML.
Empfehlungen
- Genau eine Hauptüberschrift (h1) pro Seite
- Logische und hierarchische Überschriftenstruktur
- Verwendung semantischer HTML-Elemente wie main, nav, section, header oder footer
- Sprache definieren
Screenreader benötigen die korrekte Sprachdefinition, um Inhalte richtig auszusprechen und zu interpretieren.
Empfehlung
- Die Sprache der Seite eindeutig definieren, beispielsweise über das lang-Attribut im HTML-Dokument
- Tastaturbedienbarkeit sicherstellen
Eine barrierefreie Anwendung sollte vollständig ohne Maus bedienbar sein.
Prüfen
- Ist die Tab-Reihenfolge logisch?
- Sind Fokuszustände sichtbar?
- Funktionieren Escape-Tasten?
- Gibt es keine sogenannten „Keyboard-Traps“, aus denen Nutzende per Tastatur nicht mehr herausnavigieren können?
Besonders wichtig bei
- Pop-ups
- Sidebar-Menüs
- Navigationselementen
- Interaktiven Widgets
- Skip Links integrieren
Skip Links ermöglichen es Tastatur- und Screenreader-Nutzenden, wiederkehrende Navigationsbereiche zu überspringen und direkt zum Hauptinhalt zu gelangen.
Empfehlung
Einen sichtbaren oder beim Fokus eingeblendeten „Zum Inhalt springen“-Link integrieren
- Formulare korrekt beschriften
Jedes Eingabefeld benötigt eine verständliche und sichtbare Beschriftung.
Wichtig
- Labels müssen eindeutig formuliert sein
- Placeholder-Texte ersetzen keine Labels
- Formularelemente sollten technisch korrekt mit ihren Beschriftungen verknüpft sein
- Dynamische Inhalte mit ARIA unterstützen
Moderne Webanwendungen aktualisieren Inhalte häufig dynamisch, ohne die Seite neu zu laden. Diese Änderungen müssen für Screenreader nachvollziehbar gemacht werden.
Empfehlung
- ARIA-Attribute wie aria-live nutzen, damit Änderungen automatisch angekündigt werden
- Dynamisch erzeugte Inhalte klar strukturieren und verständlich kommunizieren
Dadurch erkennen Assistenztechnologien Änderungen im DOM (Document Object Model) und können diese vorlesen.
- Farbkontraste prüfen
Ausreichende Farbkontraste sind essenziell für die Lesbarkeit und Wahrnehmbarkeit von Inhalten.
WCAG-Empfehlungen
- Mindestens 4.5:1 Kontrastverhältnis für normalen Text
- Mindestens 3:1 für große Schrift
Empfehlung
- Kontraste mit geeigneten Tools prüfen, beispielsweise dem WebAIM Contrast Checker
- Diagramme zugänglich gestalten
Interaktive Visualisierungen gehören zu den größten Herausforderungen im Bereich Accessibility.
Empfehlungen
- Nicht ausschließlich mit Farben arbeiten
- Ergänzend Muster, Formen oder Beschriftungen nutzen
- Diagramme textlich beschreiben
- Daten zusätzlich tabellarisch bereitstellen
- Fokuszustände sichtbar gestalten
- Tooltips screenreaderfreundlich umsetzen
Besonders wichtig bei hochinteraktiven Visualisierungsbibliotheken und komplexen Dashboards.
- Tabellen semantisch strukturieren
Datentabellen benötigen eine klare semantische Struktur, damit sie von Assistenztechnologien korrekt interpretiert werden können.
Empfehlungen
- Korrekte Tabellenüberschriften verwenden
- Verständliche Beschriftungen einsetzen
- Sortierung zugänglich gestalten
- Pagination und Navigation per Tastatur ermöglichen
Gerade umfangreiche Datentabellen stehen häufig im Fokus von Accessibility-Prüfungen.
- Fokus-Management ernst nehmen
Dynamische Anwendungen verändern häufig Inhalte und Komponenten. Ohne gutes Fokus-Management verlieren Nutzende schnell die Orientierung.
Besonders kritisch
- Dynamisch nachgeladene Inhalte
- Modal-Dialoge
- Tabs und Navigationselemente
- Fehlermeldungen, Warnungen oder Ladehinweise
Praxistipp
Für Benachrichtigungen und Statusmeldungen sollten sogenannte ARIA Live Regions verwendet werden. Diese informieren Assistenztechnologien darüber, dass sich Inhalte verändert haben und vorgelesen werden sollen. Dadurch werden dynamische Änderungen auch für Screenreader-Nutzende wahrnehmbar.
Barrierefreiheit sollte Teil des Entwicklungsprozesses von Dashboards sein
Ein häufiger Fehler besteht darin, Accessibility erst kurz vor dem Go-live zu betrachten. Es sollte deshalb frühzeitig ermittelt werden, welche Anforderungen die zu entwickelnde Anwendung bzw. das zu entwickelnde Dashboard in Sachen Barrierefreiheit zu erfüllen hat und wie diese Anforderungen berücksichtigt werden können
Besonders in datengetriebenen Anwendungen spart ein frühzeitiger Accessibility-Fokus später erheblichen Aufwand.
Fazit
Entwicklerteams, die Accessibility von Beginn an mitdenken, profitieren nicht nur hinsichtlich Compliance, sondern auch durch bessere UX, höhere Wartbarkeit und robustere Anwendungen. Kurzum: Sie profitieren davon, dass die zentralen Botschaften ihrer Shiny-Anwendungen die Zielgruppe noch besser erreichen.
Wir unterstützen Sie bei der Entwicklung von barrierefreien Dashboards
Sie wollen barrierefreie Dashboards und Datenprodukte entwickeln oder bestehende Anwendungen in Richtung Barrierefreiheit im Sinne von BITV 2.0 weiterentwickeln?
Wir unterstützen Sie sehr gerne dabei. Eine besondere Stärkem von uns: Die Entwicklung von Webanwendungen aus R und Python heraus - zum Beispiel mit Shiny.
Veröffentlicht: 22. Mai 2026
Autor: Tobias Titze
Starten Sie jetzt durch:
Wir freuen uns auf den Austausch mit Ihnen.
