Sauberer Code?
Warum sauberer Code?

Sie werden jetzt sicher fragen, warum Sie sich um sauberen Code scheren sollten. Sie benutzen doch einen WYSIWYG-Editor, um sich gerade nicht um den Code kümmern zu müssen. Sauberer Code ist aber kein Selbstzweck oder akademischer Zeitvertreib von HTML-Puristen, sondern dient dazu, dass Ihre Seiten von der größtmöglichen Anzahl von Nutzern auch dargestellt und genutzt werden können.

Die gängigen professionellen Entwicklungswerkzeuge wie Dreamweaver oder Golive halten Autoren zwar von gröbsten Fehlern fern, und die Redaktionssysteme sind auf dem Weg der Besserung. Ein Fehler kann aber auch darin bestehen, bestimmte Dinge zu unterlassen. So gehört das Einsetzen von alternativen Texten zu Bildern (alt-Attribut des img-Tags) zum guten Ton und dient Besuchern, die keine Bilder sehen können und daher eine Vorlesesoftware benutzen. Zudem ist das alt-Attribut mittlerweile in HTML 4 zwingend vorgeschrieben.

Begehen Sie aber nicht den Fehler vieler Entwickler und hinterlegen Sie jede noch so unwichtige Bilddatei mit einem alternativen Text oder einem redundanten title-Attribut. Ein abschreckendes Beispiel sind die vielen Seiten, wo dem Benutzer hundertfach alt="spacer.gif" vorgelesen wird. Daher sollten Bilder, die eine rein gestalterische Funktion haben, mit einem leeren alt-Attribut (alt="") »versteckt« werden.

Bessere Performance durch sauberen Code

Sauberer Code bringt durch die Vermeidung von Fehlern und mißbräuchlich eingesetzten Elementen wie vielfach verschachtelten Layouttabellen eine bessere Performance sowohl für den Server als auch für den Anwender. Moderne Browser haben zwar eine gewisse Fehlertoleranz, und die meisten W3C-Empfehlungen enthalten Vorgaben zum Umgang mit Fehlern. Trotzdem kann eine hohe Anzahl von Syntax-Fehlern den Aufbau einer Seite dramatisch verlangsamen oder im Ernstfall eine Darstellung ganz verhindern.

Im Interesse Ihrer Besucher sollten Sie Ihre Seiten also zumindest stichprobenartig durch die mittlerweile zahlreich vorhandenen Prüfprogramme testen lassen. Viele dieser Tools können Fehler aufzuspüren, die behinderte Menschen von der Nutzung Ihrer Seiten ausschließen.

Spannend ist die Gewichtung der gefundenen Fehler: aus Sicht der Nutzer gibt es sicher 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 »und« (&), die man häufig in den URLs dynamisch generierter Seiten findet. Streng genommen ist dies ein Fehler, da diese Ampersands zum Codieren von Sonderzeichen benötigt werden und somit selbst codiert werden müssen (&).

Wichtig wird valider Quelltext, 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 haben und 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: es ist nahezu unmöglich. Wenn beides ansatzweise validiert sind eine ganze Reihe möglicher Fehlerquellen ausgeschlossen.

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

Fehlersuche mit Validatoren allein reicht nicht

Neben der syntaktisch richtigen Umsetzung ist die Semantik von Bedeutung. Validierung bedeutet zunächst einmal nur eine Grammatik-Prüfung, ob die formalen Regeln von HTML und CSS eingehalten wurden. Es ist allerdings möglich, ein valides Dokument zu schreiben, das inhaltlich oder strukturell kompletter Unsinn ist. Prüfverfahren wie das zur BIENE 2006 untersuchen daher, ob Elemente entsprechend ihrer Bedeutung eingesetzt wurden. Auch der umgekehrte Fall, d. h. ob Inhalte einer Seite mit den dafür vorgesehenen Elementen ausgezeichnet wurden, wird geprüft.

Diese Tests bewahren durch ihre Beschränkung auf die Kontrolle des Sourcecodes nicht davor, dass Sie Ihre Seiten mit tatsächlichen Benutzern testen sollten. Bestimmte Farbkombinationen können von Menschen mit Farbenblindheit oder anderen Sehbehinderungen nicht wahrgenommen werden, so dass unter Umständen Ihre sorgfältig gestaltete Navigation unsichtbar wird. Kein Programm der Welt ist in der Lage nachzuvollziehen, ob die Struktur Ihrer Site von lernbehinderten Menschen verstanden wird. Hier helfen also nur Tests mit echten Nutzern.