LogoLogo

Kaputte Websites

Auf dieser Seite findest Du keine Galerie kaputter Websites (sowas gibt es auch <http://schneegans.de/www-horrorkabinett/>, nur eben nicht hier), sondern meine ganz persönliche Sicht auf diejenigen Dinge, die aus einer Website eine kaputte Website machen. Die Aufzählung ist locker nach absteigendem Haßfaktor sortiert; je weiter oben, desto schlimmer.

Kaputtes HTML

Es ist unfaßbar, wie viele Websites es immer noch nicht schaffen, ihre Seiten in gültigem HTML oder XHTML auszuliefern. Was nicht mal durch den Validator des W3C <http://validator.w3.org/> geht, ist kompletter Ausschuß. Schlicht und ergreifend. Entsprechendes gilt natürlich auch für die Style-Sheets und den Style-Sheet-Validator <http://jigsaw.w3.org/css-validator/>.

Es ist auch keine Entschuldigung, ein Werkzeug (HTML-Editor, Content-Management-System, was auch immer) einzusetzen, das ungültigen HTML-Code erzeugt. Wer als Zimmermann einen Hammer verwendet, mit dem man Nägel nur schief einschlagen kann, wird auch kaum auf Verständnis der Kundschaft hoffen können.

In dieselbe Kategorie fällt es auch, nur solche Fehler im HTML-Code zu korrigieren, die auch beim Ansehen mit dem Internet Explorer auffallen. Klassisches Beispiel: Das Nicht-Abschließen einer Entity mit einem Semikolon (also &szlig statt &szlig;). Im IE sieht man das normalerweise nicht, aber für den Rest der Leserschaft wird der Text dadurch einigermaßen unleserlich gemacht.

Unnütze Barrieren

Ich selbst bin, jedenfalls bisher, nicht behindert und kann auch die buntesten und lautesten Multimediainhalte uneingeschränkt konsumieren. Ich tue das auch gerne; meinen 16-MB/s-DSL-Anschluß habe ich ja auch nicht nur zum Spaß. (Oder gerade deswegen. Wie Du willst.) Das ist aber kein Freibrief, nur aus Jux und Dollerei nicht barrierefreie Webangebote zu gestalten; perfekt ist es dann, wenn ich als Benutzer entscheiden kann, wie viel und welche Multimedia-Dröhnung ich mir geben will. Diese Abhandlung (auf englisch) des Webdesign- und CSS-Papstes Roger Johansson unterstreicht diesen Standpunkt sehr gut, der auch in den folgenden Punkten noch einige Male vorkommt.

Kaputte Titel

Das, was im <title>-Tag des HTML-Head steht, muß aussagekräftig sein. Nicht nur, daß es Titelbalken des Browserfensters erscheint – das wäre halb so wichtig –, nein, das wird auch der Name des Lesezeichens, sollte sich der Leser entscheiden, ein solches zu setzen. Ein Lesezeichen, das auf Homepage oder untitled page zeigt, ist zu nicht allzuviel zu gebrauchen.

Kaputte Rechtschreibung

Ein bißchen Mühe kann man sich schon machen. Jeder vertippt sich mal, und auch beim fünfzigsten Drüberlesen kann man noch einen oder zwei Schreibfehler übersehen. Und ob man jetzt alte Rechtschreibung verwendet oder neue, kann wohl als Geschmacksache gelten. (Ich habe zu diesem Thema schon eine Meinung, aber die tut hier nichts zur Sache.) Bei vielen Websites hat man als Leser aber eher den Eindruck, der Autor habe sich überhaupt keine Mühe gemacht, irgendwie richtig zu schreiben – das finde ich gegenüber den Lesern ausgesprochen unhöflich.

Flash, Javascript & Co.

Flash und Javascript an sich sind natürlich nichts Schlimmes; schlimm wird's halt nur, wenn ohne Flash und Javascript nicht mehr alle Funktionen der Website erreichbar sind. Typischerweise passiert das durch eine Javascript-basierte Flackernavigation ohne statische Alternative, weil ein Formular nur durch Javascript und nicht durch einen „normalen“ Submit-Knopf abgeschickt werden kann oder weil die ganze Site eh nur noch als Flash existiert.

Nun hat aber nicht jeder Javascript eingeschaltet, und so manche etwas komplexere Javascript-Anwendung funktioniert nicht in jedem Browser, und schon gar nicht in jeder Version. Und obwohl die meisten Browser ein Flash-Plugin installiert haben dürften – die meisten sind halt nicht alle. Am Ende sperrt man locker einen Teil des potentiellen Publikums aus, was eigentlich nie im Sinne des Erfinders sein kann. (Warum wollte ich doch gleich eine Website haben? Ach richtig, damit möglichst viele Leute sie nicht sehen können.)

Verschärfend kommt hinzu, daß trickreiche Navigationen, Vorschaltseiten und sonstiges Blendwerk recht zuverlässig gegen Suchmaschinen-Roboter wirken. Und gerade die sind diejenigen „Besucher“, die auszusperren sich eigentlich niemand leisten kann, denn ohne Suchmaschinenindizierung geht eine Website im Netz einfach unter. Nichts kickt eine Website gnadenloser aus dem Google-Index als ein Flash-Intro gepaart mit einer reinen Javascript-Navigation. Hierzu empfehle ich unbedingt die Lektüre des modernen Märchens „Der Suchmaschinen-Robot und der Webdesigner“ <http://www.woodshed.de/dialog-robot.html> von Rainer Kersten; wer's danach noch nicht begriffen hat, ist ein wohl hoffnungsloser Fall.

Kaputte Farben

Eigentlich ist das doch ganz einfach: Wenn ich die Farbe des Hintergrunds angebe, muß ich auch die Farbe des Vordergrunds angeben. Wenn ich ein Hintergrundbild und eine Farbe für den Vordergrund angebe, muß ich auch eine Farbe für den Hintergrund angeben. Wenigstens für den Zeitraum, bis das Hintergrundbild geladen ist, vielleicht auch für den Fall, daß es nicht geladen werden kann. (Vielleicht hat der Leser ja auch einfach das Anzeigen von Graphiken abgeschaltet?)

Sonst kann nämlich beispielsweise Folgendes passieren: Der Autor einer Seite spezifiziert ein dunkles Hintergrundbild und hellen Text, aber keine Hintergrundfarbe. Beim Darstellen der Seite fängt der Browser erst mal mit dem hellen Text an, aber da das Hintergrundbild noch nicht geladen ist, bleibt der Hintergrund standardmäßig weiß – man sieht nichts. Erst wenn (und falls!) das Hintergrundbild geladen wird, sieht man was.

Browserweichen

Auch Browserweichen sind an und für sich nicht schlimm. Man darf sie nur nicht bemerken.

Es kann in Einzelfällen durchaus sinnvoll sein, um bestimmte bekannte Bugs in bestimmten Browsern herumzuprogrammieren und entsprechend abhängig vom User-Agent:-Header unterschiedlichen Code auszuliefern. Man sollte jedoch nicht vergessen, daß dieser Header nicht immer vorhanden ist (mancher Benutzer bzw. Proxy filtert ihn aus Sicherheitsgründen weg), und auch nicht unbedingt wahrheitsgemäß sein muß (Opera zum Beispiel kann man so konfigurieren, daß er sich als Internet Explorer ausgibt).

Browserweichen, die durch bestimmte Browsereigenarten wie die spezielle Art, CSS-Regeln auszuwerten, funktionieren, sind auch nicht viel besser. Spätestens wenn der Internet Explorer 7 weite Verbreitung findet, wird für viele Webdesigner eine Welt zusammenbrechen, weil all ihre Browserhacks auf einmal nicht mehr funktionieren.

Außerdem sollte man sich nie der Illusion hingeben, alle Browser kennen zu können. Was ich wirklich hasse, sind Websites, die mich mit einem Browser wie Opera einfach aussperren, obwohl eigentlich alles funktioniert, kaum daß sich der Browser als IE ausgibt!

Browserspezifischer Code

Manche Leute machen sich nicht einmal die Mühe, eine Browserweiche zu bauen, sondern schreiben ihren HTML-Code gleich so, daß er nur auf einem bestimmten Browser funktioniert. Das ist fast noch übler. Hier muß ich natürich auf die Kampagne für browserneutrales Webdesign verweisen.

Frames, VBScript und ActiveX

Frames, VBScript und ActiveX sind böseTM. Ist halt so. Dazu muß man, glaube ich, nichts weiter sagen.


Besucher: 18.222.22.244 mit Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com) (HTTPS) um 2024-04-23 16:09:10