accessCast

Am Mikrofon heute Manfred »majo« Heinze, Links zum Selberklicken gibt's wie immer in der Mitschrift.

Auch bei der BIENE 2006 spielt sauberer Code eine Rolle

Der Dreh- und Angelpunkt zu diesem Thema im Prüfverfahren der BIENE 2006 ist:

34. Eine Validierung von Dokumenten, die durch Markup-Sprachen erstellt wurden, ist gegen veröffentlichte formale W3C-Grammatiken möglich.

34.1 Prüfung der DTD

34.2 HTML Prüfung auf Einhaltung der W3C-Spezifikation

34.3 CSS Prüfung auf Einhaltung der W3C-Spezifikation

Ähnliche Vorgaben an die Standard-Konformität der eingereichten Angebote ziehen sich wie ein roter Faden durch das weitere Prüfverfahren. Beispiele sind die Punkte:

14. Layout-Tabellen werden vermieden.

und

30. Inhalt und Layout sind getrennt.

Wie das in der vorigen Folge behandelte label-Element sind diese Punkte hervorragend geeignet, um sich einen schnellen Überblick über die Barrierefreiheit zu verschaffen. So kann man schnell feststellen, ob mehrfach verschachtelte Layout-Tabellen, font-Tags und ähnliches aus der Steinzeit der Webentwicklung verwendet werden. Das schöne daran ist, dass diese Punkte nahezu automatisch abgeprüft werden können.

Ordentliches Fundament oder esoterischer Firlefanz?

Die spannende Frage ist die nach der Gewichtung der gefundenen Fehler. Aus Sicht der Nutzer gibt es ganz bestimmt schwerwiegendere Barrieren als den nicht-validen Quelltext einer Seite oder einer Anwendung. Die Validatoren geben ja schon bei einem einzigen uncodierten Ampersand einen Fehler aus – das sind die kaufmännischen »unds« (&), die man häufig in den URLs dynamisch generierter Seiten findet. Streng genommen ist dies auch ein Fehler, da diese Ampersands zum Codieren von Sonderzeichen benötigt werden und somit selbst codiert werden müssen (&).

Tipp: falls Ihr Redaktionssystem uncodierte Ampersands in URLs ausgibt kann man diese auch serverseitig noch bereinigen – fragen Sie den Sysadmin Ihres Vertrauens.

Wichtig wird valider Quelltext jedoch, sobald die Zugangssoftware ins Spiel kommt. Die Hersteller und Programmierer von Browsern und Hilfsmitteln wie Screenreadern, Sprachsteuerungen etc. müssen enorme Anstrengungen machen, damit ihre Software auch bei groben Schnitzern noch ein verwertbares Ergebnis zurückliefert. Dazu müssen die Programme eine gewisse Fehlertoleranz besitzen und, grob vereinfacht ausgedrückt, auch Mechanismen besitzen, um sich von Fehlern zu »erholen« und mit der Verarbeitung des Quelltextes fortzufahren. Nichts anderes ist mit der etwas holprigen Formulierung in den WCAG 2.0 gemeint, die fordert, dass der Code »eindeutig gelesen« werden kann (»parsed unambiguously«). Quelltext, in denen vorgeschriebene Schlusstags fehlen, Elemente in der falschen Reihenfolge verschachtelt sind oder simple Tippfehler die eindeutige Verarbeitung erschweren, macht den Zugangsprogrammen (den sog. »User Agents«) das Leben unnötig schwer.

Auch aus Sicht der Webentwickler wird es immer wichtiger, valides HTML zu schreiben. Wer schon mal das Vergnügen hatte, die Ursachen von Darstellungsfehlern in Seiten zu suchen, bei denen weder das HTML noch das CSS validierte weiss wovon wir reden: es ist nahezu unmöglich. Wenn beides zumindest ansatzweise validiert hat man eine ganze Reihe möglicher Fehlerquellen bereits ausgeschlossen.

In den Urzeiten der Webentwicklung waren vergessene Schlußtags nicht so tragisch – spätestens am Ende der jeweiligen Zelle in der Layouttabelle war Ende und weitervererbt wurde dort gar nichts. Mit dem Einzug von CSS ins Webdesign gilt dies aber nicht mehr. Hier können sich Style-Angaben schon bei einem vergessenen oder falsch gesetzten Schlusstag quer durch das ganze Dokument vererben. Eine Behebung des Darstellungsfehlers wird erst durch die Reparatur des Quellcodes möglich.

Neben der syntaktisch richtigen Umsetzung ist auch die Semantik von Bedeutung. Validierung bedeutet zunächst einmal nur eine Grammatik-Prüfung, ob die formalen Regeln von HTML und CSS eingehalten wurden. Natürlich ist es möglich, ein valides Dokument zu schreiben, das inhaltlich kompletter Unfug ist. Daher bei der BIENE 2006 unter anderem auch untersucht, ob Elemente entsprechend ihrer Bedeutung eingesetzt wurden. Ebenso wie der umgekehrte Fall, also ob Inhalte einer Seite mit den dafür vorgesehenen Elementen ausgezeichnet wurden, geprüft wird.

Layouttabellen sind passé

Bei diesem Punkt sticht die BIENE fester zu als die ihr zu Grunde liegenden Richtlinien. Die mittlerweile über sieben Jahre alten Zugänglichkeitsrichtlinien für Web-Inhalte 1.0 (WCAG 1.0) sagen zu dem Thema:

»Tabellen sollten verwendet werden, um tatsächlich tabellarische Daten (›Datentabellen‹) zu kennzeichnen. Entwickler von Inhalten sollten es vermeiden, sie für das Seitenlayout zu verwenden (›Layout-Tabellen‹).« (Anm.: Hervorhebung hinzugefügt)

Man beachte das »sollten« und setze es in den historischen Kontext. Zur damaligen Zeit war es tatsächlich kaum möglich, halbwegs ansprechende Designs ohne Layouttabellen hinzubekommen. Es war die Zeit der 3er- und 4er-Browser, die zwar erste Gehversuche in Richtung CSS machten, aber eigentlich alles falsch umsetzten. Diese Zeiten sind nun glücklicherweise vorbei und heutzutage gibt es keinen vernünftigen Grund mehr, neu gestaltete Seiten immer noch mit Layouttabellen und deren ständigem Begleiter, den Leer-GIFs, aufzubauen.

Somit ist es nur folgerichtig, dass in den Prüfschritten der BIENE 2006 nun steht:

14.1 Keine Layout-Tabellen als Seitengerüst

So, das war die achte Ausgabe unseres wöchentlichen Podcasts zum Thema barrierefreies Webdesign. Weitere Meldungen zum Thema der heutigen Sendung finden Sie im Weblog von ›Einfach für Alle‹ unter den Tags BIENE, HTML und Webstandards; die Links gibt‘s wie üblich in der Mitschrift.

Wenn es Ihnen gefallen hat, hören wir uns nächste Woche wieder.