Barrierefreies Webdesign – Frontend-Technik und Prüfung

Barrierefreies Webdesign – Frontend-Technik und Prüfung

 

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:

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

PGlmcmFtZSB3aWR0aD0iNzQwIiBoZWlnaHQ9IjkwMCIgc3JjPSJodHRwczovL3d3dy55b3V0dWJlLW5vY29va2llLmNvbS9lbWJlZC8zZjMxb3VmcUZTTT8iIGZyYW1lYm9yZGVyPSIwIiBhbGxvd2Z1bGxzY3JlZW4gYWxsb3c9ImF1dG9wbGF5OyBlbmNyeXB0ZWQtbWVkaWE7IHBpY3R1cmUtaW4tcGljdHVyZSIgdGl0bGU9IlczQyBXZWIgQWNjZXNzaWJpbGl0eSBJbml0aWF0aXZlIChXQUkpIC0gV2ViIEFjY2Vzc2liaWxpdHkgUGVyc3BlY3RpdmVzICI+PC9pZnJhbWU+

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:

Barrierefreiheit im Webdesign

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.

Colorable Farben und Kontraste für BITV Check
Web-Tool für die Überprüfung von Kontrastverhältnissen:

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:

Barrierefreie Navigation

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:
    ARIA Attribut Formular
  • 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:

  1. HTML semantische Struktur
  2. Tastaturbedienbarkeit
  3. ARIA-Attribute
  4. 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:

*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:

A11Y - Accessibility
    

Die Kurzform bzw. das Numeronym „A11Y“ steht für Accessibility und damit zu deutsch übersetzt für nichts anderes als Barrierefreiheit. Allerdings mit dem Unterschied, dass der deutsche Begriff Barrierefreiheit die nicht-digitale wie auch die digitale Welt meint, während A11Y ein Projekt ist, das sich ausschließlich der Web Accessibility widmet.

Unter https://www.a11yproject.com/checklist/ findet sich eine Checklist, die auf 15 Bausteine unterteilt wichtige Aspekte für einen barrierefreien Webauftritt auflistet.

BGG - Behindertengleichstellungsgesetz
    

§ 12a zur „Barrierefreien Informationstechnik“ im Behindertengleichstellungsgesetz (ursprünglich datierend aus dem Jahr 2002) adressiert speziell öffentliche Stellen des Bundes, die dazu aufgefordert sind, die Benachteiligungen von Menschen mit Behinderung auch im digitalen Umfeld zu beseitigen. Einige Anpassungen aus dem Jahr 2018 basieren auf der Europäischen Richtlinie 2016/2102 über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen.

BITV - Barrierefreie Informationstechnik-Verordnung
    

Die Barrierefreie Informationstechnik-Verordnung resultiert aus dem oben genannten Behindertengleichstellunggesetz. Zuletzt wurde sie im Mai 2019 aktualisiert und ist in der aktualisierten Fassung BITV 2.0 in Kraft.

Mehr dazu auf der Seite der Bundesfachstelle Barrierefreiheit.

WAI - Web Accessibility Initiative
   

Die W3C WAI ist eine Initiative, die sich für internationale Standards in der Barrierefreiheit im Internet einsetzt und die für die Erstellung der WCAG (siehe nächster Tab) verantwortlich ist. Die Empfehlungen der W3C WAI haben keine gesetzliche Verbindlichkeit, werden jedoch als maßgeblich für die jeweiligen Gesetzgebungen übernommen.

https://www.w3.org/WAI/

WCAG - Web Content Accessibility Guidelines
    

Die WCAG sind die technologische Basis für die deutsche BITV Adaption. Sie werden bereits seit 1999 fortentwickelt und gingen aus dem W3C (World Wide Web Consortium) hervor.

Zur vollständigen WCAG-Dokumentation: https://www.w3.org/TR/WCAG21/

 

Du hast allgemeine Fragen zu Barrierefreiheit oder konkrete technische Probleme?

Kontakt mit PPW aufnehmen

 


Titelbild: Photo by Jukan Tateisi on Unsplash