Verwaltungsdienste für alle
Wie sich Barrierefreiheit praktisch umsetzen lässt
Es gibt den Irrglauben, dass Barrierefreiheit ›nur für Behinderte‹ ist. Barrierefreiheit macht einen Service aber normalerweise für alle Menschen besser.
Man nehme nur Untertitel. Obwohl sie für Gehörlose gedacht sind, ist die Mehrheit der Nutzer*innen gar nicht gehörlos. Viele Leute nutzen Untertitel, wenn sie in der Bahn ein Video gucken wollen, aber ihre Kopfhörer vergessen haben und die Umsitzenden nicht stören möchten. Untertitel helfen auch, wenn das Gehörte eine Fremdsprache ist oder man einen starken Dialekt nicht versteht.
Es gibt auch das Konzept von dauerhaften, vorübergehenden und situationsbedingten Beeinträchtigungen, dem zugrunde liegt, dass wir alle nur zeitweilig nicht behindert sind. Im Laufe der Zeit wird die Mehrheit von uns von bestimmten Designentscheidungen beeinträchtigt werden.
Eine Webseite kann Farben haben, deren Kontrast nicht besonders gut ist. Ein junger, gesunder Mensch wird die Farben im Büro vielleicht gut lesen können. Geht dieser Mensch nach draußen in die Sonne und versucht dieselbe Webseite im hellen Sonnenlicht auf einem blendenden Handybildschirm zu lesen, wird das schwieriger und er ist situationsbedingt beeinträchtigt. Bekommt dieser Mensch eine Augeninfektion, so ist er vorübergehend beeinträchtigt. Wird er älter, könnte er einen Grauen Star bekommen und damit dauerhaft behindert sein. In allen drei Fällen aber hat er ähnliche Probleme mit den Farben der Webseite und ein besserer Kontrast würde helfen.
Barrierefreies Design macht nicht nur Webseiten für alle besser und nutzbarer, das Gesetz verpflichtet in vielen Ländern auch dazu. In Deutschland gibt es nicht nur das Behindertengleichstellungsgesetz, sondern auch die Barrierefreie-Informationstechnik-Verordnung und seit Neuestem auch die ›eu-Richtlinie über den barrierefreien Zugang zu Webseiten des öffentlichen Sektors‹. Die letzten beiden basieren auf den schon seit Jahren bekannten und genutzten Web Content Accessibility Guidelines (WCAG) und letztere besagt unter anderem, dass neue Webseiten ab September 2019 und alte Webseiten ab September 2020 barrierefrei sein müssen.
Gesetze sind gut, aber solche Anforderungen an Barrierefreiheit können auch ein Problem sein. Sie überfordern und führen mitunter dazu, dass häufig gar nicht damit angefangen wird, sich mit dem Thema zu beschäftigen. Barrierefreiheit erfordert spezielles Wissen. So ist die WCAG zu technisch geschrieben und die Anzahl der möglichen Barrieren ist überwältigend.
Die vermeintliche ›Lösung‹ ist häufig, am Ende eines Projektes einfach einen WCAG-Audit zu bestellen und die resultierenden gemeldeten Fehler zu reparieren. Leider führt das zu mehreren schwerwiegenden Problemen.
Einige Fehler kosten sehr viel mehr Zeit und Geld, wenn sie erst am Ende eines Projektes behoben werden. Das Wissen um Barrierefreiheit wird nicht vom ganzen Team geteilt. Und es wird nur in der extremen Situation angewandt, in der man keine Zeit mehr hat und nicht mehr wirklich etwas lernen kann.
Besser ist es, Barrierefreiheit von Anfang an mitzudenken. Die Empfehlungen im Service Manual des Government Digital Service lauten daher:
1. Nutze automatisierte Testwerkzeuge; diese finden zwar meistens nur 20–30% aller Fehler, aber besser man fängt mit den leicht zu findenden Fehlern an
2. Nutze eine manuelle Checkliste; ein guter Anfang ist: a) teste die Seite ohne Maus / nur mit der Tastatur, b) zoome auf 400 %, c) teste mit höherem Kontrast und veränderten Farben, d) deaktiviere die Stylesheets im Browser, e) deaktiviere die Bilder.
3. Nutze verschiedene technische Hilfsmittel: zumindest eine Vorlesesoftware (Screenreader), eine Softwarelupe und Spracherkennungssoftware; alle diese Hilfsmittel gibt es in einer kostenfreien Version.
4. Betreibe Nutzerforschung mit Behinderten; das ist am schwersten, aber liefert den größten Erkenntnisgewinn.
Die Schritte 1 und 2 kann jeder machen. Schritt 3 braucht ein bisschen Schulung und Übung, ist aber einfacher, als viele Menschen glauben. Schritt 4 ist am schwersten. Viele Teams finden es vor allem schwierig, entsprechende behinderte Teilnehmer*innen zu finden.
Ein weiterer Weg zum besseren Verständnis von Barrierefreiheit und typischen Barrieren, die wir mit unserem Design Menschen unabsichtlich in den Weg legen, ist der Einsatz von Simulationen. Das ist zwar kein Ersatz für Nutzerforschung und wird niemals eine Behinderung wirklichkeitsgetreu darstellen, aber Simulationen sind schnell, einfach und kostengünstig. Simulationen können von Browsererweiterungen kommen, wie Funkify, Web Disability Simulator und NoCoffee. Man kann auch physische Dinge nutzen wie spezielle Brillen, Handschuhe und Lupen.
Beim Government Digital Service nutzen wir hierfür sieben verschiedene Profile, die alle unterschiedliche Beeinträchtigungen haben. Für diese Profile haben wir Laptops aufgesetzt, bei denen man sich entsprechend einloggen kann. Dann werden die Simulation für das Profil gezeigt und die Hilfsmittel dieses Profils genutzt. So kann man Webseiten aus der Perspektive verschiedener Beeinträchtigungen erleben. Als Starthilfe haben wir auch ein sehr kurzes ›Minitraining‹ für die Profile erstellt. Was besonders gute Ergebnisse bringt, ist ein ›Profiltest‹:
1. Erstelle ein paar typische Aufgaben für das Projekt.
2. Lade ein ganzes Team für eine Stunde ein.
3. Jedes Gruppenmitglied wählt ein anderes Profil aus.
4. Die Gruppe hat 50 Minuten Zeit, um die Aufgaben in dem gewählten Profil zu bewältigen. Manche Hilfsmittel wie Screenreader und Spracherkennung brauchen etwas Hilfe.
5. Alle schreiben Fehler und Auffälligkeiten auf, die sie finden.
6. In den letzten 10 Minuten teilen alle ihre Erfahrungen und mögliche Fehler mit den anderen.
7. Barrierefreiheitsspezialisten sollten danach ein bisschen Zeit darauf verwenden, die Ergebnisse auszuwerten, denn durch Unkenntnis der Hilfsmittel können sich sonst ›Fehler‹ einschleichen, die gar keine Fehler sind.
Dieses Verfahren ist sehr effektiv und lehrreich. Somit können nicht nur viele Fehler früh gefunden werden, es schärft auch das Bewusstsein und Verständnis des ganzen Teams für typische Barrieren. Und das alles ohne vorheriges spezielles Wissen.
→ Weitere Informationen auf accessibility.blog.gov.uk
———
Anika Henke ist Softwareentwicklerin beim Government Digital Service in London. Sie arbeitet in einem Team, das die britische Verwaltung zu Barrierefreiheit berät.
