Der erste Schritt auf dem Weg zur Barrierefreiheit ist valides Markup und CSS. Da Blogsoftware generell für gültiges Markup entwickelt wird, erscheint das auf dem ersten Blick einfach. Leider erwies es sich aber als nicht ganz so einfach und ziemlich zeitaufwändig.
Im Großen und Ganzen unterstützt Expression Engine valides Markup recht gut, bis auf eine Ausnahme: die Kommentar- und Kontaktformulare enthalten leider immer ein name="" im <form>-Tag, und das ist in XHTML Strict nicht erlaubt. Da führt leider kein Weg hin: mit Expression Engine ist nur XHTML 1.0 Transition möglich. Ergo musste ich nach etlichen Tests und Versuchen den Doctype für ganze Blog ändern.
Beim Entwurf der Seiten und dem Aufbau der Templates habe ich einigermaßen auf valides Markup geachtet, ohne aber jedesmal penibel zu validieren. Folgerichtig haben sich einige Fehler eingeschlichen: <ul>- und <ol>-Tags, die unter bestimmten Bedingungen keine eingeschlossenen <li>-Einträge hatten, <img>-Tags ohne schließendes Slash und so weiter. Kleine Unachtsamkeiten eben. Leider verfügt Expression Engine über keine speziellen Hilfsmittel dafür: man kann weder ein Template automatisch validieren noch kann man Tools wie Tidy einbinden. Das dürfte aber für die meiste andere Blogsoftware auch zutreffen, leider.
Im Rahmen dieser »Putzarbeiten« bin auch auf eine Firefox Erweiterung gestoßen mit dem Namen »HTML Validator«. Sie basiert auch auf Tidy und soll Markup-Fehler nicht nur anzeigen, sondern auch automatisch ausbessern. Ich bin allerdings noch nicht dazu gekommen, es ausführlich zu testen.
Das ist eigentlich das größte Problem. ecto zum Beispiel schummelt mir immer wieder beim Upload von Bildern Attribute wie border oder hspace / vspace in den <img>-Tag, was natürlich bei XHTML nicht validiert und zudem völlig unnötig ist, da alles über CSS geregelt wird. Leider kann es in der aktuellen Version von ecto nicht abgeschaltet werden (siehe dazu meinen letzten Beitrag zu ecto). Natürlich passieren auch laufend kleine Fehler:
Und zu diesen syntaktischen Stolperfallen kommen jetzt noch die Anforderungen der Barrierefreiheit:
Das wird zu einer echten Sisyphus-Arbeit. Ich glaube, wenn sich barrierefreie Webseiten wirklich durchsetzen sollen, dann benötigen wir passende Werkzeuge dafür. Diese Werkzeuge müssen von sich aus für ein valides Markup sorgen und für die barrierefreien Techniken weitergehende Hilfen anbieten: Kurzbefehle für die wichtigsten logischen Auszeichnungen, automatische Textbausteine für Standardabkürzungen und Akronyme und so weiter. Aber davon sind wir leider noch weit entfernt.
Einige Hilfen lassen sich in ecto konfigurieren. So kann man zum Beispiel eigene Tags anlegen, die automatisch per Klick auf eine Markierung angewendet werden können und damit zumindest die wichtigsten Tags abdecken. Wichtige Abkürzungen können über Typinator verwaltet werden, ein systemweites Programm für Textbausteine, das auch innerhalb von ecto funktioniert.
Aber es bleibt im Moment noch ziemliches Stückwerk und Fummelei.
OK. Viel fehlt nicht mehr, zumindest für diese Seite :-) Obwohl diese automatisierten Accessability-Tests nicht sooo viel aussagen, ist es doch sehr ermutigend …
Von Peter am 29.12 um 20:27 Uhr. Kategorie: HTML-CSS | Barrierefreiheit | Lisardo-intern
Trackback-URL: http://www.lisardo.biz/trackback/154/UN9H63Pk/