Mittlerweile dürfte sich jede Webagentur damit schmücken, barrierefreie Websites zu bauen. Sie machen das sozusagen im Vorbeigehen, ohne Experten zu engagieren, ohne Praxistests mit Betroffenen und ohne großartig Ahnung von BIT-V oder WCAG zu haben – behaupte ich mal, denn viele Websites ob uralt oder nagelneu erfüllen nicht einmal die minimalen Basics, zum Beispiel die Verwendung von HTML-Elementen. Vielleicht greifen einige dieser Agenturen auf mehr oder weniger automatische Testtools zurück – was besser ist als gar nichts zu tun. Grund genug, sich einiger dieser Tools anzugucken und sie hier in lockerer Folge einmal vorzustellen.Ich beginne dort, wo jeder Code-Schreiber anfangen sollte, bei der Validation.
Validatoren
Dirk Jesse hat in seinem Beitrag Alles valide oder was? schon einiges zu dem Thema Validierung gesagt, dem ich nicht viel hinzufügen kann. Dennoch möchte ich das Thema vom Blickwinkel der Barrierefreiheit betrachten.
Im ersten Schritt sollte immer überprüft werden, ob die Seiten validen Code enthalten. Das hilft vor allem dabei, fehlerhafte Tags, Attribute und Werte zu finden,was zu Fehlern in der Darstellung führt.
Valide oder nicht valide – das ist nicht mehr die Frage
Kurioserweise glauben viele Leute, valider Code sei schon barrierefrei. Ergo, nicht valider Code ist eine Barriere. Die letztere Ansicht stimmt heute nicht mehr: Dank HTML5 und WAI ARIA haben sich die Möglichkeiten für barrierefreie Websites entscheidend verbessert. Beide Standards sind allerdings noch nicht verabschiedet und validieren dementsprechend zumindest beim W3C nicht. Es gibt allerdings einen experimentellen HTML5-Validator, der explizit bei der Doctype ausgewählt werden muss, wenn man nicht den neuen Doctype von HTML5 verwendet.
Jeder Code-Leser dürfte aber in der Lage sein, ARIA oder HTML5-Fehlermeldungen von echten Fehlern unterscheiden zu können. Bei CSS3 sieht es ähnlich aus. Ich plädiere stark dafür, stabile Elemente schon heute zu verwenden, weil sie die Benutzerfreundlichkeit und Zugänglichkeit erhöhen. Außerdem wird so Druck auf die Programmierer von Browsern und das W3C ausgeübt, diese Elemente auch zeitnah einzuführen.
Nutzen
Der HTML-Validator stellt zum Beispiel sicher, dass in XHTML alle Bilder einen Alternativ-Text haben. Er kann allerdings nicht beurteilen, ob dieser Text sinnvoll ist oder nicht. Er kann auch nicht sehen, ob jemand HTML für Überschriften verwendet oder sie per CSS gestaltet. div id=“h1″ ist ebenso valide wie „h1″. Die Validierung verhindert allerdings grobe Fehler wie falsche Tag-Attribut-Paare, was kein Browser der Welt korrigieren oder interpretieren kann. Er prüft auch nicht die Trennung von Layout und Struktur, die dank CSS eigentlich Standard sein sollte. Kein Validator der Welt verhindert, dass jemand mit “ “ seine Abstände einstellt oder Absätze über „br“ statt über „p“ erzeugt, das sind typische Artefakte von WYSIWYG-Editoren.
Fazit
Basis barrierefreier Websites ist fehlerfreier Code. Wer seinen Code nicht prüft, riskiert fehlerhafte Darstellung im Browser, was normalerweise einen Rattenschwanz weiterer Probleme nach sich zieht. Der Validator ist allerdings nur der Anfang und nicht das Ende der Testphase. Er schwächelt dort, wo es um semantisch sinnvolle Auszeichnungen geht und hier kommt es auf das Können des Code-Schreibers an.
Einen recht interessanten Artikel dazu gibt es bei Wait till I come. Chris und Remy Sharp diskutieren über die Bedeutung des Validierens, Chris vertritt als Protagonist der Barrierefreiheit im wesentlichen unseren Standpunkt.