Validierte Netzseiten

zur Übersicht

Diese netten Validierungs-Bildchen sind ja schon auf der Eingangsseite zu sehen. Eine erfolgreiche Validierung besagt, daß die jeweilige Seite aus formal korrektem HTML und CSS besteht. Vereinfacht gesagt sind das die Formatierungssprachen, aus denen meine gesamte Netzseite (und viele andere) aufgebaut ist. Was hat es damit nun auf sich? Worin besteht der Nutzen einer Validierung? Und was sollen diese Bildchen?

Zunächst mal ist HTML eine Art Computersprache. Genau wie in einer natürlichen Sprache (wie etwa Deutsch) gibt es eine Art Grammatik, obwohl Computersprachen im allgemeinen eine sehr viel genauer definierte Grammatik aufweisen. Der Satz "Aufkleben den mir Briefmarken" ist aus mehreren Gründen grammatisch falsch. Man könnte ihn in mindestens acht Varianten berichtigen, die alle grammatisch korrekt wären:

1. ich klebe die Briefmarken auf.
2. ich klebe die Briefmarke auf.
3. die Briefmarken kleben auf mir.
4. die Briefmarke klebt auf mir.
5. ich klebe auf den Briefmarken.
6. ich klebe auf der Briefmarke.
7. die Briefmarken kleben mich auf.
8. die Briefmarke klebt mich auf.

Alle acht Sätze sind grammatisch korrekt, besagen aber verschiedene Dinge. Die letzten vier sind inhaltlich offensichtlich Quatsch, auch wenn sie grammatisch korrekt sind. Aber die ersten vier Sätze wären sinnvoll, und zwischen dem ersten und dem zweiten Paar besteht ein großer Unterschied. Hätte ich gleich einen grammatisch richtigen Satz gebaut, der meine gewünschte Bedeutung korrekt ausdrückt, dann müßte man nicht herumraten, was wohl gemeint ist.

Wenn ein Browser nun auf fehlerhaften HTML-Code trifft, dann wird er versuchen zu erraten, was der Autor wohl gemeint haben mag. Wie an obigem Beispiel zu sehen, kann das aber völlig danebengehen, zumal Browser nicht unbedingt intelligent genug sind, um die Sätze 5 bis 8 als Unsinn zu erkennen. Vielleicht rät ein Browser ja halbwegs richtig, aber vielleicht auch nicht. Ein anderer Browser oder auch eine künftige Version desselben Browsers mag etwas völlig anderes raten. Wenn also falscher Code etwa im Internet Explorer korrekt dargestellt wird, heißt das noch gar nichts.

Noch schlimmer, wenn Autoren ihre Seiten für den IE "optimieren", d.h. schlechten Code so schreiben, daß wenigstens der IE aus dem Datenmüll noch etwas halbwegs Ansehnliches zusammenraten kann. Das wiederum bringt unbedarfte Anwender dazu, auf den IE zu setzen, wenn andere Browser "nichts taugen" - anstatt den Autoren auf seine Verantwortung hinzuweisen. Das befördert dann direkt das Microsoft-Monopol. Ich selber habe keinerlei Microsoft-Produkte auf meinem Rechner, ich würde sie nichtmal geschenkt haben wollen. Als Netzautor "optimiere" ich deswegen nicht für den IE, sondern ich will, daß jeder Browser meine Seite anzeigen kann. Wenn andererseits ein Browser dermaßen fehlerhaft ist, daß er nicht einmal korrektes HTML anzeigen kann, dann ist das nicht mein Problem. Betroffene Anwender sollen entweder das Programm aktualisieren oder falls das nicht geht, ein anderes verwenden.

Wenn der Code aber korrekt ist, dann vergrößert sich eben die Chance, daß auch exotische oder künftige Browser die Seite brauchbar anzeigen. Und zwar ohne daß irgendetwas "optimiert" werden muß. Vieles, was oft dem Browser als Fehler zugeschrieben wird, hat seine Ursache in fehlerhaftem HTML-Code. Wenn man gleich richtigen Code schreibt, braucht man auch keine Workarounds, d.h. ich spare damit Zeit. Nebenbei erleichtert man damit auch den Suchmaschinen ihre Arbeit. Deren Interpreter können nämlich durch fehlerhaften HTML-Code auch verwirrt werden. Das führt dazu, daß man die Seite schlechter finden kann, und das ist ja nicht im Sinne einer öffentlich lesbaren Netzseite. Ich schreibe also Code, der den formalen Regeln entspricht, und das prüfe ich dann mit dem kostenlosen W3C-Validator. Die Leute vom W3C sind nämlich diejenigen, die Sachen wie HTML genau definieren.

Diese niedlichen Bildchen haben für den normalen Anwender natürlich keinen Wert. Solange die Seite brauchbar angezeigt wird, interessiert ein Anwender sich nicht dafür, ob der HTML-Code korrekt ist. Ich will damit aber andere Netzautoren darauf aufmerksam machen, daß man sich darum kümmern kann. Professionelle Webdesigner sollten das natürlich sowieso wissen, Validierung ihres Codes sollte ganz normaler Teil ihrer Arbeit sein. Wenn so ein Profi vom Standard abweicht, dann wird er gute Gründe dafür haben und das nicht aus Schlampigkeit tun. Aber die Privatleute wissen oft nicht einmal, daß Validierung überhaupt existiert. Es ist übrigens kein Verlaß auf irgendwelche HTML-Editoren. Ganz im Gegenteil, die verzapfen oftmals den schlimmsten Code. Deswegen schreibe ich alles von Hand.

Selbst mit Lynx, einem reinen Textbrowser ohne Mausunterstützung, kann man meine Seite vernünftig lesen, wobei die Bilder dann durch die jeweiligen Beschreibungstexte ersetzt werden. Was sich mit Lynx lesen läßt, sollte eigentlich auch für spezielle Behinderten-Software geeignet sein. Das betrifft dann bereits den Bereich der Barrierefreiheit, geht also über formal korrekten HTML-Code hinaus. Korrekter Code ist notwendige Vorbedingung für Barrierefreiheit, aber das allein reicht nicht: Man kann schließlich auch in korrektem HTML Seiten schreiben, die für Sehbehinderte überhaupt nicht nutzbar sind.

Ich optimiere zwar meine Seiten nicht extra auf Barrierefreiheit, aber ich achte darauf, nicht unnötig Steine in den Weg zu legen. Daß ich auf Farben verzichte, hat nur ästhetische Gründe. Aber kontrastreiche Darstellung, Vermeiden von blinkendem Zeug, eindeutige Kennzeichnung von gelesenen, nicht gelesenen und aktiven Verweisen sind auch für Nichtbehinderte hilfreich. Meine Layout-Tabellen sind linearisiert immer noch lesbar, meine Bilder haben immer eine hinterlegte Beschreibung (im alt-tag), die Schriftgrößen sind stets relativ und nicht absolut (und bei der Indexseite gibt es eine Textversion, da die Bilder nicht skalierbar sind), ich verzichte auf Flash-Navigation, ich verzichte auf Javascript usw., weil das bei meiner Netzseite nutzlose Spielerei wäre, die obendrein auch noch Behinderte ausschlösse. Nur weil jemand nicht sehen kann, heißt das ja nicht, daß er nicht denken kann. Daher geht es mir hier auch darum, Netzautoren darauf hinweisen, an solche Leser zu denken. Mehr zum Thema Barrierefreiheit findet man auf der Netzseite barrierefreies Webdesign. Meine Netzseite entspricht dem Level A der W3C-Richtlinien zur Barrierefreiheit.