Toll, wenn der Validator keinen einzigen Fehler anzeigt. Dabei muss eine Webseite gar nicht unbedingt validieren. Der Validator liefert lediglich ein Indiz für eine sauber angelegte Webseite. Trotzdem kann eine Seite mit zwanzig Fehlern besser codiert sein als eine Seite, die keinen einzigen Fehler liefert. Es kommt darauf an, die Ergebnisse des Tools richtig zu lesen.

Manchmal habe ich das Gefühl, dass einige Leute Qualität im Sinne von Webstandards an den Fehlermeldungen eines Validators messen. Der Validator hilft einem kein Stück weiter, wenn man sich nicht die Mühe macht, nachzusehen, welche Elemente die Fehler verursachen.
In Weblogs, die sich mit Webstandards beschäftigen, gibt es regelmäßig fragende, zweifelnde oder auch hämische Kommentare der Art: »Aber diese und jene Seite validiert nicht!« Das muss sie auch nicht. Zumindest nicht in jedem Fall.

Die kleinen Dinge

Ja sicher, kleine Fehler sollte man beseitigen. Ein Tag, der nicht geschlossen wird? Ein falsches Attribut in einem Element? Ein fehlendes alt-Attribut in einem Bild? Kann der zuständige Webwoker in vielen Fällen schnell beheben. Sollte er auch. Klare Sache.

In dieser Hinsicht bin ich immer noch von Googles Startseite irritiert. Google kümmert sich um Webstandards, das sieht man an vielen anderen Stellen. Aber warum muss die Startseite so schlampig programmiert sein? Im body stehen "bgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b alink=#ff0000", im Quelltext stehen Elemente wie <center> und <font>. Es wäre nun wirklich kein großer Akt, dort ein wenig aufzuräumen.

Nicht meine Schuld

Dann gibt es viele Fälle, in denen der Webworker einfach keinen Einfluss auf den Inhalt hat. Werbung ist so ein Fall. Skripte, die aus irgendwelchen Gründen auf der Webseite laufen müssen. Der Standardista sieht so etwas natürlich natürlich nicht gerne, schließlich gibt das der Webseite einen kleinen Makel. Aber er hat keinen Einfluss darauf. Also ignorieren und weiter.

Anders sieht es beim oft zitierten User-Content aus. Da hat man also ein hübsches CMS eingerichtet. Alles läuft fehlerfrei, bis der erste Redakteur sich an dem WYSIWYG-Editor versucht und horrenden Blödsinn verzapft – soll heißen: er produziert unsinnigen HTML-Code. Darüber kann man sich beschweren, aber mittlerweile sollte jedes große, bekannte, gute CMS in der Lage sein, solchen Content so aufzubereiten, dass es verdammt schwierig wird, unsauberen HTML-Code auszugeben.

Ich glaube nicht, dass es narrensichere Systeme gibt. Aber selbst, wenn der Editor an sich dazu neigt, fehlerhaften Code auszugeben, kann der Webworker in vielen Fällen einen Filter hinzuschalten, der HTML besser im Griff hat als der Editor oder der CMS-eigene Filter. Der HTML-Purifier läuft per Plugin zum Beispiel mit MODx, Drupal, Wordpress, Joomla oder Symfony. Außerdem stehen jede Menge anderer Filter zur Verfügung.

Der Zeit voraus

Bei den Webkrauts gab es neulich den Fall mit dem html5doctor.com. Natürlich mäkeln die meisten Validatoren an dieser Webseite herum. Schließlich nutzt der Doktor html5-Elemente wie <nav>, <header> oder <section>, die noch nicht offiziell zum Standard gehören. Insofern sind manche Webseiten eben ihrer Zeit voraus – und validieren deshalb nicht.

Ebenso verhält es sich mit neuen Attributen, die zur Barrierefreiheit beitragen. Pflichtfelder zum Beispiel werden gerne mit einem Stern * gekennzeichnet. Das reicht aus für alle User, die den Stern sehen können; Screenreader jedoch lesen entweder »Stern« vor – oder gar nichts. WAI ARIA schafft Abhilfe und bietet das Attribut aria-required="true" für das input-Element an. Das können die ersten Browser/Screenreader bereits verarbeiten – und auch der blinde Nutzer weiß somit, dass er hier was eintippen soll. Freilich sind noch nicht alle Screenreader soweit. Aber auch wenn der Validator meckert, ist es sinnvoll, denn das Attribut hilft jetzt schon einigen Nutzern. Daneben gibt es auch noch aria-invalid, aria-controls, aria-expanded und einiges mehr.

Minimal störend

Dann kommen noch die – subjektiv gesehen – absoluten Kleinigkeiten zum Zuge. Ein nicht umgewandeltes & ist nun kein Weltuntergang. Ein anderes Beispiel sind mehrfach gesetzte ids, zum Beispiel automatisch vergeben durch das CMS. Wenn ich nun die Wahl habe, drei Stunden zu investieren, um entweder ein CMS zu bändigen, das an irgendeiner Stelle leicht fehlerhaften Code erzeugt, oder die Zeit lieber in Inhalte, Text, Informationsarchitektur und Navigation zu stecken, dann lasse ich die kleinen Fehler lieber links liegen und kümmere mich um die wichtigen Dinge.

Null

Der umgehrte Fall übrigens: Wenn der Validator null Fehler ausspuckt, ist das natürlich eine schöne Sache. Auch hier muss man einen Blick unter die Haube werfen, um die Qualität beurteilen zu können. Man erreicht auch mit semantisch fragwürdigen Konstrukten wie <span class="ueberschrift h1"> oder einem Tabellen-Layout 0 Fehler. Null Fehler alleine sagen nicht besonders viel aus.

Was ich damit sagen will: Nur zu bemängeln, dass eine Webseite x Validierungsfehler hat, ist nicht zielführend. Es gibt richtig schlimme Fehler und es gibt belanglose Fehler. Man muss sich schon die Mühe machen und genau hinsehen.