Eines der führenden Frameworks zur Entwicklung interaktiver Dashboards und Webanwendungen direkt aus R und Python heraus ist Shiny. In diesem Beitrag zeigen wir, was die Stolpersteine auf dem Weg zu barrierefreien Shiny-Anwendungen sind, worauf es besonders zu achten gilt und wie sich mit Shiny EAA & BITV 2.0 konforme Anwendungen im Sinne der Web Content Accessibility Guidelines (WCAG) entwickeln lassen.
Warum Barrierefreiheit in Shiny-Anwendungen 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.
Da Shiny HTML dynamisch erzeugt, entstehen Accessibility-Probleme oft unbeabsichtigt – beispielsweise durch fehlende ARIA-Attribute oder unzureichendes Fokus-Management. ARIA steht für Accessible Rich Internet Applications und umfasst HTML-Erweiterungen, die die Barrierefreiheit von Websites fördern, in dem sie die Semantik von dynamischen Webinhalten beschreiben. Fokus-Management bedeutet, dass die Shiny-Anwendung gezielt steuert, welches Element in diesem Moment den Tastaturfokus besitzt. Also welches Element Nutzende mit Tastatur oder Screenreader gerade bedienen (also typischerweise dort wo die Bedienung von Tab, Enter, Space und Pfeiltasten wirkt).
Entwicklung von barrierefreien Shiny-Anwendungen: An welchem Standard kann man sich orientieren?
Die meisten Anforderungen zum Beispiel für die Entwicklung von Shiny-Anwendungen orientieren sich an den WCAG-Richtlinien 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 in Shiny-Apps
Vorab: R Shiny und auch Shiny for Python bieten durch den großen Funktionsumfang und ihre Flexibilität das Rüstzeug, um optimale Anwendungen im Sinne der Barrierefreiheit zu entwickeln. Shiny ist aber nicht „out-of-the-box“ barrierefrei. Oft fehlt in der Entwicklung aber (noch) das Augenmerk auf die Barrierefreiheit und es entstehen immer wieder ähnliche Schwachstellen:
- Fehlende Tastaturbedienung
- Dynamische Inhalte ohne Screenreader-Unterstützung
- Nicht ausreichende Farbkontraste
- Fehlende semantische Struktur
Angelehnt an WCAG: Checkliste für barrierefreie Shiny-Anwendungen und -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 sind das Herzstück von Shiny, gehören aber auch zu den größten Accessibility-Herausforderungen.
Empfehlungen
- Farbblindheit mitdenken und neben farblichen Unterschieden z.B. auch auf Muster setzen (z.B. bei gestapelten Säulendiagrammen)
- Diagramme textlich beschreiben
- Daten zusätzlich tabellarisch anbieten
- Fokuszustände sichtbar machen
- Tooltips screenreaderfreundlich gestalten
Besonders zu prüfen bei Bibliotheken, die hochinteraktive und stark visuelle Inhalte erzeugen wie plotly und highcharter.
- Tabellen semantisch strukturieren
Wie oben beschrieben sind auch umfassende und komplexe Datentabellen bei der Ermöglichung der Barrierefreiheit besonders im Fokus. Datentabellen in Shiny benötigen:
- korrekte Header
- verständliche Beschriftungen
- zugängliche Sortierung
- tastaturbedienbare Pagination
- Fokus-Management ernst nehmen
Herausforderung: Dynamische Shiny-Anwendungen verändern permanent das DOM, zum Beispiel durch das Nachladen von Inhalten, die Erzeugung neuer Komponenten durch Filter oder den Wechsel von Tabs. Ohne gutes Fokus-Management verlieren User schnell die Orientierung.
Besonders kritisch:
- Dynamische Inhalte mit renderUI() – neue Elemente erscheinen, Fokus bleibt irgendwo im alten DOM „stecken“
- Nutzende klicken und es entsteht Modal-Dialog – der Tastaturfokus bleibt aber im Hintergrund und User merken nicht, dass ein Dialog geöffnet wurde
- Notifications wie Fehlermeldungen, Warnungen oder Ladehinweise – erscheinen oft visuell, temporär und außerhalb des aktuellen Fokus, was die Barrierefreiheit erschwert. Praxistipp für Notifications ARIA Live Regions verwenden. Eine ARIA Live Region informiert Assistenztechnologien darüber:„Wenn sich dieser Bereich verändert, lies die Änderung bitte vor.“ Dadurch werden dynamische Inhalte hörbar gemacht.
Welche Packages helfen auf dem Weg zu barrierefreien Shiny-Apps?
Hilfreiche Werkzeuge im Shiny-Ökosystem:
- Bslib: Unterstützt zugängliche Themes und Kontraste auf Basis von Bootstrap, welches oft eine bessere semantische Grundlage bietet als stark individuell gebaute Layouts
- a11yShiny: Package mit barriereärmeren Wrappern für typische Shiny-Komponenten. Ergänzt ARIA-Attrbute, Skip Links etc. und unterstützt dadurch WCAG- und BITV-Anforderungen.
- highcharter: Highcharts bietet ein eigenes Accessibility-Modul für Screenreader-Unterstützung, Tastaturnavigation und bessere Zugänglichkeit von Diagrammen. Bei highcharter sollte geprüft werden, ob diese Funktionen korrekt aktiviert und konfiguriert sind.
- htmltools: Erleichtert semantisches HTML.
Barrierefreiheit von Shiny-Anwendungen testen
Tools für die automatisierte Überprüfung der Barrierefreiheit sollen vor allem erkennen, ob eventuell Labels fehlen, Kontrastprobleme bestehen oder ARIA-Attribute oder Überschriften fehlen. Eine Auswahl empfohlener Tools:
- shinya11y: Hilft beim Prüfen von Accessibility-Problemen direkt in der Shiny-App. Es integriert tota11y und zeigt u. a. Probleme mit Labels, Kontrasten, Überschriftenstruktur und Screenreader-Wahrnehmung. Gut für frühe Checks in der Entwicklung.
- shinytest2: Ist in der Lage Benutzerinteraktionen automatisiert aufzuzeichnen, Tests reproduzierbar auszuführen und Shiny Anwendungen systematisch prüfen zu lassen. Das Package integriert sich direkt in das populäre R-Testframework testthat.
- Lighthouse Accessibility Audits: Lighthouse-Faktor für Barrierefreiheit ist ein gewichteter Durchschnitt aller Prüfungen der Barrierefreiheit
- axe DevTools: Eines der wichtigsten Accessibility-Tools, da es viele WCAG-Probleme automatisch identifiziert und diese verständlich beschreibt.
- WAVE Accessibility Tool: WAVE visualisiert Barrierefreiheitsprobleme direkt in der Anwendung und ist gut geeignet für schnelle Prüfungen und erste Analysen.
Automatisierte Accessibility-Tests sind sehr wichtig — sie reichen aber oft nicht aus, weil viele Probleme nicht rein technisch erkannt werden können. Gerade bei R Shiny-Anwendungen, Dashboards und interaktiven Datenvisualisierungen entstehen viele Accessibility-Probleme erst im tatsächlichen Nutzungskontext, durch Interaktion, durch dynamische Inhalte oder durch fehlende Verständlichkeit.
Hierfür braucht es Tastaturtests (Maus weglegen, komplette Anwendung nur per Tastatur bedienen), Screenreader-Tests (Tools: NVDA unter Windows, VoiceOver für macOs und iOS)
Fazit
Barrierefreie R Shiny-Anwendungen sind technisch anspruchsvoller als klassische statische Websites – insbesondere durch dynamische Inhalte und interaktive Datenvisualisierung.
Mit einer strukturierten Accessibility-Strategie lassen sich jedoch viele typische Probleme früh vermeiden:
- semantisches HTML,
- Tastaturbedienbarkeit,
- Fokusmanagement,
- ausreichende Kontraste,
- und screenreaderfreundliche dynamische Inhalte.
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 Shiny-Dashboards und -Applikationen
Sie wollen barrierefreie Dashboards und Datenprodukte mit Shiny entwickeln oder bestehende Shiny- Anwendungen in Richtung Barrierefreiheit im Sinne von BITV 2.0 weiterentwickeln?
Wir unterstützen Sie sehr gerne dabei. Erfahren Sie mehr zu unseren Leistungen und Referenzen rund um R-Shiny und Shiny for Python.
Veröffentlicht: 26. Mai 2026
Autor: Tobias Titze
Starten Sie jetzt durch:
Wir freuen uns auf den Austausch mit Ihnen.
