Barrierefreies Webdesign – Frontend-Technik und Prüfung
Inhalt
Wie wird meine Website für alle Menschen nutzbar? In diesem Blogartikel wollen wir dir das Thema digitale Barrierefreiheit bzw. Accessibility (oder kurz: A11Y) in Digitalsprech näherbringen. In unserem vorherigen Blogartikel zu dem Thema haben wir beleuchtet, dass barrierefreie Interaktionswege im Netz nicht allein von Seiten der Nutzer mit Behinderung gefordert werden, und warum es ganz grundsätzlich Sinn macht, sich als Website-Betreiber damit zu beschäftigen. Nun soll es im Schwerpunkt um die technischen Aspekte gehen. Bevor wir damit loslegen, werfen wir zunächst einen Blick auf die Menschen, die eben andere Anforderungen an digitale Medien stellen, als das wohl den meisten Menschen, ohne die hier aufgeführten körperlichen oder geistigen Einschränkungen, bewusst ist.
Was bedeutet Barrierefreiheit im Digitalen?
Für die meisten Menschen dürfte die Interaktion mit einer Website oder einer App mehr oder weniger intuitiv verlaufen – eine durchdachte vorherige Konzeption vorausgesetzt. Dieselbe Anwendung bedeutet für eine andere Person unter Umständen größte Komplikationen oder sie ist schlichtweg unbrauchbar, weil sich individuell digitale Barrieren ergeben. Nach rechtlicher Verordnung aus dem Behindertengleichstellungsgesetz sollen „[…] Menschen, die langfristige körperliche, seelische, geistige oder Sinnesbeeinträchtigungen haben…(§ 3)“ nicht nur in den Bereichen Bau und Verkehr (Stichworte: Treppen, Verkehrszeichen u.v.m.), deren typische Barrieren wohl auch Nicht-Behinderten sehr viel geläufiger sind, sondern auch in der digitalen Welt keine Benachteiligung erfahren. So sollen öffentliche Stellen des Bundes die Barrierefreiheit von Websites und digitalen Anwendungen insbesondere bei der Planung und Überarbeitung von digitalen Projekten berücksichtigen (§ 12a BGG).
Welche Behinderungen können zur Barriere in der digitalen Welt werden?
Bei der Berücksichtigung von Barrierefreiheit sprechen wir über die Ebnung von digitalen Zugangswegen. Konkreter geht es um folgende vier Ebenen, in denen sich Hindernisse ergeben können:
Sehen:
- Sehschwächen (häufiges Auftreten im Alter)
- Farbenfehlsichtigkeit
- Blindheit
Hören:
- Schwerhörigkeit
- Gehörlosigkeit
Motorik:
- Verlust von Gliedmaßen
- Eingeschränkte Gelenkbeweglichkeit (z.B. durch Arthrose)
- Eingeschränkte Muskelfunktionen (z.B. durch Lähmungen, Muskelschwund, Muskelentzündungen)
- Bewegungsstörungen oder eingeschränkte Bewegungskontrolle (z.B. Parkinson’sche Erkrankung, Zittererkrankung (Tremor), Dystonien etc.)
Kognition (mentale Funktionen):
- Auch allgemein definiert als Wahrnehmungsprobleme oder Lernschwierigkeiten
- Lese-/Rechtschreibschwäche (Dyslexie/Dysgraphie), Rechenschwäche (Dyskalkulie)
- Down-Syndrom
- Aufmerksamkeitsdefizit-/Hyperaktivitätsstörung (ADHS)
- Autismus
Dieses Video der W3C Web Accessibility Initiative sensibilisiert für einige dieser Einschränkungen und zeigt konkret, wie Barrieren abgebaut werden:
Welche konkreten technischen Barrieren gibt es auf Websites, in Apps oder in anderen digitalen Anwendungen?
Da körperliche und geistige Einschränkungen ein sehr breites Spektrum ausmachen, ist eine vollumfängliche Auflistung aller potenziellen digitalen Barrieren kaum möglich. Folgende Schwierigkeiten, aufgeteilt nach Sinnesbereichen, stellen wohl die häufigsten Probleme in der Interaktion zwischen User und Interface dar.
Visuelle Barrieren:
- Zu geringe Farbkontraste
- Fehlende Skalierbarkeit bzw. zu kleine Schriftgrößen
- Zu geringe Zeilenabstände
- Fehlende Textalternativen zu Bildern, Illustrationen oder Videos
- Fehlende Semantik (fehlende Deklaration von Inhaltstypen für den Screenreader, wie z.B. die klare Definition von h1-hx Überschriften, das Markup von Formularfeldern…)
- Fehlende Navigationsstrukturen (z.B. klare Link-Benennungen, einheitliche Navigationskonventionen, fehlende Bread-Crumb-Navigation u.a.)
- Schlecht lesbare Schriftarten
- Animationen und Pop-Up-Fenster (problematisch für Screenreader)
Auditive Barrieren:
- Fehlende Textalternativen zu Audio-Daten (für Menschen mit Einschränkungen beim Hören)
- Automatisch abspielende Audio-Inhalte (überlagern Screenreader-Informationen)
Motorische Barrieren:
- Fehlende oder eingeschränkte Tastaturbedienbarkeit
- Zu kleine oder zu eng nebeneinander liegende Klickflächen
- Animationen und Pop-Up-Fenster (ggf. problematisch für die Bedienbarkeit)
- Fehlende Semantik (fehlende Deklaration von Inhaltstypen für Assistenzsystem bzw. Tastaturbedienbarkeit)
Kognitive Barrieren:
- Zu komplexe Inhalte (zu lange Sätze, zu viele Fachbegriffe, zu komplexe Bedienung)
Welche technischen Anforderungen gibt es für barrierefreie Websites?
Die Entwicklung barrierearmer oder barrierefreier Seiten beinhaltet eine Vielzahl von Implikationen für die Webentwicklung. Wie du oben bereits gelesen hast, gibt es kaum einen Bereich des Webdesigns, der nicht potenzielle Barrieren aufweisen kann. Im Frontend-Team unserer Internetagentur haben wir die daraus resultierenden Anforderungen in drei wesentliche Themenbereiche aufgeteilt, die für Quick-Wins in der Accessibility besonders wichtig sind:
Farben und Kontraste nach BITV
Für alle sehenden User gehören Farben essenziell zur Komposition einer jeden digitalen Anwendung. Die BITV (siehe Mini-Glossar am Ende) schreibt vor, dass Farben nicht allein als Mittel zur Informationsübermittlung dienen dürfen. D.h. eine farblich hinterlegte Klickfläche sollte mit einem Text kombiniert werden. Für normalen Text soll ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund gewährleistet sein. Für große Texte wie Überschriften (ab 24 px) genügt das Verhältnis 3:1 zwischen Vordergrund- und Hintergrundfarbe. Betroffen sind neben klickbaren Flächen und Texten auch die Umrandungen von Eingabefeldern. Hiervon ausgenommen sind nebensächliche Textinformationen als Teil eines Bilds oder eines Logos, das Logo selbst oder dekorative Grafiken.
Nach der strengeren Priorität II (BITV 2.0 Priorität II entspricht WCAG 2.0 Stufe AAA) gelten hier bereits die geforderten Kontrastverhältnisse 7:1 (normaler Text zu Hintergrund) bzw. 4,5:1 (Großer Text zu Hintergrund).
Zur Prüfung des Kontrasts gibt es unterschiedliche Tools. In den Developer Tools von Chrome ist eine integrierte Lösung auffindbar über den eigenen Color-Picker. Hier die Beschreibung zur Ermittlung des Kontrastverhältnisses unter web.dev. Eine Alternative bietet Colorable, ein simples, aber sehr praktisches Web-Tool, das zudem über einfache Regler eine schnelle Anpassung des gewünschten Farbwerts mit Echtzeit-Veränderung des Kontrastwerts bietet.
Einen Komplettcheck bietet der Dienst Checkmycolours, der die gesamte Website nach verwendeten Farbwerten scannt und direkt problematische Farbverhältnisse auflistet.
Barrierefreie Navigation und Bedienung
Die Navigation muss zunächst sicherstellen, dass eine aussagekräftige Reihenfolge aller Inhalte gewährleistet wird. Das bedeutet, dass eine Navigation via Screenreader verständlich und mit der Tastatur bedienbar ist. Es braucht einen verständlich sicht- bzw. erfassbaren Fokus auf dem aktuell gewählten Tastaturfokus und für sämtliche Links gilt, dass diese klar benannt werden, so dass deren Zweck und Linkziel für jede Art der Bedienung verständlich wird. Zudem ist unbedingt auf die Konsistenz der Navigation und eine einheitliche Bezeichnung über den gesamten Webauftritt hinweg zu achten.
Sogenannte ARIA-Attribute (Abkürzung für Accessible Rich Internet Applications) unterstützen neben bereits existierenden und teils auch bereits im Sinne der Barrierefreiheit nützlichen HTML-Markups die Semantik von Elementen, um allen voran für blinde und sehbehinderte Menschen eine bessere Bedienung zu ermöglichen. Sie sorgen dafür, dass sämtliche Interaktionsmöglichkeiten vom Screenreader bestmöglich interpretiert und wiedergegeben werden können. Dabei gilt jedoch als erste Regel, dass ein natives HTML immer den Vorrang haben soll, um die Rolle, den Zustand oder die Eigenschaft eines Elements zu deklarieren, bevor es zum Einsatz von ARIA-Attributen kommt. Mehr zu ARIA-Attributen: https://developer.mozilla.org/de/docs/Web/Accessibility/ARIA
Bei der Desktop-Navigation per Tastatur muss sichergestellt werden, dass sich mittels der Tastatur alle Menüs und Untermenüs öffnen lassen. Hierbei ist wichtig, dass der Fokuspunkt auch bei Menüs mit mehreren Ebenen funktioniert. Wird die Anwendung mit einer Maus bedient, sollten sich Flyout-Menüs verzögert schließen, um Menschen mit motorischen Einschränkungen zeit zum Reagieren zu geben. Sowohl für Maus- als auch für die Touch-Bedienung sind ausreichende Freiräume bzw. Abstände rund um die Klickflächen nötig, um eine fehlerfreie Interaktion zu gewährleisten. Für die Bedienung per Screenreader gilt, dass Aufbau, Struktur und aktueller Zustand hörbar sein müssen.
Hier ein Beispiel für eine mobile Navigation eines Burger Menüs, bedienbar via Tastatur und lesbar durch einen Screenreader:
Barrierefreiheit für Formulare
Besonders kritisch im Rahmen der digitalen Barrierefreiheit sind Formulare, da sie elementar sind, um Registrierungen, Anträge, Bestellungen oder vergleichbare Prozesse online durchführen zu können. Sämtliche service-relevanten Vorteile des Internets münden oftmals in der Nutzung eines Formulars. Aus diesem Grund verdienen Formulare ein besonderes Augenmerk bei der Umsetzung barrierefreier Web-Auftritte.
Folgende Kriterien finden hier u.a. Berücksichtigung:
- for-Attribut –> verbindet bzw. verknüpft die Beschriftung mit dem Input-Feld
- Input-Typ –> dient der Klassifizierung der Inhaltsart wie bspw. Text, Datum, Zahl, Telefonnummer
- Pflichtfelder –> unabdingbar für jedes Formular ist ein Hinweis auf Pflichtfelder, zumeist mit einem * deklariert
- Fehlermeldung –> bei fehlenden oder falschen Eingaben sollte eine deutliche Fehlermeldung pro Feld erscheinen mit konkreten textbasierten Hinweisen, was zu verbessern ist (eine farbliche Markierung genügt nicht)
- Focus –> das jeweils gerade gewählte Formularfeld sollte farblich hervorgehoben werden, um eine eindeutige Navigation zu ermöglichen und zur Vereinfachung der Tastaturbedienung
- ARIA-Attribute –> helfen zusätzlich als Markups und erhöhen die Verständlichkeit für Screenreader; so z.B. bei der Beschriftung eines Input-Felds:
- Autofill –> dient dem automatischen Ausfüllen von entsprechend klassifizierten Feldern. Aktuelle Browser bieten die Möglichkeit zur Speicherung der eigenen Adressdaten und somit die Option zum Autofill eines Formulars, dessen Werte entsprechend gepflegt wurden.
- Hilfetexte / Hinweise –> dienen der klaren Verständlichkeit eines Formulars durch Erklärungen oberhalb des jeweiligen Feldes, wie bspw. der Veranschaulichung des richtigen Eingabeformats
Barrierefreie interaktive Web-Komponenten
Auch für sämtliche interaktive Web-Komponenten – wie u.a. Web-Applikationen, Modals, Slider, Tooltips oder Akkordeons – gehen wir grundsätzlich so vor, dass folgende Aspekte der Barrierefreiheit berücksichtigt werden:
- HTML semantische Struktur
- Tastaturbedienbarkeit
- ARIA-Attribute
- Screenreader
Am Beispiel der Akkordeons:
Zur Strukturierung und besseren Übersichtlichkeit setzen wir bei einer Vielzahl unserer Projekte Akkordeons ein. Der Tastaturfokus liegt dann zunächst immer beim ersten Element. Mit dem nächsten Sprung folgt der nächste Akkordeon-Punkt, der mit Enter aufgeklappt wird. Sollte wiederum ein Link in einem aufgeklappten Inhalt enthalten sein, so wäre dieser Link in Folge das nächste wählbare Element, bevor das nächste Akkordeon-Item fokussiert wird.
Im Code wird dem aufgeklappten Element die Klasse „is-active“ zugewiesen. Die Sichtbarkeit eines Akkordeon-Inhalts sollte nicht mit dem Markup „display:none“ erfolgen, sondern stattdessen mit „visibility: visible | hidden“ oder „opacity: 1 | 0“
Wie kann die BITV-Konformität geprüft werden?
Diese Tools und Methoden helfen standardmäßig bei der technischen Überprüfung jeder Website:
- W3C Validator
- Einsatz der gängigsten Browser (wie Chrome, Edge, Firefox, Safari…)
- Einsatz unterschiedlicher Devices (Windows vs. Mac, Desktop vs. Smartphone vs. Tablet, Android vs. iPhone…)
- Ggf. optional noch ein Lighthouse-Test via Chrome DevTools
Für die Überprüfung der Konformität einer Website im Sinne von BITV und WCAG sind folgende Tests zusätzlich zu empfehlen:
- Die oben genannten Tests inkl. des Lighthouse Accessibility Tests
- BITV-Test wie z.B. https://webtest.bitv-test.de/
- WCAG Test z.B. https://wave.webaim.org/
- Schnelltest bzw. Checkliste von Aktion Mensch
- Test von verschiedenen Screenreadern* auf unterschiedlichen Betriebssystemen (mobil und Desktop)
- Optional: Test durch qualifizierte Prüfer bzw. Prüfstellen
*Anmerkung zu Screenreadern:
Die drei Screenreader NVDA (Open-Source für Windows), JAWS (kostenpflichtig für Windows) und VoiceOver (auf Apple Geräten vorinstalliert) machen zusammen 92% der eingesetzten Screenreader aus laut einer Umfrage von https://webaim.org/projects/screenreadersurvey8/. Bei mobilen Geräten kommt zudem noch das vorinstallierte TalkBack auf Android Geräten häufig zum Einsatz.
Mini-Glossar und Links
Viele Abkürzungen oder Begriffe werden teils synonym innerhalb des Themas Barrierefreiheit verwendet. Hier die wichtigsten:
Du hast allgemeine Fragen zu Barrierefreiheit oder konkrete technische Probleme?
Titelbild: Photo by Jukan Tateisi on Unsplash
