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

PGlmcmFtZSB3aWR0aD0iNzQwIiBoZWlnaHQ9IjkwMCIgc3JjPSJodHRwczovL3d3dy55b3V0dWJlLW5vY29va2llLmNvbS9lbWJlZC8zZjMxb3VmcUZTTT8iIGZyYW1lYm9yZGVyPSIwIiBhbGxvd2Z1bGxzY3JlZW49InRydWUiIGFsbG93PSJhdXRvcGxheTsgZnVsbHNjcmVlbiIgdGl0bGU9IlczQyBXZWIgQWNjZXNzaWJpbGl0eSBJbml0aWF0aXZlIChXQUkpIC0gV2ViIEFjY2Vzc2liaWxpdHkgUGVyc3BlY3RpdmVzICI+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 und auf der Website BITV Lotse.

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