(Klicken, um großes Bild aufzurufen)Wie im Abschnitt »Meine Erfahrungen mit Webdesign-Agenturen«, »Vergleich 3« erwähnt, handelt es sich bei dieser Seite um einen Agenturaufftrag – und nicht um die Homepage der Agentur selbst.
Dem Kunden, der diese im Frankfurter Raum angesiedelte Agentur beauftragt hatte, hatte ich im Januar 2007 eine ausführliche Analyse zukommen lassen. Hier der – ebenfalls anonymisierte – Wortlaut mit Antwort.
Mein standardkonformer Nachbau berücksichtigt nun alle Punkte, die ich in dieser Analyse anführte.
Zum besseren Verständnis der folgenden Erläuterungen, rufen Sie die anonymisierte Agenturseite in einem neuen Fenster auf, und behalten Sie diese griffbereit im Hintergrund!
Da die Anzeige in einem Frameset erfolgt, rufen Sie danach auch die tatsächliche Inhaltsseite auf für spätere Erläuterungen.
Das Dokument enthält keine Doctype-Angabe. Dadurch ist das Dokument nicht nur nicht valides HTML, sondern die Browser rendern nach Gutdünken. Erst die Angabe einer Dokumenttyp-Deklaration mit Dokumenttyp-Definition (DTD) zwingt die Browser dazu, den Code ordentlich zu interpretieren.
Obwohl ich seit langem keine Frames mehr einsetze, zähle ich mich nicht zu der missionarisch-puristischen Anti-Frames-Fraktion dazu. Doch im Fall dieser Kundenseite ist ein Frameset absolut nicht notwendig. Außerdem, wenn schon auf Frames zurückgegriffen werden musste, um ein zentriertes Anzeigefenster innerhalb des Browserfensters zu erhalten, bleibt es ein Rätsel, warum nicht gleich ein mittig zentriertes, eingebettes Frame (<iframe>) zum Einsatz kommt, anstelle dieses sonderbaren Konstrukts aus ganzen neun Frames (bestehend aus der Anzeigeseite und acht weiteren inhaltsleeren Seiten, nur um den grauen Rahmen zu bilden).
Der <noframes>-Bereich ist leer: Besucher, die die Anzeige von Frames deaktiviert haben, bekommen nichts zu sehen. Hm, Barrierefreiheit als Spezialität?
Auch wenn dies kein schlimmer (vielleicht sogar kein) Fehler ist, ist es in meinen Augen eine Unverschämtheit seitens der Agentur, sich hier als Autor in einem zweiten Meta-Tag zu präsentieren. Manche Suchmaschinen werden lediglich die zweite Angabe speichern, also gar nicht den Namen des Kunden – welcher immerhin Urheber der Inhalte bleibt.
Die weiteren Erläuterungen und Kritiken behandeln die tatsächliche Inhaltsseite:
Wie bereits bei der Frameset-Datei fehlt hier die wichtige Dokumenttyp-Angabe.
Die externe CSS-Ressource wird Zeile 16 eingebunden, also bereits im Körper des Dokuments (<body>). Diese Referenzierung gehört aber innerhalb des Dateikopfes (<head>-Bereich) notiert, also vor dessen abschließenden Tags </head> Zeile 13.
Dasselbe gilt für den Style-Block Zeilen 174 bis 188: Ein CSS-Anweisungsblock gehört ebenfalls innerhalb des Dateikopfes notiert. Desweiteren gehören die dort notierten CSS-Regeln zur farblichen Gestaltung der Scrollleisten nicht zum CSS-Standard, sondern wurden lediglich von Microsoft eingeführt (auch wenn Opera-Browser diese Regeln interpretieren).
Für das Zeile 17 eingebundene Logo (eine GIF-Datei) wurde kein Alternativtext notiert: Blinde und Besucher, die das Anzeigen von Bildern deaktiviert haben, bekommen nichts mit. Hm, Barrierefreiheit als Spezialität?
Dieser Fehler wiederholt sich bei fast allen (nicht als Hintergrundgraphik) eingebundenen Bildressourcen.
Die Slashs (»//«) in der Kommentar-Notation Zeile 20 und bei allen anderen HTML-Kommentaren sind überflüssig.
Dieser Fehler ist im Grunde genommen kein Fehler (wird vom Validator auch nicht moniert), sondern lediglich eine falsche Notation. Die Doppelslashs vor dem Ende eines HTML-Kommentartags sind nur innerhalb von JavaScript-Blöcken notwendig - wenn man auf sehr archaishe Browser Rücksicht nehmen will.
Zeile 16 wird bereits eine externe CSS-Datei eingebunden. Warum werden dann Zeile 22 (und an anderen Stellen im Dokument) weitere CSS-Anweisungen als »Inline-Styles« vermerkt (<div id="navigation" style="position:absolute; overflow:auto; ...">)? Diese sind in der externen CSS-Ressource besser aufgehoben.
Dies ist auch kein »richtiger« Fehler (wird deswegen nicht nummerisch gezählt), macht aber für spätere Änderungen den Quelltext schwer zu warten. Ein zentrales CSS-Dokument zu ändern ist viel einfacher, als in einem unübersichtlichen HTML-Code nach Inline-Styles zu suchen!
Der Inhalt dieser Seite enthält keine tabellarisch darzustellenden Daten. Dennoch werden im Quelltext vier Tabellen notiert (Zeilen 23, 100, 159 und 199). Diese vier Tabellen wurden hier zum Zwecke der Darstellung eingebunden, wozu das table-Element aber nicht erdacht worden ist. Zudem blähen Tabellen den Quelltext unnötig auf, der dardurch schwer zu lesen und von Dritten zu pflegen wird.
(Klicken, um großes Bild aufzurufen)
Der W3C-Validator weist auf einen geschlossenen, jedoch nirgends zuvor geöffneten Tag Zeile 26 auf (nebenbei bemerkt: deswegen ist der Validator eigentlich da! Um Fehler, die bei der Erstellung einer Webseite immer wieder auftreten können, aufzuzeigen. Hätte die so sehr auf barrierefreiheit spezialisierte Agentur ihre Arbeit validiert, wäre der Fehler aufgefallen).
Dieser <font>-Tag zur Angabe der Schriftart/-famile und der Schriftfarbe, der auch an anderen Stellen im Dokument eingesetzt wird (z.B. Zeilen 36, 103, 110, 163 und 202), ist zwar nicht gänzlich aus dem HTML-Standard gestrichen worden, gilt allerdings schon lange als deprecated. Moderne Webdesigner, wie man sie eigentlich in professionellen Webdesign-Agenturen antreffen sollte, nutzen zur Formatierung der Schrift ausschließlich CSS.
Der Grund für den sechsten Fehler ist übrigens hier zu finden:
<a href="/z_testdir/ag_3/erlaeuterungen.html" target="_self" class="link">Startseite</font></a>
^
Gewollt war (vermutlich) folgendes:
<a href="/z_testdir/ag_3/erlaeuterungen.html" target="_self"><font class="link">Startseite</font></a>
^
Diese schlampige Arbeitsweise wiederholt sich auch Zeile 84 (dort steht »font« im div-Tag, was ebenfalls aufgefallen wäre, wenn »barrierefreie Agentur« die Seite einem Validitätscheck unterzogen hätte. Denn der Validator meldet: »Line 84, Column 106: "FONT" is not a member of a group specified for any attribute.«).
Abstände vom Fensterrand, innerhalb oder zwischen Elementen helfen, den Inhalt besser zu strukturieren und zu visualisieren. Um Abstände zu erzeugen, bieten CSS gleich zwei mächtigen Werkzeuge, nämlich margin für den Außenrand/-abstand und padding für den Innenabstand.
Die Realisierung von Abständen mit Hilfe geschützter Leerzeichen, wie nicht nur Zeile 26 zu sehen (<td bgcolor="#00C000" width="110"> <a ...), erinnert eher an Laienarbeit denn an professionelles Layouten. Hier übertrifft vor allem der neunte »Fehler« alles, was mir an schlechter Arbeit bisher begegnet ist!
Überschriften helfen dem Autor, dem Inhalt eine bessere Struktur zu geben und dem Leser, sich einen kurzen Überblick über den gesamten Inhalt eines Textes zu verschaffen: bei langen Texten sind sie eine willkommene Orientierungshilfe. Überschriften sollten daher mit der größten Sorgfalt gewählt werden und eine knappe, prägnante Zusammenfassung der Informationen anbieten, die im darauf folgenden Abschnitt zu finden sind.
Im Webdesign sind Überschriften aus zwei weiteren Gründen wichtig: Sie werden von Screen Readern anders vorgelesen als der restliche Text, sind sogar »navigierbar«. Auf Screen Reader angewiesene Besucher können sich von Überschrift zu Überschrift »bewegen«. Ferner gewichten Suchmaschinen den Inhalt von Überschriften, zumindest einiger, stärker als den restlichen Text.
HTML verfügt zum Auszeichen von Überschriften über ein Element: das Element »hx«: h steht für »heading« (Überschrift), x für eine Zahl zwischen 1 und 6). Damit lassen sich sechs Überschriftenebenen abbilden: <h1> stellt die höchste, <h6> die niedrigste Hierarchiestufe dar.
Im Browser betrachtet weist die Beispielsseite zwei Überschriften auf: »Kurz notiert« und anschließend, etwas kleiner formatiert: »Meine Fachbereiche und Erfahrungen«. Doch im Quelltext ist kein entsprechendes Element zu finden! Statt dessen wurde normaler Text mit Hilfe des veralteten font-Elements und einer CSS-Klasse so formatiert, dass dieser wie eine Überschrift aussieht. Ein Screen Reader würde hier vorlesen:
kurz-notiert-ich-bin-zoologe- ...
in einem Atemzug und mit gleichbleibender Stimmlage (zudem p-Elemente zur Auszeichnung von Abschnitten fehlen). Erst durch die richtige Auszeichnung mit dem <hx>-Element würde die Maschine die Überschrift entweder stärker betonen oder eine kleine Pause zwischen dieser und dem restlichen Text einlegen. Hier jedoch erkennen auf Screen Reader angewiesene Besucher nicht, was Sehenden sofort ins Auge springt, nämlich die zwei Überschriften. Hm, Barrierefreiheit als Spezialität?
Als ich mein Versprechen einlöste und die Präsenz des Kunden unter die Lupe nahm, traute ich hier meinen Augen nicht. Ich fühlte mich ins Jahr 1998 zurückversetzt, als ich die Seite eines Bekannten optimiert hatte. Dieser hatte die Seite mit dem Netscape Composer erstellt – einem zum Glück wie Microsofts FrontPage verschwundenen WYSIWYG-Editor (WYISIWYG: What You See Is What You Get), der einen grauenhaften Code produzierte: Alle Einrückungen und Zentrierungen waren mit ellenlangen Zeilen voller geschützten Leerzeichen ( ) realisiert, was mir damals – der ich mit HTML gerade angefangen hatte – einen Haufen Zeit kostete, um mich in dieser Leerzeichenwüste zurecht zu finden!
Ob die »barrierefreie Agentur« einen WYSIWYG-Editor zur Erstellung dieser Seite benutzt hatte? Hatte man den neuen Auszubildenden die Arbeit machen lassen, weil andere Designer mit wichtigeren Projekten beschäftigt waren als mit diesem wenige Unterseiten umfassenden und somit wahrscheinlich nicht so lukrativen Auftrag?
Aber zurück zur Beispielsseite: unterhalb der (wie eben gesehen nicht als solche ausgezeichneten) Überschrift »Meine Fachbereiche und Erfahrungen« werden eben diese Bereiche in Form einer Liste aufgeführt. Zumindest sieht es aus wie eine Liste: schön eingerückt und mit einem Aufzählungszeichen (hier jeweils einem grünen Quadraten) vor jedem Listenpunkt versehen. Alles deutet darauf hin, dass hier korrekterweise mit den entsprechenden HTML-Elementen zur Auszeichnung von Listen gearbeitet wurde: <ul> für ungeordnete Liste und <li> für list item (Listenpunkt)...
Doch der Blick in den Quelltext verrät bereits ab Zeile 113, dass dem nicht so ist: Kein einziges Listenelement ist hier zu sehen, statt dessen wurden die Listeneinrückungen – wieder mal – mit Hilfe unzähliger geschützter Leerzeichen realisiert!
Mir tut das Geld leid, das »Kunde« für die Erstellung dieser Website ausgegeben hat! Neun unverzeihliche Design-Fehler für eine Agentur, die sich laut eigener Aussage auf »Barrierefreiheit spezialisiert« hat, gekoppelt mit schlampiger Arbeit... die der 14-jährige Sohn oder die Tochter des Nachbars mindestens genauso schlecht hinbekommen hätte und das für einen Bruchteil der vereinbarten Summe!
Es gäbe noch mehr zu dieser Seite zu sagen, z.B. wie sich das schlechte Markup im Bezug auf Suchmaschinenoptimierung auswirkt... aber ich denke, lieber Leser, wenn Sie von der Rubrikseite bis hierhin gelesen haben, dass Sie jetzt genug mitnehmen, um bei der Suche nach einem geeigneten Webdesigner für Ihren Auftritt vorsichtig zu sein! Lassen Sie sich nicht von Floskeln wie »wir haben die Usability erfunden«, »Barrierefreiheit ist unsere Spezialität« blenden, sondern überprüfen Sie, ob die Anbieter auch einhalten, was sie Ihnen versprechen.
Obige Punkte gelten auch für die vertikal zentrierte Version dieses Nachbaus.