Barrierefreie Webseiten in der Praxis

Barrierefreie Webseiten in der Praxis

Kürzlich habe ich mich mit der Theorie und ersten praktischen Schritten in Richtung Umsetzung barrierefreier Webseiten beschäftigt.

Da ich das Thema als sehr wichtig empfinde, habe ich die Umsetzung der Richtlinien für unsere eXperinox Portalseite nun weiter vorangetrieben.

Auf geht’s mit weiteren praktischen Tipps zu barrierefreien Webseiten.

Das verwendete Tool

In Teil 1 der Serie zu Barrierefreiheit habe ich das ein oder andere Tool erwähnt. Im Rahmen der weiteren Schritte in Richtung Barrierefreiheit habe ich immer wieder verschiedene Tools, wie den TotalValidator eingesetzt.

Sehr gut bewährt hat sich WAVE. Das Tool besticht durch seine Einfachheit und die sehr guten Hinweise auf potentielle Probleme samt Markierung des betroffenen HTML Codes in einem eigenen Code-Fenster.

Blocksatz ist nicht gut für Barrierefreiheit
Blocksatz ist nicht gut für Barrierefreiheit

Auch die weiterführenden Links zu den Standards und Guidelines des WCAG sind sehr hilfreich, wenn man die Hintergründe zu den bemängelten Stellen kennen will.

Blocksatz ist ungünstig

Blocksatz gefällt einigen Designern besser, in Bezug auf Barrierefreiheit wird diese aber nicht empfohlen, da er die Lesbarkeit in manchen Fällen durch relativ große Textlücken erschwert. Im obigen Screenshot von WAVE ist genau dieser Hinweis auch zu lesen.

Deshalb habe ich mich im Sinne der Barrierefreiheit gegen den Blocksatz entschieden und alle Texte in linksbündig, Flattersatz abgeändert.

Video und Alternativtext

Für unser Teaser-Video verwenden wir jPlayer. WAVE moniert einen fehlenden Beschreibungstext.

Unsere verwendete Version ist nicht mehr auf dem letzten Stand, weshalb ich zuerst ein Update auf die letzte Version durchziehe. Vielleicht ist das Problem ja dadurch schon behoben – hoffen darf man ja 🙂 .

In der Konfiguration eines Videos für jPlayer kann man einen Titel setzen. Allerdings wird dieser nur für das Video selbst verwendet, aber nicht für das Poster (die Grafik), die vor dem Abspielen des Videos angezeigt wird. Das lässt sich aber einfach umgehen, indem man beim DIV, in welchem der Player läuft, ein Title Attribut ergänzt.

Um die Barrierefreiheit bei der Bedienung des Players generell zu erhöhen, werden in der Anleitung von jPlayer folgende Einstellungen empfohlen: useStateClassSkin auf true und autoBlur auf false setzen. Dadurch soll die Bedienung mit Screenreadern laut Beschreibung verbessert werden.

Wer einen anderen Player verwendet, sollte sich auf jeden Fall mit den Einstellungen seines Players etwas näher auseinandersetzen und etwaige Einstellungen zur Barrierefreiheit beachten.

Unser Registrierungsformular / Login

Das Registrierungsformular zeigt gleich zwei Probleme auf. Das ist zum Einen der „Chroma-Hash“, der bei der Passworteingabe unterstützen soll (indem er farbige Balken anzeigt, wenn man das Passwort eingibt) und das von uns verwendete Security-Image.

Beide Elemente sind nicht barrierefrei und wir sollten uns diese eventuell einmal näher ansehen. Andererseits ist eXperinox selbst nicht barrierefrei, weshalb wir die Registrierung bzw. das Login auch vernachlässigen könnten.

Lessons learned in diesem Zusammenhang: bei der Auswahl von CAPTCHAs auf Barrierefreiheit achten, indem man zum Beispiel akkustische Captchas verwendet.

Screenreader

Um ein Gefühl dafür zu bekommen, wie Seh- und Hörbehinderte eine Webseite mit Hilfe eines sogenannten Screenreaders wahrnehmen, empfiehlt es sich, einen solchen zu installieren.

Thunder Storm

Ich habe den kostenlosen Screenreader Thunder Storm getestet und unsere Portalseite damit aufgerufen. Leider stürzt Thunderstorm unter Windows 10 ziemlich häufig ab. Die Sprachsynthese ist aber wirklich sehr gut.

NV Access

Aufgrund der Abstürze habe ich dann einen weiteren, kostenlosen Screenreader getestet, nämlich NV Access. Leider macht auch dieser seine Probleme und stürzt am Ende der Installation ab. Trotzdem plaudert der Reader munter vor sich hin – die Installation hat also offensichtlich funktioniert und NV Access taucht auch im Symbolmenü auf, wo man viele Einstellungen vornehmen kann.

Die voreingestellte Sprachsynthese eSpeak ist um vieles schlechter und viel holpriger als bei Thunderstorm. In den Einstellungen kann man aber unter Sprachausgabe auf das Microsoft Speech API umstellen – und voila – die Stimme kommt einem bekannt vor. Exakt die gleiche, als bei Thunderstorm.

Der Test mit einem Screenreader

Einen Screenreader zu testen, kann ich trotz der Probleme jedem nur empfehlen!

Für mich war das allerdings ein wenig ernüchternd, da ich so erkennen musste, dass für echte Barrierefreiheit noch einiges zu tun wäre. So fällt sehr schnell auf, dass so einfache Dinge wie ein guter Seitentitel ungemein wichtig bei der Gestaltung einer barrierefreien Webseite sind. Nicht Sehbehinderte mögen  ja gewohnt sein, mit etwas „SEO geschwängerten“ Seitentiteln umgehen zu können, indem man sie einfach ignoriert. Für Sehbehinderte, die sich Inhalte vorlesen lassen müssen, ist das aber wohl mehr als nervig, da sie nur eines wollen: wissen, was sie auf der Seite finden können.

Thunderstorm beinhaltet auch WebbIE – einen eigenen Browser für Sehbehinderte. Dieser liest zum Beispiel auch den ARIA Hinweis zur Navigation (wie zum Beispiel Menu) vor.

Webpage: eXperinox – kostenloses Multiplayer Browserspiel, Fair to play

Menu
Link: Info & Regeln
Link: Die Story
Link: Fair to Play

Das von uns verwendete Plug-In für mehr Datensicherheit für soziale Medien liest sich in einem Screenreader auch alles andere als gut.

Es gibt wirklich einiges zu beachten, wenn man seine Seiten barrierefrei gestalten will. Aber ich bin davon überzeugt, dass das alles halb so schlimm ist, wenn man erst einmal ein gewisses Gefühl dafür entwickelt hat, was man in diesem Zusammenhang beachten muss.

Und ich hoffe, dass ich mit den letzten Artikeln für das Thema sensibilisieren und zum Entwickeln dieses Gefühles etwas beitragen konnte.

Schreibe einen Kommentar

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