Interaktive und dynamische Websites barrierefrei umsetzen

Online-Angebote haben ein enormes Potenzial für Menschen mit Behinderungen und können Betroffenen ein Stück Selbständigkeit und Chancengleichheit zurückgeben. Dafür müssen Webseiten aber barrierefrei umgesetzt sein, damit sie auch für blinde und gehörlose Menschen ebenso wie für motorisch Behinderte und Menschen mit kognitiven Einschränkungen nutzbar sind. Damit Web-Projekte die Anforderungen der Barrierefreiheit kostengünstig berücksichtigen können, ist ein möglichst früher Einbezug im Projektvorgehen erforderlich, was besonders für interaktive und dynamische Websites gilt. Die Stiftung "Zugang für alle" setzt sich als langjährige Partnerin des BAKOM für die Förderung einer inklusiven Informationsgesellschaft ein und berät Web-Projekte zu allen Belangen der Barrierefreiheit.

Andreas Uebelbacher & Anton Bolfing, Stiftung "Zugang für alle"

Für viele Menschen ist das Internet heute nicht mehr aus dem Alltag wegzudenken, weder im Berufs- noch im Privatleben. Für Menschen mit Behinderungen ist der Zugang zu Online-Angeboten jedoch häufig noch wichtiger, da er vielfach die einzige Möglichkeit überhaupt darstellt, an Informationen zu gelangen, die ihnen sonst ganz verschlossen blieben. So wäre etwa ein Behördengang anstelle der bequemen Nutzung eines E-Government-Angebots am Rechner zu Hause sicher sowieso deutlich aufwändiger. Abhängig von der Art der Behinderung kann ein solcher Weg zur nicht vertrauten Adresse einer Behörden-Stelle jedoch ganz unmöglich sein und nicht nur eine Frage der Bequemlichkeit darstellen.

Damit Websites auch von Menschen mit Behinderungen genutzt werden können, müssen diese barrierefrei umgesetzt sein. Erst dann können alle Nutzerinnen und Nutzer gleichermassen auf die betreffenden Inhalte online zugreifen und damit etwas anfangen. Dies geschieht oft mit sogenannten 'assistiven Technologien', also mit unterstützender Soft- oder Hardware, welche Ein-/Ausgaben den besonderen Bedürfnissen behinderter Nutzerinnen und Nutzer anpassen. Beispiele sind etwa ein Vorlese-Programm ('Screenreader'), welches visuelle Inhalte bzw. ganze Webseiten für blinde Menschen vorliest, oder eine Mundmaus, mit welcher Tetraplegikerinnen und Tetraplegiker einen Rechner bedienen können. Zudem profitieren von barrierefreien Websites insbesondere auch ältere Nutzerinnen und Nutzer, die zwar bereits gewisse Einschränkungen aufweisen, jedoch noch nicht in den entsprechenden Statistiken dazu erscheinen.

Barrieren vermeiden – statt später teuer abbauen

Barrierefreiheit entsteht in Web-Projekten jedoch nicht zufällig. Vielmehr müssen die entsprechenden Anforderungen möglichst früh in einem Projekt eingebracht und in allen Phasen der Realisierung berücksichtigt werden.

Nur durch frühzeitige und kontinuierliche Berücksichtigung von Anforderungen der Barrierefreiheit lassen sich späte Anpassungen vermeiden, die sonst weitaus teurer werden. Leider wird jedoch noch immer bei zu vielen Websites erst nach Launch erstmals daran gedacht, Barrierefreiheit ('Accessibility') zu berücksichtigen. Und dies ist teils auch der Fall bei Web-Angeboten von Bundesämtern, für welche folgende Anforderung verbindlich ist.

Im Falle der Vergabe der Umsetzung von Web-Projekten an externe Dienstleister wie Web-Agenturen sind die betreffenden Anforderungen gleich in die jeweiligen Pflichtenhefte und Verträge aufzunehmen. Die Problematik zu später Berücksichtigung von Barrierefreiheit hat sich mit dem Einsatz interaktiver und dynamischer Technologien auf modernen Websites verschärft. So bestanden vor einigen Jahren die überwiegende Mehrheit von Online-Angeboten noch aus verlinkten, aber an sich statischen Informationsseiten. Bei diesen stellten sich ebenfalls bereits die meisten Themen, wie sie in den internationalen Richtlinien für barrierefreie Webinhalte (Web Content Accessibility Guidelines; WCAG 2.0 des W3C) festgehalten sind.

Zu nennen sind hier zum Beispiel die folgenden Anforderungen:

Alternativtexte für informative oder verlinkte Grafiken
Tastaturbedienbarkeit aller interaktiver Elemente
Korrekte Inhaltsstrukturierung (Überschriften sind im Code als Überschriften, Listen als Listen ausgezeichnet)
Tabellen werden nicht zu Layout-Zwecken eingesetzt, sondern für Daten und sind logisch aufgebaut
Farbkontraste sind ausreichend stark auch für Menschen mit Sehbehinderungen

Die besondere Herausforderung dynamischer Websites

Heute gelangen demgegenüber weit häufiger interaktive und dynamische Elemente zum Einsatz anstelle von HTML-Standardelementen, sogenannte 'Widgets', oder RIAs ('Rich Internet Applications'). Häufig verwendete Komponenten sind etwa Megadropdown-Menus, Registerkarten, Akkordeons oder auch Kalender-Funktionen, die mittels Skriptsprache (vor allem JavaScript) dynamisch neue Inhalte darstellen, ohne dass eine Seite neu geladen werden muss. Diese Elemente (häufig 'Widgets' genannt) können durchaus für alle Nutzerinnen und Nutzer, also auch für Menschen mit Behinderungen, das Nutzungs-Erlebnis (die 'User Experience') verbessern. Es sind jedoch besondere Vorkehrungen zu treffen, damit diese Elemente auch barrierefrei funktionieren, und gerade hier stellen sich die besonderen, neuen Herausforderungen der Accessibility im Internet.

Die typischen Probleme von Widgets betreffen zwei Arten der Nutzung.

Fehlende Tastaturbedienbarkeit: Widgets sind nicht mit der Tastatur bedienbar, wenn dies nicht auf Ebene der Umsetzung (z.B. im JavaScript) sichergestellt wird. Dies verletzt eine Grundanforderung der Barrierefreiheit, schliesst alle Menschen mit motorischen Einschränkungen aus, welche eine Maus nicht bedienen können.
Unzugänglichkeit mit Screenreader: Widgets sind für blinde Screenreader-Nutzerinnen und -Nutzer nicht bedienbar, da diese häufig nicht erfahren, um welche Art von Interaktions-Element es sich handelt (z.B. ein Reiter), was ihr aktueller Zustand ist (z.B. 'nicht ausgewählt') und wie demnach das Funktionsprinzip ist (z.B. dass sich nach Auswählen eines Reiters der nachfolgende Inhalt entsprechend verändert). Dadurch geht die Orientierung verloren, die Funktionalitäten werden unbedienbar. Gleichermassen wird neu auf einer Seite erscheinender Inhalt nicht wahrgenommen, weil der Screenreader dies nicht vermittelt bekommt.

Beide obgenannten Problembereiche werden am besten bereits während der Umsetzung vermieden. Zum einen kann dies erfolgen, indem Entwicklerinnen und Entwickler bei der Implementation sicherstellen, dass alle Funktionalitäten gleichermassen auch mit der Tastatur bedienbar sind. Dies lässt sich auch sehr einfach durch alle Projekt-Beteiligten testen, haben doch die meisten Mitarbeiterinnen und Mitarbeiter in Informatik-Projekten bei der Arbeit (noch) eine Tastatur vor sich stehen.

Zum anderen sollten Widgets mittels WAI-ARIA für die Screenreader-Nutzung fit gemacht werden. WAI-ARIA ('Web Accessibility Initiative' - 'Accessible Rich Internet Applications') ist seit 20. März 2014 empfohlener Standard des W3C, um genau solche Nicht-Standard-Elemente auch für blinde Nutzerinnen und Nutzer auf verständliche Weise anbieten zu können. WAI-ARIA ist eine rein semantische Erweiterung für HTML, die das Layout von Webseiten nicht verändert. Mittels WAI-ARIA können Informationen zu Rollen, Eigenschaften und Zuständen von dynamischen Anwendungen (Widgets) im HTML hinzugefügt werden. Auch hier empfiehlt sich fortlaufendes Testen, was z.B. mit einem kostenlosen Open Source Screenreader erfolgen kann.

Empfehlungen für Web-Projekte

Die folgenden Empfehlungen können massgeblich dazu beitragen, dass in Web-Projekten barrierefreie Internet-Angebote kosteneffizient entstehen können.

Barrierefreiheit gehört ins Pflichtenheft bei Auftragsvergabe: Hier sollte explizit auf die geltenden internationalen W3C-Standards WCAG 2.0 und WAI-ARIA verwiesen werden, damit diese für die ausführenden Web-Agenturen verbindlich werden. Natürlich sollte dies im Rahmen einer Abnahme am Ende auch überprüft werden.
Verankern Sie Barrierefreiheit möglichst früh in einem Projekt: Die Accessibility-Checkliste bietet hier eine gute erste Orientierung. Planen Sie die Anforderungen zur Erreichung von Barrierefreiheit von Beginn weg ein, wie alle anderen umsetzungsrelevanten Projekt-Anforderungen. Die Accessibility-Checkliste 2.0 wurde 2010 im Auftrag des BAKOM erstellt.
Prüfen Sie Styleguides früh auf ausreichende Farbkontraste, um gute Erkennbarkeit von Inhalten auch für sehbehinderte Menschen sicherzustellen z.B. mittels Colour Contrast Analyser.
Nutzen Sie WAI-ARIA im Rahmen der Umsetzung, da alle modernen Webseiten durch diesen neuen W3C-Standard im Hinblick auf die Barrierefreiheit profitieren.
Testen Sie Webseiten selbst fortlaufend: a. mittels Tastatur: Sind alle Funktionen auch mit der Tastatur bedienbar? b. mit dem Screenreader: Sind die Webseiten, insbesondere auch JavaScript-Widgets auch für blinde Menschen verständlich? c. ohne Ton: Sind Multimedia-Inhalte (z.B. informative Videos) auch ohne Ton verständlich, da sie z.B. Untertitel aufweisen?