Digitale Barrierefreiheit: Umsetzung im Web

Teil 3 unserer Blogreihe zu digitaler Barrierefreiheit: Wie setzt man Barrierefreiheit im Web um? Darauf gehen wir hier genau ein. Wir klären wer in einem Team welche Aufgaben hat, welche Arbeitsabläufe es gibt und welche Tools zum Testen genutzt werden können.

Beispielhafte Team- und Aufgabenverteilung

• Product Owner
  • Gibt die zu beinhaltenden Features vor.
  • Integriert digitale Barrierefreiheit in die Definition of Done.
• UI/UX Designteam
  • Kann gut zwei Drittel aller möglichen Fehler bereits im Designprozess vermeiden.
  • Wählt eine Typografie, die gut lesbar ist und bei der sich die Buchstaben gut unterscheiden lassen.
  • Nutzt Farben mit starken Kontrasten.
  • Achtet bei Verwendung von Icons darauf, dass diese auch durch Text erklärt werden.
  • Sorgt für eine barrierefreie Nutzerführung.
  • Kennt und nutzt barrierefreie UI-Komponenten.
  • Dokumentiert Entscheidungen zur Barrierefreiheit.
  • Kommuniziert die getroffenen Entscheidungen an das Entwicklungsteam.
• Entwicklungsteam
  • Muss die barrierefreie Nutzbarkeit sicherstellen.
  • Sorgt für saubere HTML-Syntax.
  • Setzt die richtigen Attribute im HTML.
  • Nutzt ARIA-Attribute, wenn erforderlich.
  • Gewährleistet die Tastaturbenutzbarkeit.
  • Führt Barrierefreiheits-Checks mit spezialisierter Software durch.
• Content-Creation-Abteilung
  • Verantwortlich für barrierefreie Inhalte.
  • Setzt Alternativ-Texte für Bilder.
  • Erstellt Untertitel für Videos.
  • Setzt die passenden Sprachauszeichnungen (DE / EN usw.) in Texten.
  • Erstellt barrierearme Dokumente.
• Testing-Team
  • Erfüllt wichtige Beratungsfunktion.
  • Testet digitale Anwendungen mit assistiven Technologien und prüft Mobil/Desktop-Darstellung.

Fazit: Digitale Barrierefreiheit ist Teamarbeit - nur wenn alle mithelfen, gelingt es.

Der Testprozess

Um die Barrierefreiheit einer Webseite, Releases oder neuer Features zu testen, sollte man immer die folgenden vier Schritte durchlaufen:

1. HTML validieren
2. (Teil-)automatisierte Tests durchführen
3. Manuell testen
4. Mit assistiven Technologien testen

1. HTML validieren

Wie startet man nun also mit dem ersten Blick unter die Haube?

Je nach Art der Website, welche gebaut wird, kann man das HTML bereits lokal in der Entwicklung mit dem NPM Paket HTML Validator auf korrekte Semantik testen.

Bei Live-Websites kann das HTML mit dem W3C Markup Validation Service validiert werden.

Tipp: Um das HTML bei lokalen Seiten ohne Node zu validieren, kann man jederzeit den Quelltext im Browser anzeigen lassen (bei Firefox zum Beispiel mit der Tastenkombination "Strg + U"), diesen kopieren und dann beim W3C Markup Validation Service einfügen und testen.

2. (Teil-)automatisierte Tests

Vor allem für Websites, die ohne typisches CMS lokal entwickelt werden, gibt es verschiedene Möglichkeiten, automatisierte Tests einzurichten und durchzuführen. Da es sich dabei aber um ein Thema handelt, das ein gewisses Entwicklungs-Know-how voraussetzt, lassen wir das an dieser Stelle bewusst aus. Am Ende dieses Artikels findet sich noch ein Link mit weiterführenden Informationen.

Viele der Fehler, die das automatische Testen gefunden hätte, werden auch von teilautomatisierten Tools gefunden und spätestens beim manuellen Testen kann man alle Fehler korrigieren - das Auslassen der vollautomatischen Tests hindert einen also nicht daran, eine BFSG-konforme, barrierefreie Website zu bekommen.

Sobald die automatisierten Tests durchlaufen (oder übersprungen) sind, kann man teilautomatisiert mithilfe von verschiedenen Browser-Plug-Ins testen. Nicht jedes Tool findet alle, geschweige denn die gleichen Fehler. Dadurch ergänzen sich die Tools gegenseitig. Mit folgenden drei Tools findet man in etwa 50% der üblichen Fehler:

• Zur Chrome-Extension von Arc-Toolkit
• Zur Chrome-Extension der Axe-DevTools (auch für Firefox verfügbar)
• Zu den Browser-Extensions von Wave

Die Anwendung der Tools dauert jeweils nur ein paar Sekunden, somit ist mit wenig Aufwand bereits viel geprüft.

3. Manuelle Tests durchführen

Nachdem das HTML sauber ist und die automatisierten Tests sowie Browsertests fehlerfrei waren, ist der nächste Schritt das manuelle Testen.

Ein kostenloses Tool für manuelle Tests ist das Accessibility Insights Assessment Tool. Mit dieser Chrome-Extension kann man jede Seite testen und die Ergebnisse dabei dokumentieren. Das Tool leitet den Nutzer dabei Schritt für Schritt durch die für WCAG-Konformität notwendigen Schritte und das dokumentierte Ergebnis lässt sich zudem auch noch ansehnlich exportieren. Leider ist man was Teamarbeit angeht mit diesem Tool etwas eingeschränkt, da die Ergebnisse nur im Browser lokal zwischengespeichert werden. Für mehr Struktur und Teamarbeit empfehlen wir daher CAAT (kostenpflichtig) oder das BITV-Web-Tool (kostenfrei für private Zwecke):

• Zum Tool von CAAT
• Zum Tool der BITV

4. Tests mit assistiven Technologien

Viele Menschen mit Einschränkungen nutzen assistive Technologien, um Websites zu bedienen. Die WCAG setzt auch fest, dass eine Website erst dann konform ist, wenn sie mit assistiven Technologien bedienbar ist. Daher muss auch mit assistiven Technologien getestet werden, idealerweise mit Hilfe von Nutzern, die diese Technologien täglich verwenden.

Gängige assistive Technologien:

• Screenreader

  Apples MacOS hat von Haus aus VoiceOver, welches sich mit der Tastenkombination CMD + F5 starten und stoppen lässt.
  Windows dagegen benötigt Software von Drittanbietern wie NVDA oder JAWS.
  Bei Linux-Nutzern mit GNOME-Desktop-Umgebungen wie zum Beispiel openSuse, Ubuntu oder Fedora ist der Screenreader ORCA von Haus aus integriert.

  Mit dem Screenreader sollte man testen, ob

  • jedes Element und jede Überschrift lesbar ist.
  • man jeden Link und jede Landmarke ansteuern kann.
  • (WAI)-ARIA korrekt eingesetzt wurde.
  • man Input-Felder ausfüllen kann.
• Sprachsteuerungen

  Testen mit Voice Control (macOS) oder Voice Access (Windows). Diese Tools erlauben es, dass gesprochene Befehle vom System ausgeführt werden. Mit ihnen sollte man nun testen, ob:

  • jede Funktion ansteuerbar ist.
  • Links, Schaltflächen und interaktive Elemente aktivierbar sind.
  • Texte in Formulare eingegeben werden können.

  Zum systematisieren von Tests gibt es ein vorgefertigtes Template:

  • Zum Test-Template für Sprachsteuerung (englisch)
• Bildschirmlupen

  Bei MacOS zu finden in den Systemeinstellungen unter „Bedienungshilfen“. Bei Windows 10 und 11 zu finden in den Systemeinstellungen unter „Erleichterte Bedienung“. Die Lupe lässt sich bei Windows auch mit der Tastenkombi „Windows und +“ aktivieren, sowie mit „Windows und Esc“ deaktivieren.

  Damit sollte nun geprüft werden, ob:

  • Texte und Bilder bei mindestens vierfacher Vergrößerung noch lesbar und nicht verpixelt sind.
  • Elemente einheitlich angezeigt werden.
  • keine Elemente andere überlagern.

  Zum systematisieren von Tests gibt es ein vorgefertigtes Template:

  • Zum Test-Template für Bildschirmlupen (englisch)

Wenn man all das geschafft hat, sollte man nun alle noch offenen Baustellen der getesteten Website genau kennen und beseitigen können.
Letztendlich wichtig ist es aber die Kriterien der WCAG zu erfüllen, damit man für das kommende BFSG gewappnet ist. Wenn Sie mehr zum BFSG erfahren wollen, haben wir hier einen ausführlichen Beitrag für Sie geschrieben.

Danksagung

Für diesen Beitrag wurden wir sehr von einem Artikel von Gehirngerecht.digital beeinflusst. Vielen Dank für die tolle Arbeit und die Schulung im Rahmen des Rheinwerk-Verlags.

• Zum Originalartikel