Barrierefreie Webseiten – Umsetzung der Richtlinien

Barrierefreie Webseiten – Umsetzung der Richtlinien

Nachdem ich im ersten Beitrag auf die Richtlinien zum gestalten barrierefreier Webseiten eingegangen bin, geht es in diesem Artikel um die Umsetzung der Richtlinien.

Wer also Teil 1 noch nicht gelesen hat und sich mit diesem Thema noch nicht auseinandergesetzt hat, sollte das idealerweise jetzt nachholen.

Prüfung auf Barrierefreiheit

Bevor man seine Webseite barrierefrei gestalten will, wünscht man sich ein Tool, welches eine Prüfung auf Barrierefreiheit vornimmt. Idealerweise als Ergebnis mit einer Liste all jener Teil der Webseite, wo etwas zu tun ist.

IDI Web Accessibility Checker

Ein Tool ist der IDI Web Accessibility Checker. Die Ergebnisse verleiten allerdings etwas zum Schmunzeln – da ist ganz offensichtlich ein automatischer Übersetzer am Werk.

So lautet eine Empfehlung beim ersten Aufruf des Tests für unsere Startseite wie folgt:

2.4 Schiffbar: Geben Sie Möglichkeiten, um Nutzer zu navigieren, Inhalte zu finden und bestimmen, wo sie sind.

oder

Prüfung 8: img Element können eine lange Beschreibung.

Wenn man die verlinkte Beschreibung anklickt, kommt man damit am Ende schon zurecht, aber etwas „Phantasie“ kann bei mancher Beschreibung nicht schaden. Ansonsten sind die angewandten Richtlinien für die Prüfung und die Schritte zur Behebung inklusive Beispielen recht gut.

TotalValidator

Den TotalValidator gibt es in einer Basic und einer Pro Version. Die Basic Version kann nur eine einzelne Seite testen und bietet weniger Möglichkeiten bei den Einstellungen zur Prüfung.

Den TotalValidator gibt es als Desktop-Programm für unterschiedliche Betriebssysteme als auch als PlugIn für Firefox und Chrome. Das Firefox PlugIn brachte ich nicht zum Laufen, die Windows-Desktop Variante funktioniert einwandfrei.

Die Ergebnisse (getestet habe ich nur die Basic-Version, evtl. liefert die Pro Version mehr) sind bei weitem nicht so detailliert, als sie es beim IDI Web Accessibility Checker sind. Trotzdem ist es damit möglich, die ein oder andere Accessibility Lücke aufzudecken.

Ein Vorteil des TotalValidator ist, dass man eine Seite auch lokal (localhost) testen kann, was während der Umsetzung der Richtlinien durchaus hilfreich sein kann.

WAVE – Web Accessibility Evaluation Tool

Ein Online-Tool, welches sehr übersichtliche Ergebnisse liefert, ist WAVE. Das Tool überzeugt durch inline Kommentare und liefert so einen raschen Überblick zur Barrierefreiheit.

WAVE - Online Tool zum prüfen auf Barrierefreiheit
WAVE – Online Tool zum prüfen auf Barrierefreiheit

Ein sehr empfehlenswertes Tool für einen Einstieg ins das Thema mit Hinweisen, warum es eine entsprechende Richtlinie gibt und wie man sie erfüllen kann.

Color Contrast Analyser

Der Color Contrast Analyzer prüft nicht eine gesamte Webseite auf WCAG Konformität, sondern zeigt an, ob der Kontrast zwischen 2 Farben ausreichend ist, um die entsprechende WCAG Richtlinie zu erfüllen.

Somit kann man feststellen, ob die Webseite auch bei Farbblindheit problemlos gelesen werden kann.

Barrierefreiheit - reicht der Kontrast aus?
Barrierefreiheit – reicht der Kontrast aus?

Dieses Programm ist als Desktop-Variante für Windows und Mac erhältlich.

Umsetzung der Richtlinien

Nachdem man anhand der verschiedenen Tools zum Prüfen der eigenen Seite ein Gefühl dafür bekommen hat, was Barrierefreiheit bedeutet, kann es an die Umsetzung gehen.

Wir wollen das im Rahmen dieses Artikels mit einem Praxisbeispiel – der eXperinox Startseite – tun und den ein oder anderen Fail beheben.

Sprache setzen

Beginnen wir mit den einfachsten Dingen zuerst. Jedes HTML Dokument benötigt einen entsprechende Sprachangabe. Diese hat in unserem Fall gefehlt:

<html xmlns=“http://www.w3.org/1999/xhtml“ xml:lang=“de“ lang=“de“>

Alternativen Text für Images anbieten

Jedes Bild benötigt einen beschreibenden Text. Außer für Bilder wie Logos, die keinen „echten“ Inhalt bieten. In diesem Fall muss man ein leeres ALT-Attribut angeben.

Unsere Screenshots auf der Startseite haben bisher allesamt den gleichen Text beinhaltet, der SEO optimiert gedacht war. Dieser hat der Prüfung nicht standgehalten, weil er zu lang gewesen ist. Und zum anderen sollte der ALT-Text beschreiben, was auf dem jeweiligen Bild zu sehen ist. Das habe ich nun geändert und einen korrekten, das Bild beschreibenden Text bei den Screenshots verwendet.

Ein gewisses Problem stellt unser „Hamburger“ Menü dar, welches verwendet wird, wenn die Breite des Browserfenster einen gewissen Wert unterschreitet. Damit verbessern wir vor allem die Navigation auf Smartphones.

"Hamburger" Menü
„Hamburger“ Menü

Dieses haben wir nämlich nicht als IMG umgesetzt, sondern rein über CSS. So sieht die entsprechende Zeile im HTML wie folgt aus:

<a class=“hamburger“ href=“#portal-menu“></a>

Schlecht für WCAG, weil wir so keinen Link-Text zur Verfügung stellen können. Das A-Tag kennt ein solches nicht und ein IMG, welches über das ALT-Attribut einen Text liefern könnte, haben wir auch nicht. Damit können Screenreader keinen Text zur Beschreibung für den Link zum Menü auslesen.

Über folgenden Trick löse ich das Problem:

<a class=“hamburger“ href=“#portal-menu“><span class=“hidden“>Dropdown-Menü</span></a>

Ich liefere also einen Text, den ich über CSS ausblende. Zumindest der TotalValidator zeigt sich damit zufrieden.

Nach eine kurzen Recherche gibt es zu diesem Problem auch empfohlene Lösungen: Using CSS to hide a portion of the link text.

Video

Wir haben auch ein Video auf unsere Portalseite. Der TotalValidator liefert uns leider keinen Hinweis auf fehlende Barrierefreiheit.

Zur Wiedergabe verwenden wir das jPlayer PlugIn und wir haben auf Barrierefreiheit keine Rücksicht genommen und ich weiß deshalb, dass wir z.B. nirgends eine Beschreibung zum Inhalt des Videos haben. Es würde den Artikel sprengen, nun näher auf unser „Videoproblem“ einzugehen und nach einem alternativen Videoplayer für unsere Seite zu suchen. Das Thema sehen wir uns später einmal näher an.

Entsprechende Richtlinien für Audio und Video sind unter WCAG Time Based Media zu finden.

Ein sehr guter Überblick zur Barrierefreiheit von Videos und Links zu entsprechenden Playern ist unter Accessible media player resources and demos (in Englisch) zu finden.

Navigation

Sehbehinderte Menschen können optische Zusammenhänge auf einer Webseite nicht entsprechend wahrnehmen. Ein Beispiel ist eine entsprechende Anordnung von Elementen zu einem Menü oder die Zuordnung von Tabs zu einer Tab-Gruppe.

Nach den WCAG Richtlinien ist für solche Elemente erforderlich, dass diese Zusammenhänge durch entsprechende Tools oder eine textuelle Beschreibung dem Anwender klar gemacht werden.

Auf unserer Portalseite betrifft das die Top-Navigation, welche durch eine Liste implementiert wurde.

WAI-ARIA definiert für diesen Zweck sogenannte Rollen, welche sowohl Gruppen (Menü, Tab-Gruppe) als auch entsprechende Elemente (Menü-Item oder Tab-Panel) kennzeichnen können. Für ein Menü wird die Rolle menu oder menubar, für ein Menü-Item die Rolle menuitem verwendet.

Eine sehr gute Beschreibung zur Angabe der notwendigen Rollen zu einem Menü ist in diesem Artikel (englisch) zu finden.

Wenn nach der Definition der Rollen jedes role Attribut vom TotalValidator bemängelt wird, so kann das am Document Type liegen. Wenn man z.B. <!DOCTYPE html PUBLIC „-//W3C//DTD XHTML 1.0 Transitional“ „http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“> verwendet, so kommt es zu diesen Fehlern. Eine Änderung in <!DOCTYPE html> schafft Abhilfe.

Das war nur ein erster Einblick in die Barrierefreiheit einer Webseite. Wer sich bisher bei der Erstellung seiner Webseite nicht darum gekümmert hat, wird auf viele Dinge stoßen, die es entsprechend anzupassen gilt.

Ich hoffe, für dieses Thema entsprechend sensibilisiert zu haben und freue mich auf Rückmeldungen und Erfahrungen bei der Gestaltung barrierefreier Webseiten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.