Zur Startseite

Barrierefreiheit Teil 2

 Hinter Türchen Nr.19 gibt's weitere Tipps und Infos für eine barrierefreie Website...

 

 Wahrnehmbar, Bedienbar, Verständlich und Robust  - Testen und validieren

Das Projekt steht vor dem Abschluss – die Seite ist aufgebaut, Erweiterungen sind installiert, das Template ist fertig und es stehen die letzten Tests an. Eigentlich sollte die Seite barrierefrei sein, und nicht mehr viel zu tun bleiben, denn die Planung ist hier mehr als die halbe Miete und der Joomla! Core ist eine gute Grundlage, auch wenn er nicht perfekt ist. Der Knackpunkt sind eingesetzte Erweiterungen, die vielleicht noch eingesetzt wurden.

Aus Sicht des Dienstleisters heißt Barrierefrei: Die Erfolgskriterien der WCAG 2.0 zu Konformitätsstufe AA sind erfüllt. Dies muss nachweisbar sein. Dass neben den rein formalen Aspekten auch oft Empathie mitspielt und einem sagt, ob etwas barrierefrei ist oder dazu beiträgt - das ist wieder was anderes, das kann sozusagen nicht verrechnet oder verifiziert werden.

Das Joomla Accessibility Team (JAT) erarbeitet derzeit Checklisten, die dabei helfen werden, eine Seite auf Barrierefreiheit zu testen. Die Checklisten sind noch in Überarbeitung, und werden ziemlich umfangreich. Als Vorgeschmack gehen wir ein paar Punkte durch. Zum Trost für den Aufwand kann man sich sagen, dass dies auch schon eine wichtige und erfolgversprechende SEO-Maßnahme ist. Denn die wichtigsten Besucher der Seite sind blind und honorieren die Maßnahmen zur Barrierefreiheit: Die Suchmaschinen!

Erste Überprüfung:

  • Es gibt nichts auf der Seite, das sich bewegt oder Hintergrundgeräusche macht, die man nicht stoppen kann. Slider, Musik-Clips, Animierte Gifs … das alles darf durchaus sein, muss sich nur vom Benutzer anhalten lassen. Warum? Hintergrundmusik würde den Screenreader übertönen, sich bewegende Elemente stören Menschen mit einem Aufmerksamkeitsdefizit (und nicht nur diese).
  • Links im Text und Steuerelemente sind nicht nur über ihre Farbe erkennbar.
  • Kein Element blinkt so schnell, dass es epileptische Anfälle auslösen kann.
  • Farbkontraste, Schriftgröße – alles was die Wahrnehmbarkeit betrifft ist im Template umgesetzt.
  • Es gibt keine Layout-Tabellen im Template, das ist eine wohlbekannte Forderung und seit Jahren verpönt. Es gibt allerdings ein Schlupfloch. Man kann die Tabelle mit role=“none“ ausgezeichnen, um wenigstens dem Screenreader mitzuteilen dass er diese nicht beachten soll. Aber das bleibt unter uns!

Nun testen wir die Robustheit sämtlicher Seitentypen: Homepage, Blogs (Achtung: Navigationen), Formulare, einzelne Artikel - einfach alle Arten von Seiten. Und vor allem Seiten und Formulare von integrierten Erweiterungen. Denn bei Erweiterungen, wenn sie nicht selbst geschrieben sind, weiß man nicht ohne Weiteres ob sie sich an die Regeln für das barrierefreie Webdesign halten. Eine Erweiterung, die quer schießt kann die Barrierefreiheit der ganzen Seite zerstören!

Der NU-Validator

Das Tool dafür ist der NU Validator https://html5.validator.nu/. Dieser Validator ist noch recht neu und im Beta-Stadium – er wird den bekannten Html-Validator ablösen. Die Ausgabe ist hier besser und übersichtlicher und auch genauer. Dankenswerterweise übernimmt der Validator auch gleich die Kontrolle der vorgeschriebenen alt-Texte und der Gliederung.

Das aXe-Tool

Es sollte schon zu Beginn beim Erstellen des Templates eingesetzt worden sein, um bei der Template-Erstellung auf Fehler aufmerksam zu machen. Nun kann man es auch nochmal zur Kontrolle verwenden. Zum Beispiel darf nicht passieren, dass auf <h1> gleich <h3> folgt – aXe macht auch darauf aufmerksam.

Durchtabben

Ein weiterer Test ist sehr einfach durchzuführen, aber aufwendig: Die Keyboard Nutzung. Es braucht nichts weiter als einen Finger um sich von Anfang an durch eine Seite zu tabben.

  • Der Focus muss beim Start immer auf dem ersten anklickbaren Element der Seite stehen.
  • Es muss möglich sein, direkt zum Content oder direkt zum Menü zu springen (Bypass).
  • Der Focus  muss immer erkennbar sein (blauer Rahmen auf blauem Button zum Beispiel ist unsichtbar)
  • Der Focus darf nicht gefangen werden, so dass ein Benutzer nicht mehr aus einem Fenster herauskommt. Modalfenster testen! Vorsicht bei Bildergalerien! Sie sind gerne Fokus-Fallen.

Screenreader NVDA

Formulare müssen auch für Blinde ausfüllbar sein. Besonders interessant und lehrreich ist es dabei, einen Screenreader, hier den kostenfreien NVDA http://meinnvda.de/  einzusetzen. Die Seite vorlesen zu lassen ist für Sehende erst einmal ein Schock und hört sich ziemlich schrecklich an. Wie jedes Tool braucht es eine Gewöhnungs- und Lernzeit, um die Funktion zu verstehen. Als Alternative kann man natürlich mit dem Inspector des Browsers arbeiten und alles nachprüfen. Oder sich die Seite ohne css anschauen (Im Browser Ansicht: Stil = keiner ). Es ist aber nicht dasselbe. Man sieht ein „x“ und es ist dem Sehenden klar, dass das ein Symbol zum Schließen ist. Aber was sagt hier der Screenreader? „mal“. So wie in der Schule: 2 x 2 = 4.

Formulare

Formulare sind besonders wichtig. Denn wenn ein Formular von einem Blinden ausgefüllt werden soll, muss dieser jederzeit wissen wo er sich befindet und in welches Feld er schreiben soll. Oder er muss wissen, wo eine clientseitige Validierung nicht geklappt hat. Beim falschen Passwort zum Beispiel. Das einfachste und allgemeinste Formular auf Webseiten ist das Suchformular, ein einziges Eingabefeld.  Es muss ein Hinweis da sein, der dem Blinden sagt: Dies ist ein Eingabefeld für einen Suchbegriff. Es kann ein <label> sein oder <legend> oder ein placeholder, aber es muss irgendetwas da sein und es muss sich eindeutig auf das Eingabefeld beziehen.

Gerne werden labels versteckt. Das ist möglich mittels CSS. Keinesfalls darf es aber mit display:none ausgeblendet werden, denn dann sieht es auch der Screenreader nicht. In Joomla ist das schon gut gelöst, aber wenn Formulare mit einer fremden Erweiterung generiert werden, ist Vertrauen gut, aber eine Kontrolle ist besser.

ARIA-attribute

Ein besonderes Thema ist die Prüfung, ob die ARIA-Attribute gesetzt sind – und zwar richtig gesetzt. ARIA-Attribute werden per JS gesetzt, wenn sich der Zustand eines Screens ändert. Damit ermöglichen sie es, auch dynamische Inhalte zu zeigen und generell JavaScript/jQuery in Webseiten zu verwenden. Bevor es diese ARIA (Accessible Rich Internet Applications) gab, durften barrierefreie Seiten kein JS verwenden. Daher kommt das Vorurteil, dass barrierefreie Seiten langweilig sind, was lange auch gestimmt hat. Innerhalb des Joomla Core ist es im Moment (3.8.2) im Frontend weitgehend korrekt – wie es bei externen Erweiterungen aussieht, muss im Einzelfall getestet werden.

Content-Pflege

Wenn Redakteure den Content pflegen ist es nun Zeit, sie zu schulen. Dabei müssen sie in Bezug auf Barrierefreiheit vor allem folgende Themen verstehen:

  • Was bedeuten alt-Texte bei Bildern? Wann braucht man sie, wann nicht?
  • Warum ist eine konsistente Gliederung wichtig? Warum darf man nicht einfach eine Zeile als  <h5> markieren, obwohl das layout von h5 gerade so schön passt?
  • Wie kann eine Datentabelle erstellt werden, so dass sie barrierefrei ist?
  • Warum sollten Links in einem Content nicht doppelt vorkommen (indem man z.b. zuerst das Bild verlinkt und dann den Titel?
  • Warum sollen Abkürzungen ausgezeichnet werden? (Weil der Screenreader bei WHO einfach „who“ vorliest (hu) und nicht “World Health Organization “ wie bei <abbr title="World Health Organization">WHO</abbr>)
  • Warum sollen Zahlen mit Tausenderpunkten und Telefonnummer in Dreierblöcken geschrieben werden?

Man kann Redakteure ruhig einmal mit einer Screenreader-Sitzung konfrontieren und sie ihre Texte abhören lassen.

Nun schleichen sich natürlich im Lauf der Zeit immer wieder Fehler ein. Es sollten auch Barrierefrei-Audits in größeren Intervallen eingeplant werden.

Nachsatz

Ich bin der Meinung, dass es keine Barrierefreiheit im Web geben kann. Formal ja – man kann alle Punkte der Checkliste abgehakt haben. Aber irgendein Mensch wird immer irgendeine Form der Behinderung haben, die nicht ausgeglichen wurde.

Es wird wohl keiner gleich eine Anzeige wegen Diskriminierung erstatten, wenn mal ein Farbkontrast nicht stimmt. Wahrscheinlich reagiert Google da wesentlich rachsüchtiger als Menschen mit Behinderungen, wenn es mal einen Fehler gibt. Nur bei Formularen, da versteht man keinen Scherz. Niemand soll eine teure Reise falsch buchen, nur weil das Formular nicht barrierefrei ist.

Unser Ziel soll es sein, Barrierefreiheit selbstverständlich zu machen. So wie es selbstverständlich geworden ist, ohne Layout-Tabellen zu arbeiten, so sollen auch alle Erfordernisse der Barrierefreiheit ohne weitere Überlegung berücksichtigt werden.