Logo Adobe Certified Expert (ACE) und Adobe Certified Instructor (ACI) für Adobe Acrobat

29. Dezember 2005

Barrierefrei – Schritt 1: valides Markup

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.

Grenzen von Expression Engine

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.

Templates und Kategoriebezeichnungen anpassen

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.

Markup-Fehler bei der Content-Pflege

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:

  • vergessene schließende Tags
  • Tippfehler in Tags
  • vergessene Anführungen
  • vergessene Attribute (ich vergesse zum Beispiel gerne das title= )
  • und noch vieles mehr

Und zu diesen syntaktischen Stolperfallen kommen jetzt noch die Anforderungen der Barrierefreiheit:

  • Abkürzungen und Akronyme kennzeichnen
  • Sprachwechsel markieren
  • alle Bilder mit sprechenden alt-Attributen versehen
  • alle Links mit guten und ausagekräftigen title-Attributen versehen
  • Zitate über <q>, <blockquote> oder <cite> kennzeichnen
  • Code mit mit <code> oder <samp> hervorheben
  • Kurz: jeder logische Abschnitt soll sein passendes Markup bekommen

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.

Hilfsmittel in Mac OS X

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.

Fazit:

Valid xhtml 1.0 Transitional

Valid CSS!

[Valid Atom 1.0]

Ausgabe des Reports Cynthia Says - Web Content Accessability Report. Er brachte ein valides Ergebnis.

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

Trackbacks

  1. Trackback-URL: http://www.lisardo.biz/trackback/154/UN9H63Pk/

Kommentare

  1. Um den unvermeidlichen Kommentarspam zu verringern, musste ich leider einige Hürden einbauen: zunächst muss eine gültige E-Mailadresse eingegeben werden, die allerdings auf der öffentlichen Webseite nicht erscheint. Ausserdem kann der Kommentar erst nach dem Aufrufen einer eigenen Vorschau-Seite gespeichert werden. Sie müssen ausserdem einen Namen angeben (Vorname, Nachname, Spitzname oder Pseudonym).
Dieser Eintrag kann nicht mehr kommentiert werden.

Aktuelle Seminartermine:

Seminar: PDF-Prüfung und Korrektur mit PitStop
28. November 2008, Skill GmbH in Ismaning, bei München Mehr Infos …
Acrobat und PDF im Verlag
01. Dezember 2008, Skill GmbH in Ismaning, bei München Mehr Infos …
Werbebanner erstellen mit Adobe Flash
04. Dezember 2008, Skill GmbH in Ismaning, bei München Mehr Infos …

Seminarkalender abonnieren

Icon einer Kalenderdatei
Seminarkalender als .ics-Datei: Für Kalenderanwendungen herunterladen (alle Systeme)
Icon einer Kalenderdatei
Seminarkalender für iCal: Kalender abonnieren (nur Mac OS X)