Schlanker Code, dargestellt mit der Firefox-Erweiterung Tilt

Nicolai Schwarz von der Webkrauts-Redaktion fragt nach, wie barrierefrei der Auftritt über barrierefreies Webdesign ist.

Nicolai:

Jan, Du hast Ende Oktober Deinen Webauftritt www.barrierefreies-webdesign.de mit neuem Design und neuen Inhalten online gestellt. Da du ja Spezialist für barrierefreie Webseiten bist: Ist deine Seite nun barrierefrei? Nach dem Domainnamen zu urteilen, müsste sie es ja sein.

Jan:

Könnte man die Frage mit einem einfachen »Ja« oder »Nein« beantworten, wären heute alle professionellen Webauftritte barrierefrei. Nein, trotz der Webstandards zur Barrierefreiheit wird die tatsächliche Nutzbarkeit immer noch von Inhalten und nicht zuletzt den Nutzern abhängig sein. 100%ige Barrierefreiheit kann wohl nie erreicht werden. Barrierefreiheit ist ein Ziel und kein Zustand.

Dennoch: Ich habe mir alle Mühe gegeben, die Erfolgskriterien der Web Content Accessibility Guidelines 2.0 (WCAG 2.0 bzw. Richtlinien für barrierefreie Webinhalte 2.0) zu erfüllen. Das heißt, die Erfolgskriterien der Konformitätsstufen A und AA sind mit ziemlicher Sicherheit erfüllt, aber nicht alle Anforderungen der Konformitätsstufe AAA konnten mit der gleichen Selbstverständlichkeit umgesetzt werden.

Nicolai:

Kannst Du die Konformitätsstufen etwas näher erläutern?

Jan:

Das Konzept der Konformität in den WCAG 2.0 ist ein sehr ausgeklügeltes System. Die konkreten Anforderungen werden in 61 Erfolgskriterien formuliert. Ein Erfolgskriterium der WCAG 2.0 ist eine allgemeine Anforderung an Webinhalte, die die Zugänglichkeit und Nutzbarkeit durch Menschen mit Behinderungen sicherstellen soll.

Die Erfolgskriterien gehen über allgemeine Anforderungen der Nutzbarkeit und Zugänglichkeit hinaus und sind stets wichtiger für Menschen mit Behinderungen als für Menschen ohne Behinderung. Während beispielsweise Usability oder Standardkonformität durchaus allgemeine Anforderungen für ein Webangebot darstellen, decken die Erfolgskriterien der WCAG 2.0 ausschließlich solche Anforderungen der Nutzbarkeit und Zugänglichkeit ab, die aufgrund von Behinderungen entstehen.

Jedes Erfolgskriterium ist einer der drei Konformitätsstufen A, AA oder AAA zugeordnet. Allgemein können diese so beschrieben werden, dass Konformitätsstufe A wichtige Anforderungen darstellen und dass je höher die Konformitätsstufe wird, desto nachrangiger die Anforderung ist. Tatsächlich sind deutlich mehr Faktoren in diese Klassifizierung eingeflossen, etwa

• ob das Erfolgskriterium eine Voraussetzung für die Zugänglichkeit darstellt,
• ob das Erfolgskriterium für alle Inhaltsformen umsetzbar ist,
• ob Webworker das Erfolgskriterium mit vertretbarem Aufwand umsetzen bzw. erlernen können oder
• ob das Erfolgskriterium Funktion und Design von Webseiten stark beeinflusst.

Darüber hinaus gibt es einige Erfolgskriterien, die quasi zweimal in der WCAG 2.0 vorkommen. Das erste Erfolgskriterium ist dann zum Beispiel für die Konformitätsstufe A notwendig und ein zweites Erfolgskriterium mit erhöhten Anforderungen der Konformitätsstufe AAA zugeordnet. Beispiele dafür betreffen etwa die Tastaturbedienung, Audiodeskription oder Linktexten.

Ob nun eine Seite barrierefrei ist oder nicht, wird auf der Grundlage der WCAG 2.0 über die Konformitätsstufen definiert, d.h. wenn alle Erfolgskriterien der Stufe A erfüllt sind, ist die Konformität auf Stufe A erreicht. Für Stufe AA müssen die Erfolgskriterien der Stufen A und AA ohne Ausnahme erfüllt werden und für Konformitätsstufe AAA sämtliche Erfolgskriterien der WCAG 2.0.

Nicolai:

Die WCAG 2.0 wurde in diesem Jahr auch in der Barrierefreien Informationstechnik-Verordnung 2.0 übernommen. Wird das einen großen Einfluss auf die Webgestaltung in Deutschland haben?

Jan:

Mittelfristig leider nicht, aber langfristig wahrscheinlich schon. Die BITV 2.0 orientiert sich zwar an den WCAG 2.0, aber sie bricht mit wichtigen normativen Grundsätzen, etwa den Konformitätsstufen. Letztlich wurden im Wesentlichen die Erfolgskriterien der WCAG 2.0 übernommen, mehr aber auch nicht. Außerdem gilt die BITV 2.0 nur für die Bundesverwaltung, was für die Vorgängerversion aus 2002 ebenfalls galt.

Es ist keine Frage, dass die BITV 2.0 als Selbstverpflichtung der Bundesregierung bedeutsam ist. Sie wurde auch gemeinsam mit Vertretern der Behindertenverbände in Deutschland entwickelt und drückt den Anspruch an die Gleichstellung aus. Aber sie ist aus mehreren Gründen nicht mit den WCAG 2.0 kompatibel; außerdem widerspricht die BITV 2.0 aus denselben Gründen EU-Vorgaben zur Barrierefreiheit im Netz. Erst wenn die EU-Vorgaben konkretere Formen annehmen, werden Behörden und auch die Wirtschaft stärker in die Pflicht genommen.

Der Maßstab für barrierefreies Webdesign ist die WCAG 2.0, die jetzt schon drei Jahre ein Webstandard sind. Neben dem bereits erwähnten Konzept der Konformität enthalten sie umfangreiche Dokumentationen, die regelmäßig an den Stand der Technik angepasst werden. Wer barrierefreies Webdesign erfolgreich umsetzen will, kommt um die Konformitätsstufen und den zusätzlichen Dokumenten der WCAG 2.0 nicht vorbei.

Nicolai:

Kommen wir zurück zu Deiner Seite. Du hast keine Erklärung zur Konformität. Welche Konformitätsstufe erreicht der Webauftritt denn?

Jan:

Eine Erklärung zur Konformität kommt sicher noch. Leider war die Luft kurz vor und nach dem Relaunch etwas raus, und die Überprüfung der Aussagen in einer solchen Erklärung ist eine nicht triviale Angelegenheit. Außerdem ist die Seite — wie so viele Webseiten — zwar online, aber noch lange nicht fertig.

Ich gehe davon aus, dass Konformitätsstufe AA erreicht ist, allerdings gibt es Grenzfälle. Beispielsweise habe ich die Codelistings und Multimedia von der CD-ROM meines Buchs aus 2004 integriert. Sie enthalten Beispielvideos; die Videos sind teils mit und teils ohne Ton und haben keine Alternativen — weder Audio-Deskription noch Untertitel — höchstens der dargestellte Code. Da es sich um Beispiele handelt, sind sie auf der Grundlage der Richtlinien in Ordnung, aber trotzdem könnte man hier einen Strick daraus drehen und sagen, der Webauftritt sei nicht barrierefrei bzw. erreiche nicht einmal die Konformitätsstufe A.

Natürlich sind auch etliche Anforderungen der Konformitätsstufe AAA erfüllt, aber nicht alle. Ich kann zum Beispiel nicht behaupten, dass das Leseniveau (Erfolgskriterium 3.1.5) auch für Schüler der sechsten Klasse geeignet ist; schlicht und einfach, weil ich das Leseniveau nicht darauf geprüft habe. Auch haben aufgezeichnete synchronisierte Multimedia mit Audio keine ergänzende Gebärdensprachfilme (Erfolgskriterium 1.2.6). Ich bin mir außerdem nicht sicher, ob wirklich alle Linktexte auch außerhalb ihres Kontextes jedem verständlich sind (Erfolgskriterium 2.4.9). An der Barrierefreiheit der Seiten werde ich zwar weiter arbeiten, aber ich behaupte jetzt auch, dass kein Auftritt dieses Umfangs Konformitätsstufe AAA erreichen kann — zumindest kenne ich keinen größeren Webauftritt, der alle Erfolgskriterien der WCAG 2.0 erfüllt.

Nicolai:

Was hast Du denn auf Konformitätsstufe AAA umgesetzt?

Jan:

Von den 23 Erfolgskriterien der Stufe AAA sind auf www.barrierefreies-webdesign.de nach aktueller Einschätzung vier nicht erfüllt und vier nicht anwendbar. Von den verbleibenden 15 Erfolgskriterien sind elf aller Wahrscheinlichkeit nach erfüllt und vier sind noch zu klären.

Erfüllt	1.4.7 — leiser oder kein Hintergrund-Audioinhalt 1.4.9 — Bilder eines Textes (keine Ausnahme) 2.1.3 — Tastatur (keine Ausnahme) 2.2.3 — keine Zeiteinteilung 2.4.8 — Position 2.4.10 — Abschnittsüberschriften 3.1.3 — ungewöhnliche Wörter — wahrscheinlich 3.1.4 — Abkürzungen — wahrscheinlich 3.2.5 — Änderung auf Anfrage 3.3.5 — Hilfe 3.3.6 — Fehlervermeidung (alle)
In Arbeit	1.4.6 — Kontrast (erhöht) — in Arbeit 1.4.8 — visuelle Präsentation — in Arbeit 2.3.2 — drei Blitze — zu prüfen 2.4.9 — Linkzweck (reiner Link) — zu prüfen
Nicht erfüllt	1.2.6 — Gebärdensprache (aufgezeichnet) 1.2.7 — erweiterte Audiodeskription (aufgezeichnet) 1.2.8 — Medienalternative (aufgezeichnet) 3.1.5 — Leseniveau
Nicht anwendbar	1.2.9 — reiner Audioinhalt (live) 2.2.4 — Unterbrechungen 2.2.5 — erneute Authentifizierung 3.1.6 — Aussprache

Die beiden noch in Arbeit befindlichen Erfolgskriterien betreffen das visuelle Erscheinungsbild:

• Zum einen geht es um Kontraste: Es ist nicht einfach, harmonisierende Farben zu finden, die die erhöhten Kontrastanforderungen (Erfolgskriterium 1.4.6) erfüllen. Ich habe hierzu etliche Runden mit allen möglichen Leuten gedreht, bis ich eine zumindest für mich akzeptable Kombination von Farben gefunden habe. Dabei mussten viele Farbzuweisungen im Inhalt zurückgenommen werden oder sind ganz verschwunden, denn sogar die minimalen Kontrastverhältnisse auf Konformitätsstufe AA stellten sich als schwierig zu realisieren heraus. Weil die Farben in den letzten Monaten öfters geändert wurden, steht noch eine letzte Optimierungsrunde aus. Den Anspruch, überall AAA zu erreichen, habe ich allerdings nicht mehr. Sollten sich aber Nutzer beschweren, dann werde ich das Erfolgskriterium wohl wieder auf die Tagesordnung setzen.
• Zum anderen geht es um diverse Anforderungen an die visuelle Präsentation (Erfolgskriterium 1.4.8). Umgesetzt ist beispielsweise die Begrenzung der Laufweite und das flüssige Layout. Hier zeigt sich, wie unterschiedlich die Umsetzung sein kann: Während die Laufweite mit einem Minimum an CSS festgelegt werden kann, ist die Gestaltung eines flüssigen Layouts komplexer: Nicht nur müssen wir Seitenzoom, Textvergrößerung und die Kombinationen von beiden überprüfen, wir müssen hier besonders intensiv mit verschiedenen Browsern und Browserversionen testen — ebenso wie mit unterschiedlichen Bildschirmauflösungen. Die Lösung mit JavaScript funktioniert inzwischen recht stabil; mittlerweile habe ich aber auch andere Lösungen gesehen, die ohne JavaScript auskommen und stattdessen mit Media-Queries arbeiten. Insgesamt handelt es sich bei diesem Erfolgskriterium um sehr testintensive Anforderungen, so dass eine 100%ige Erfüllung schwer zu überprüfen ist. (siehe Demo)

Mehr als die Hälfte der Erfolgskriterien auf Konformitätsstufe AAA sind umgesetzt worden bzw. nicht anwendbar oder werden in Kürze umgesetzt sein. Auf dem Webauftritt sind beispielsweise folgende Punkte bereits erledigt:

Die Position einer einzelnen Seite innerhalb des Webauftritts (Erfolgskriterium 2.4.8) wird über mehrere Wege vermittelt: In der Navigation wird die Position mit Farbe, border (für benutzerdefinierte Farbeinstellungen) und einem Icon gekennzeichnet; ergänzt werden die Kennzeichnungen mit einem Brotkrumenpfad. Besonders tückisch war aber die Abbildung der Position auf der Strukturebene: Die Subnavigation auf der linken Seite musste als integrativer Bestandteil der Hauptnavigation ausgespielt werden, um die Anforderungen aus dem Erfolgskriterium in Verbindung mit der Linearisierbarkeit zu erfüllen.

Die Subnavigation wird als Teil der Hauptnavigation ausgespielt.

Im konkreten Layout hatte die dadurch notwendige absolute Positionierung einen starken Einfluss auf den Fluss von Inhalt (rechts) und Info-Bereich (unten links). Es bedürfte eines Fine-Tunings mit JavaScript, um das Layout stabil zu halten.

Für möglichst eindeutige Linktexte (Erfolgskriterium 2.4.9) werden Icons eingesetzt, mit denen interne von externen Links unterschieden werden können oder die aktuelle Position in der Navigation gekennzeichnet wird. Die Grafiken wurden aus zwei Gründen als IMG im HTML eingebunden (statt als CSS-Hintergrundgrafik): Zum einen sollten sie bei benutzerdefinierten Farbeinstellungen wahrnehmbar sein und zum anderen benötigen sie einen Alternativtext. Hier musste ich einen etwas ungewöhnlichen Weg gehen und die Icons in den Links einbauen, um der Anforderung zu genügen.

An einigen Stellen — etwa beim Vergleich zwischen WCAG 2.0 und BITV 2.0 — biete ich Auswahlmöglichkeiten an. Obwohl es sehr verlockend war, die Anzeige der ausgewählten Inhalte dynamisch zu gestalten, habe ich die Änderung von Inhalten nur nach expliziter Bestätigung durch den Nutzer (Erfolgskriterium 3.2.5) vorgesehen. Um genau zu sein, besteht die abhängige Auswahl von Inhalten zunächst aus einer Auswahlliste und Schaltfläche, die mit Progressive Enhancement vereinfacht wird; Inhalte der Seite werden aber nicht dynamisch ausgetauscht.

Nicolai:

Wenn deine Webseite also weitestgehend barrierefrei ist, willst du dir das irgendwie zertifizieren lassen?

Jan:

Nein, von wem denn? In Deutschland gibt es kein anerkanntes Zertifizierungsverfahren. Und wenn es ein solches Verfahren gäbe, würde es wahrscheinlich immer den falschen Eindruck vermitteln, nämlich dass die Barrierefreiheit in irgendeiner Weise vollendet sei.

Wenn es eines Tages Zertifizierungen für barrierefreies Webdesign geben sollte, dann muss man sich hier aber an der WCAG 2.0 orientieren und entweder ein A (für weniger Barrierefreiheit), ein AA (für mehr Barrierefreiheit) und AAA (für eine umfassende Barrierefreiheit) vergeben.

Nicolai:

Gibt es besondere Highlights auf der Seite?

Jan:

Das Rad habe ich nicht neu erfunden. Die eingesetzten Techniken sind seit Jahren bekannt. Es wurden aber viele Kriterien der Barrierefreiheit sehr detailliert berücksichtigt, die auf den ersten Blick nicht erkennbar sind. Eine der größten Herausforderungen war es, diese vielen Aspekte in Einklang zu bringen.

Wichtig sind natürlich die Inhalte. Viele Beiträge stammen aus den Jahren 2001 bis 2003 und mussten an die WCAG 2.0 angepasst werden. Leider habe ich einige Artikel aus dem Angebot rausnehmen müssen, weil sie so nicht mehr vertretbar waren. Insgesamt hat die redaktionelle Arbeit die meiste Zeit in Anspruch genommen.

Inzwischen gab es eine erste Feedbackrunde. Gut fand ich, dass vor allem blinde Nutzer besser zurechtkamen. Auch das flexible Layout, d.h. die Anpassung von Schriftgröße und Fenstergröße, funktioniert gut. Und wenn man mir mitteilt, dass die Farben gut gewählt sind, muss ich an die vielen Runden denken, die ich gedreht habe, bis die Anforderungen an Kontrastverhältnisse und "visuell akzeptabel" eine ausreichend große Schnittmenge aufwiesen. Gerade beim Design wird sehr deutlich, wie viele Meinungen es zu vermeintlichen Kleinigkeiten geben kann.

Das Highlight ist, dass die Seite endlich online ist. Sie ist öffentlich und nicht perfekt, aber entwickelt sich täglich weiter. Und sie gibt hoffentlich neue Impulse, das Web barrierefreier zu machen.

Ein Interview mit

Jan Eric Hellbusch bietet Beratung und Schulung zur Barrierefreiheit im Web. Er ist außerdem Buchautor: Zuletzt hat er mit Kerstin Probiesch das Buch Barrierefreiheit verstehen und umsetzen — Webstandards für ein zugängliches und nutzbares Internet geschrieben.

Webstandards im engeren Sinne sind technische Spezifikationen, die von Industriegremien herausgegeben und öffentlich weiterentwickelt werden. Ziel dieser Spezifikationen ist es unter anderem, browserübergreifend einheitlich implementiert zu werden, sodass eine standardkonforme Website auf verschiedenen Browsern robust funktionieren kann. Im Vergleich zu Websites, die lediglich auf proprietäre (herstellereigene) Techniken setzen, ist eine standardkonforme Website zukunftsfähiger.

Konformität zu Webstandards heißt dabei, sowohl die konkreten Anforderungen als auch die dahinter stehenden Prinzipien umzusetzen. Die konkrete Konformität lässt sich teilweise automatisiert mit Validatoren und Lints testen, andere Anforderungen lassen sich zumindest manuell prüfen.

W3C-Webstandards

Das wichtigste Gremium für Webstandards war bisher das World Wide Web Consortium (W3C). Es gibt die Standards für HTML und CSS heraus, sogenannte W3C-Recommendations. Die W3C-Standards folgen gewissen Designprinzipien, die auf den Idealen des W3Cs basieren.

Über eine lange Zeit hinweg waren HTML 4.01, XHTML 1.0, CSS 2.0 und DOM 2 Core/HTML die Spezifikationen, auf die sich die Webstandards-Bewegung bezog. Sie stammen größtenteils aus den Jahren 1998 bis 2000. Die darauffolgenden Jahre kämpften die Webstandards-Verfechter dafür, dass diese auch einheitlich in den Browsern umgesetzt werden.

Die Situation hat sich seitdem verkompliziert. Dies hat verschiedene Gründe, die auch mit einem geänderten Prozedere des W3Cs zu tun haben: Damit ein Dokument eine Recommendation wird, bedarf es mindestens zwei konformer Browser-Umsetzungen. Stolze 13 Jahre wurde daher an dem Nachfolger von CSS 2.0 gearbeitet. Im Juni 2011 erschien mit Version 2.1 schließlich eine fehlerbereinigte, an die Praxis angepasste CSS-Spezifikation, die sich breiter Unterstützung erfreut.

Zwei HTML5-Spezifikationen mit Unterschieden

Die Weiterentwicklung der anderen Spezifikationen geriet ebenfalls ins Stocken. Das W3C hatte zunächst die Arbeit an HTML 4 und XHTML 1 aufgegeben und arbeitete an XHTML 2, welches seitens der Browserhersteller auf Ablehnung stieß. So gründeten diese die »Web Hypertext Application Technology Working Group« (WHATWG) als Konkurrenz zum W3C, eine lose Arbeitsgruppe ohne einen formalen Rahmen. Die WHATGWG startete mit dem Ansatz, HTML 4, XHTML 1 sowie DOM 2 HTML unter dem Namen (X)HTML5 evolutionär weiterzuentwickeln. Ihr Ziel ist es, offener, pragmatischer und schneller zu arbeiten als das W3C, ihr Maßstab für Erfolg ist die Akzeptanz der Techniken bei den Browserherstellern.

Schließlich entschied sich das W3C im Jahr 2006, die Arbeit der WHATWG als Grundlage für den kommenden W3C-HTML-Standard zu verwenden. Seitdem entwickeln gleich zwei Arbeitsgruppen parallel am wichtigsten Webstandard: Die HTML-Arbeitsgruppe des W3Cs und die weniger scharf umgrenzte WHATWG. Die Spezifikation liegt in zwei Versionen vor, die sich aufgrund inhaltlicher Differenzen voneinander unterscheiden können. Auch in anderen Bereichen werden Spezifikationen jeweils von einer W3C-Arbeitsgruppe und der WHATWG gleichzeitig betreut.

Die gegenwärtige Lage der Webstandards ist nicht zu verstehen, wenn man diese Spaltung und ihre Auswirkungen nicht kennt. Die WHATWG arbeitet an einem versionslosen, nie abgeschlossenen »Living Standard«, der gleichermaßen aus sehr stabilen und bereits implementierten wie aus rein experimentellen Techniken besteht. Konsequenterweise trägt HTML auf Seiten der WHATWG keine Versionsnummer mehr. Hingegen strebt das W3C an, ihre HTML5-Version schnell abzuschließen und als Recommendation zu veröffentlichen. Zu diesem Zweck werden strittige, instabile und optionale Teile ausgeklammert. Am 2. August 2011 lief die »Last Call«-Phase ab, für 2014 ist die Verabschiedung der Spezifikation vorgesehen.

Die neue Unsicherheit

Von HTML5 als Webstandard zu sprechen, ist also nicht unproblematisch: Zwar wird eine traditionelle W3C-Recommendation erarbeitet, interessante Teile fehlen darin jedoch und sind auf W3C-Seite höchstens als Zusatzmodule ausgelagert.

Was CSS betrifft, so haben wir es mit zahlreichen proprietären Eigenschaften und W3C-Entwürfen zu tun, die sich noch stark im Fluss befinden. Die Hersteller haben ihre Erfindungen als Entwürfe beim W3C eingereicht. Deren CSS-Arbeitsgruppe arbeitet sie langsam ab und kodifiziert, was die Browser experimentell längst unterstützen. Dabei können sich durchaus noch Änderungen ergeben. Erst wenige Module von CSS 3 haben es bisher zu Candidate Recommendations, Proposed Recommendations oder gar Recommendations geschafft.

CSS 3 bedeutet also, ständig Eigenschaften mit Hersteller-Präfixen zu notieren. Uneinheitliche Browserunterstützung und proprietärer Code ist damit zur Regel geworden – genau das, was die Webstandards-Bewegung eigentlich abschaffen wollte.

Im JavaScript-Bereich lichtet sich langsam das Dunkel. Die HTML5-Spezifikation definiert nicht nur die Auszeichnungssprache, sondern auch gleich die zugehörigen JavaScript-Schnittstellen. Diese existieren teilweise seit den Anfangstagen von JavaScript, wurden vorher aber in keinem Standard normativ festgelegt. Techniken wie XMLHttpRequest sind Gegenstand weiterer W3C Working Drafts. Auch hier kann man mehr von einem anhaltenden, nachholenden Standardisierungsprozess sprechen, als von fertigen, etablierten Webstandards.

Standardkonformität als Qualitätsmerkmal

Lange dienten die W3C-Standards als Qualitätsmaßstab. W3C-Konformität schaffte Vertrauen gegenüber Kunden, denn das Industriegremium genoss eine hohe Autorität. Mittlerweile hat das W3C seine Autorität verloren. Browserhersteller wollen die Fähigkeiten des Webs als Anwendungsplattform rapide ausbauen und entschließen sich zunehmend, die Sache selbst in die Hand zu nehmen. Sie arbeiten bloß aus taktischen Gründen mit dem W3C zusammen: Wenn ihnen das W3C dienlich ist, so nutzen sie es als Vehikel, um ihre Techniken zu etablieren, anderweitig entziehen sie sich dessen formalisierten Verfahren.

Zur Zeit ihrer Verabschiedung waren HTML 4 und CSS 2 die normativen Referenzen für Qualität im Webdesign. »Der Code validiert gemäß XHTML 1.0 Strict und CSS 2.0« war zusammen mit weiteren Coding- und Design-Guidelines Bestandteil vieler Pflichtenhefte. Bezüglich HTML5 und CSS 3 lassen sich solche harten Kriterien nicht mehr aufstellen. Es gibt zwar einen HTML5-Validator, der sich jedoch nach dem »Living Standard« der WHATWG richtet. Das bedeutet, dass sich die Anforderungen – zumindest theoretisch – andauernd ändern können. Einen praxistauglichen CSS-3-Validator gibt es nicht, der W3C-CSS-Validator kann mit experimentellen Eigenschaften und Werten nicht umgehen.

Der Wegfall der einfachen Validierbarkeit ist problematisch, denn die Verwendung von HTML5 und CSS 3 kann die Qualität einer Website definitiv steigern, wie eine Vielzahl an Artikeln der Webkrauts gezeigt hat.

Ambivalente Innovationen

Für Webentwickler erweist sich die gegenwärtige Situation als ambivalent. Es gibt einen rasanten technischen Fortschritt. Browser implementieren ständig neue experimentelle Techniken, die die Webentwicklung vereinfachen und neue Möglichkeiten schaffen sollen. Für Webentwickler stellt die Aufsplittung in dutzende Spezifikationen und die oft undurchschaubare Browserunterstützung in erster Linie eine Herausforderung dar.

Zudem folgt die Standardisierung nicht mehr einheitlichen, absehbaren Verfahren. Einerseits haben wir es mit Spezifikationen zu tun, die zum Teil noch instabil und im Fluss sind. Andererseits sind viele Techniken schon praktisch nutzbar und für moderne Websites von entscheidendem Vorteil. Standardisierung kommt heutzutage nachher: »Paving the Cowpaths« (Pflastern der Trampelpfade) lautet das Credo der WHATWG. Es ist nicht zu erwarten, dass die Innovationsgeschwindigkeit nachlässt und der Großteil der verwendeten Techniken zu klassischen Recommendations »abkühlt«.

Progressive Enhancement als neues Ziel

Aus diesen Gründen wurde die Konformität zu abgeschlossenen, festen Standards bereits weitgehend abgelöst durch Progressive Enhancement: Webentwickler nutzen Techniken bereits zu ihrem Vorteil und zum Vorteil ihrer Besucher, selbst wenn sie noch keine Standards im strengen Sinne sind und noch nicht einheitlich umgesetzt werden.

Beim Progressive Enhancement rechnet man damit, dass eine Website in Browsern mit unterschiedlichen Fähigkeiten unterschiedlich aussieht und gegebenenfalls ein wenig anders bedienbar ist. Ein verwandtes Konzept ist das Responsive Design, welches ein besonderes Augenmerk auf die Vielfalt der Webzugangsgeräte und deren Bedürfnisse legt.

Progressive Enhancement heißt derweil nicht, sämtliche Qualitätsansprüche und bewährte Verfahren zu verwerfen und beliebige proprietäre und inkompatible Techniken zu verwenden. Es bedeutet, auf vielversprechende Techniken zu setzen, die sich gerade in der Standardisierung befinden und bereits eine gewisse Praxistauglichkeit und Interoperabilität erreicht haben. Techniken, für die es klare Strategien der Anwendung und der Abwärtskompatibilität gibt, für die Polyfills oder Fallback-Lösungen existieren. Der Unterschied einer Website mit Progressive Enhancement zu einer achtlos inkompatiblen und nicht anpassungsfähigen Website liegt darin, dass die alternativen und reduzierten Versionen bewusst geplant wurden und ihre User Experience stimmig bleibt.

Fazit

Die anhaltende technische Innovation hat eine klassische Auffassung von Webstandards-Konformität weitesgehend obsolet gemacht. Es ist für Webentwickler schwerer geworden, sich im Dschungel von entstehenden Standards zurecht zu finden. Sie müssen selbst in Erfahrung bringen, wie sie Techniken sicher und kompatibel verwenden können. Doch sie stehen nicht orientierungslos da: Es wurden längst neue Best Practices entwickelt, die den sinnvollen und robusten Einsatz neuer Techniken ermöglichen.

Links

• Ergänzungsartikel: Die jüngsten Konflikte zwischen W3C und WHATWG
• Übersicht über HTML5-Spezifikationen und -Literatur
• Spezifikationen der W3C-HTML-Arbeitsgruppe
• Spezifikationen der W3C-Web-Apps-Arbeitsgruppe
• Übersicht bei Microsoft über den aktuellen Stand der Standardisierungen
• Übersicht über CSS-3-Spezifikationen
• Blog der CSS-Arbeitsgruppe mit Entscheidungen und Aktualisierungen

Zum Autor

Mathias Schäfer (molily) arbeitet als Web- und Software-Entwickler für 9elements.

3 Formulare

Bei Formularen gibt es über die bereits aufgeführten Techniken hinaus zwei Besonderheiten: Zum einen wird oft zwischen Pflichtfeldern und optionalen Feldern unterschieden, zum anderen muss die Fehlerbehandlung besonders beachtet werden.

3.1 Pflichtfelder

Pflichtfelder werden gerne über Farbe hervorgehoben. Wie für andere Seitenelemente ist auch hier die Verwendung von Farbe empfehlenswert. Die farbige Kennzeichnung von Pflichtfeldern sollte jedoch durch zusätzliche, sichtbare Merkmale ergänzt werden. Die notwendigen Textangaben im LABEL-Element wurden bereits im Abschnitt »Kennzeichnung von Pflichtfeldern« [im Buch] vorgestellt. Einige Möglichkeiten sind das Asterisk, ein Text oder ein grafisches Symbol.

Wenn Pflichtfelder über Farbe gekennzeichnet sind, dann muss eine dieser Möglichkeiten genutzt werden. Dabei geht es nicht um die Zugänglichkeit für Screenreader-Nutzer, sondern ausdrücklich um Sehende bzw. Sehbehinderte.

Wenn beispielsweise ein Asterisk zusätzlich zur Farbe eingesetzt wird, dann sollte bei den (ebenfalls empfehlenswerten) Ausfüllhilfen ein Hinweis der Art »Bitte füllen Sie alle gelben und mit einem Asterisk (*) gekennzeichneten Felder aus« stehen. Das Asterisk ist zwar Konvention, aber wegen der geringen Größe des Zeichens ist es möglicherweise für Menschen mit einer Sehbehinderung nicht erkennbar.

Statt oder in Ergänzung eines solchen Zeichens empfiehlt sich zusätzlicher Text. Pflichtfelder können im zugehörigen LABEL-Element durch »Pflichtfeld« bzw. optionale Felder durch »optional« gekennzeichnet werden:

<p><label for="wert">Mobiltelefon (optional)</label>
<input name="handy" id="wert" type=text" /></p>

Listing 5: Mehrfachkennzeichnung für Pflichtfelder durch Textergänzung

Eine weitere Technik der Mehrfachkennzeichnung besteht in der Verwendung strukturierender HTML-Elemente. Wenn die Beschriftung eines Pflichtfelds über STRONG ausgezeichnet wird, dann wird sie fett dargestellt. Formal genügt das den Anforderungen. In der Praxis kommt es darauf an, ob ein Nutzer mit einer Seheinschränkung dies gut erkennt oder nicht.

Die Vermittlung von Informationen über Farbe allein ist besonders dann kritisch, wenn Inhaltstypen voneinander unterschieden werden sollen. Das folgende Beispiel zeigt die Vermittlung einer wichtigen Information allein über Farbe im Administrationsbereich von DokuWiki (vgl. auch Abb. 8 bzw. 9): »Einstellungen mit einem hellroten Hintergrund sind gesichert und können nicht mit diesem Plug-in verändert werden, Einstellungen mit hellblauem Hintergrund sind Voreinstellungen, weiß hinterlegte Felder zeigen lokal veränderte Werte an. Sowohl die blauen als auch die weißen Felder können verändert werden.«

Abb. 8: Administrationsbereich in einem DokuWiki mit farblicher Kennzeichnung verschiedener Typen von Steuerelementen

Bei benutzerdefinierten Bildschirmfarben ist dieses Formular nicht mehr bedienbar:

Abb. 9: Bei benutzerdefinierten Farben ist der Administrationsbereich des DokuWiki nicht mehr bedienbar.

3.2 Fehlermeldungen

Fehlermeldungen müssen unter dem Gesichtspunkt der Mehrfachkennzeichnung sorgfältig gestaltet werden. Fehlerbeschreibungen und Hilfen müssen nicht nur vorhanden, sondern auch wahrnehmbar sein. Es sind die Hinweise, Fehlermeldungen und Ausfüllhilfen, die es Nutzern ermöglichen, Logins, Bestellungen oder auch Online-Banking erfolgreich vornehmen bzw. abschließen zu können.

Eine über Farbe vermittelte Fehlermeldung wird deswegen durch zusätzliche Formatierungen (Schriftschnitt), Symbole oder Rahmen ergänzt. Hinweise wie »Fehlermeldungen in roter Farbe« sind nicht barrierefrei. Eine bessere Fehlermeldung ist: »Falsche Eingaben sind in Rot und fetter Schrift gekennzeichnet«.

Symbole für Fehlermeldungen sind ebenfalls positiv zu bewerten. Allerdings müssen allein stehende Symbole (ohne ergänzenden Text) im HTML stehen und dürfen nicht mittels CSS generiert werden, da sie wichtige Informationen transportieren. Außerdem müssen sie allgemein verständlich sein, wie z.B. ein Dreieck mit einem Ausrufezeichen.

Eine interessante Technik zur Mehrfachkennzeichnung fehlerhafter Eingaben wird beim Webangebot von »Sozialnetz Hessen« verwendet. Hier wird bei Fehleingaben das auch bei benutzerdefinierten Farbeinstellungen sichtbare FIELDSET-Element in Kombination mit LEGEND eingesetzt. Die Rahmen des FIELDSET-Elements werden dabei nicht unterdrückt und die Fehlermeldung hebt sich somit vom umgebenden Inhalt ab:

Abb. 10: In drei von vier Feldern werden fehlende Eingaben mithilfe von FIELDSET und LEGEND hervorgehoben.

Mit dieser Form der Mehrfachkennzeichnung ist die Sichtbarkeit der fehlerhaft ausgefüllten Eingabefelder für alle Nutzer gleichermaßen gewährleistet. Sie sind bei benutzerdefinierten Farben erkennbar und zudem mit Screenreadern aufgrund der verwendeten HTML-Technik eindeutig identifizierbar.

Das Buch

Der Text ist ein Auszug aus »Barrierefreiheit verstehen und umsetzen – Webstandards für ein zugängliches und nutzbares Internet« von Kerstin Probiesch und Jan Eric Hellbusch. Das Buch ist im dpunkt.verlag erschienen. Wir veröffentlichen daraus das Kapitel »Mehrfachkennzeichnung in der Praxis«. Außerdem verlosen wir drei Exemplare.

Die Autoren

Jan Eric Hellbusch und Kerstin Probiesch sind beide freiberufliche Berater für barrierefreies Webdesign; sie beraten Unternehmen und Behörden und schulen Programmierer und Webredakteure. Nach seinem BWL-Studium war Jan Eric Hellbusch in verschiedenen Organisationen im Bereich »Internet« tätig. Seit 2000 veröffentlicht er Beiträge einschließlich zweier Bücher zur Barrierefreiheit im Web. Kerstin Probiesch prüft als freie Accessibility-Spezialistin Webseiten auf WCAG 2.0-Konformität, schreibt Fachartikel und begleitet beratend die Entwicklung barrierefreier Webangebote von der Konzeptionsphase an.

2. Inhalte

Die Mehrfachkennzeichnung beschränkt sich nicht auf Links. Ob Überschriften oder Tabellen, es gibt zahlreiche Inhaltstypen, die oft über Farbe allein und ohne zusätzliche Formatierung gestaltet werden. Im Folgenden werden einige typische Barrieren beschrieben, die insbesondere in Inhaltsbereichen entstehen können.

2.1 Überschriften

In der Regel werden Überschriften im Inhaltsbereich visuell durch Schriftgröße, Fettung und Farbe hervorgehoben. Während eine Hauptüberschrift i.d.R. größer als der Fließtext gestaltet wird, werden – je tiefer ein Dokument strukturiert ist – die Überschriftenebenen oft nur noch durch Farbe und somit nicht ausreichend gekennzeichnet.

Überschriften sind markante Informationspunkte. Sie ziehen die Aufmerksamkeit auf sich und geben im Idealfall eine Information über den nachstehenden Text. Zudem vermittelt die Überschriftenhierarchie, wo in der inhaltlichen Gliederung ein Text einzuordnen ist. Deswegen müssen Überschriften auf der Strukturebene entsprechend ihrer Hierarchie im HTML ausgezeichnet werden. Die Anforderung gilt selbstverständlich auch im Kontext der visuellen Wahrnehmung. Überschriftenebenen müssen unabhängig von einzelnen Formatierungen wie Farbe erkennbar sein.

Eine Möglichkeit, Überschriften hervorzuheben, ist über vorangestellte Symbole. Für jede vorhandene Überschriftenebene kann ergänzend zur Textgestaltung ein Symbol eingebunden werden, vgl. Listing 2.

h1, h2, h3, h4 {
padding: 5px 0px 5px 25px;
display: list-item;
margin-left : 20px;
}
h1 {
list-style-image:url('lib/img/h1.gif');
}
h2 {
list-style-image:url('lib/img/h2.gif');
}
h3 {
list-style-image:url('lib/img/h3.gif');
}
h4 {
list-style-image:url('lib/img/h4.gif');
}

Listing 2: CSS für vorangestellte Symbole bei Überschriften

Eine weitere Möglichkeit ist, Überschriften zusätzlich mit einem Rahmen auszuzeichnen, der links vor der Überschrift platziert wird. Horizontale Rahmen unterhalb der Überschriften sind ungeeignet, da sie wie Unterstreichungen wirken und als Links interpretiert werden könnten.

Natürlich kann mit Schriftgröße, Einrückungen und anderen Formatierungen (in Ergänzung zu Farbe) gearbeitet werden. Für die sechs Überschriftenebenen ist darauf zu achten, dass sie sich unabhängig von der Farbe unterscheiden. Bei längeren Dokumenten mit einer nummerierten Gliederung kann jedoch auf zusätzliche Formatierungen verzichtet werden, sofern die Ordnungszahlen der Gliederung nachvollziehbar sind.

2.2 Listen

Bei Aufzählungen und Listen kann es erwünscht sein, die Aufzählungspunkte durch CSS-Grafiken zu ersetzen. Dies ist unproblematisch, solange diese Grafiken keine Informationen transportieren. Wenn jedoch verschiedene Symbole zur Unterscheidung von Listeneinträgen eingesetzt werden, dann muss sichergestellt sein, dass die Bedeutung der Symbole klar ist. Ist dies nicht der Fall, dann ist ein weiterer beschreibender Text nötig, denn für über CSS eingebundene Grafiken gibt es keine Möglichkeit, Alternativtexte zu vergeben.

Bei verschiedenfarbigen Aufzählungszeichen (z.B. »rote und grüne Punkte«) kann ergänzend zur Farbe eine Form verwendet werden, etwa rote Kreise und grüne Quadrate. Werden unterschiedliche Symbole als Informationsträger in Listenpunkten eingesetzt, muss die Barrierefreiheit durch weitere Maßnahmen sichergestellt werden.

In einem anderen Beispiel haben wir eine Liste mit vier Links durch Grafiken ergänzt. Die ersten drei Grafiken waren identisch, aber die vierte Grafik machte deutlich, dass der nachstehende Link zu einer anderssprachigen Seite führt. Der letzte Eintrag wurde mit unsichtbarem Text ergänzt. Das ist so lange sinnvoll, wie der restliche Text einer Seite deutsch ist: Auf einer französischsprachigen Seite wäre es sinnvoll, auch die Links zu deutschsprachigen Seiten zu kennzeichnen.

2.3 Hervorhebungen im Fließtext

Zusätzlich zu einer Vermittlung durch Symbole oder über Farben können typografische Merkmale wie eine andere Schriftart und Schriftgröße, Unterstreichungen oder Durchstreichungen zum Hervorheben einzelner Inhalte eingesetzt werden. Die Verwendung von Farbe ist auch hier empfehlenswert, solange sie nicht der einzige Informationsträger ist.

Wenn Texte kollaborativ – z.B. in einem Wiki – geschrieben werden, können unterschiedliche Versionen angezeigt und eingefügte sowie gelöschte Texte eingesehen werden. Diese Informationen werden oft nur über Farbe vermittelt.

Abb. 5: Eingefügte und gelöschte Texte werden durch Hintergrund- und Vordergrundfarben hervorgehoben.

Auch hier sind zusätzliche Formatierungen im Sinne einer Informationsvermittlung über mehrere Wege nötig. Eine Lösung wäre, die Textpassage sowohl in Rot als auch fett darzustellen – wobei die Fettung selbstverständlich mit HTML geschehen sollte – und wie folgt darauf zu verweisen: »Textänderungen sind in Rot und fett dargestellt.«

Auf der Strukturebene könnte ein eingefügter oder gelöschter Text mit einem STRONG-Element ausgezeichnet sein. Wird jedoch das STRONG-Element auch zur Hervorhebung anderer Texte genutzt, dann lässt sich die »normale« Hervorhebung nicht mehr von der für geänderte Texte unterscheiden. Die nach der HTML-Spezifikation für diesen Zweck vorgesehenen INS- und DEL-Elemente sind nicht geeignet. Sie werden von Screenreadern nicht ausgewertet und sind daher nicht zugänglichkeitsunterstützend.

In einem solchen Fall ist es am besten, Versionsunterschiede direkt im Fließtext zu kennzeichnen und dies bereits im Screendesign zu berücksichtigen, z.B. indem solche Bereiche so gestaltet werden, dass neben einer Textfarbe die geänderten Stellen vorher und hinterher ergänzt werden.

Abb. 6: Veränderungen im Dokument werden mit Farbe und Text gekennzeichnet.

2.4 Farbig hinterlegte Bereiche

Auf Webseiten werden oft Informationskästen für ergänzende oder hervorgehobene Informationen verwendet. Sie können allgemeine Hinweise, Merksätze, Linklisten u.v.m. enthalten. Meist werden solche Bereiche über Farbe (z.B. einen grauen Hintergrund) gekennzeichnet. Auch solche Informationskästen und ähnliche Seitenelemente benötigen zusätzliche Erkennungsmerkmale. In der Regel reicht ein Rahmen, hilfreich sind aber auch Bezeichnungen.

Wenn Absätze oder andere Textblöcke durch eine veränderte Farbe hervorgehoben werden, gehört auf der Strukturebene eine vorangestellte Überschrift als Bezeichnung zu den Minimalanforderungen.

<div class="hinweis">
<h2>Benötigen Sie Hilfe?</h2>
<p>Einige Fragen und Antworten finden Sie in der <a href="#">Hilfe</a>.</p>
<p>Einige Begriffe finden Sie im <a href="#">Glossar</a> erläutert.</p>
</div>

Listing 3

Auch sollte der Informationskasten einen ergänzenden, umschließenden Rahmen erhalten. Da er bei benutzerdefinierten Farben erkennbar ist, kann er die gleiche Farbe wie die farbige Hinterlegung selbst erhalten:

.hinweis {
padding: 1em;
width: 320px;
height: 400px;
border: 2px solid #eee;
overflow: auto;
float: left;
margin: 0 2em 1em 0;
background-color: #eee;
}

Listing 4: border-Technik für Info-Kästen

Ohne die border-Eigenschaft wird ein Info-Kasten bei benutzerdefinierten Farben nicht gut von anderen Inhalten zu differenzieren sein. Mit einem Rahmen kann die Hervorhebung hier sichergestellt werden, wie im untersten Bild von Abbildung 7 zu sehen ist.

Abb. 7: Eine farbliche Hervorhebung kann durch einen Rahmen bei benutzerdefinierten Farben besser wahrgenommen werden.

2.5 Tabellen

Auch in Tabellen können verschiedene Maßnahmen der Mehrfachkennzeichnung berücksichtigt werden. Ein Beispiel sind Spalten- und Zeilenüberschriften: Die farbige Gestaltung von Kopfzellen fördert die Leserlichkeit, aber durch Fettung und/oder Zentrierungen oder andere Ausrichtungen können die Zellen auch unabhängig von der Farbe visuell hervorgehoben werden.

Vor dem Hintergrund benutzerdefinierter Bildschirmfarben sollte auch bei der Gestaltung von Tabellen auf einige wenige weitere Zeilen CSS geachtet werden, um die Wahrnehmbarkeit zu fördern.

Sind beispielsweise in einer Datentabelle die Reihen abwechselnd nur mit zwei unterschiedlichen Hintergrundfarben gestaltet (Zebratabellen), dann geht diese visuelle Leseunterstützung bei benutzerdefinierten Farben verloren. Auch wenn die Tabelle noch zugänglich ist, kann das Lesen durch weitere Maßnahmen gefördert werden. Eine sehr einfache Technik sind Rahmen für Tabellenzellen bzw. -reihen, die in der gleichen Farbe wie der Zellenhintergrund gehalten sein können und bei benutzerdefinierten Farben Orientierungsmöglichkeiten in langen Datentabellen bieten. Dies ist vor allem bei wichtigen Informationen in großen Tabellen sinnvoll.

2.6 Grafiken

Auch in Schaubildern (z.B. Kursverläufe in Charts, Diagrammblöcke) darf nicht allein durch Farbe unterschieden werden. Neben Farbe können hier ergänzend Muster (z.B. eine gestrichelte rote und eine durchgezogene blaue Kurve) eingesetzt werden. Dies ist besonders bei Farben wichtig, die für farbfehlsichtige Menschen problematisch sind.

Um etwa in einem Geschäftsbericht die Gewinne und Verluste darzustellen, darf sich nicht allein auf eine farbige Markierung der Zahlen verlassen werden: Rot für negative Zahlen und Schwarz für positive Zahlen reicht nicht aus. Empfehlenswert ist hier ein zusätzliches Plus- bzw. Minuszeichen vor den jeweiligen Zahlen. Darstellungen von Flächen (z.B. Zufriedenheit oder Unzufriedenheit mit einem bestimmten Produkt) sind durch weitere Merkmale zu ergänzen, vor allem wenn für die Flächen die Farben Rot und Grün verwendet werden. Für diesen Fall bietet sich eine Schraffierung für eine der beiden Flächen an.

Das Buch

Der Text ist ein Auszug aus »Barrierefreiheit verstehen und umsetzen – Webstandards für ein zugängliches und nutzbares Internet« von Kerstin Probiesch und Jan Eric Hellbusch. Das Buch ist im dpunkt.verlag erschienen. Wir veröffentlichen daraus das Kapitel »Mehrfachkennzeichnung in der Praxis«, morgen erscheint der dritte Teil. Außerdem verlosen wir drei Exemplare.

Zur Erinnerung – Inhalte müssen in den folgenden zwei Fällen wahrgenommen werden können:

• Wenn die Formatierung abgeschaltet ist oder nicht wahrgenommen werden kann, dann muss das HTML oder ein Text den Unterschied zum umgebenden Inhalt verdeutlichen.
• Wenn eine Formatierung durch den Nutzer überschrieben wird, dann muss eine zusätzliche Formatierung oder ein Text den Unterschied zum umgebenden Inhalt am Bildschirm verdeutlichen. Bei Farbe werden dabei Vordergrund- und Hintergrundfarbe als die gleiche Formatierung behandelt.

1. Links

Die Gestaltung von Links, vor allem auf der Struktur- und Textebene, wurde bereits ausführlich behandelt. Im Kontext der Mehrfachkennzeichnung kommen weitere Anforderungen hinzu. Damit Links in Fließtexten auch ohne Farbe erkennbar sind, benötigen sie eine Unterstreichung, eine Fettung oder eine andere sichtbare Hervorhebung. Linktexte müssen sich außerdem sowohl vom Hintergrund als auch vom umgebenden Fließtext deutlich abheben. Das bedeutet, dass die verwendeten Farben für Links gegenüber den Fließtexten ein Kontrastverhältnis von mindestens 3:1 aufweisen sollten.

Darüber hinaus gibt es besondere Maßnahmen, um Hervorhebungen bei benutzerdefinierten Farben zu optimieren. Bereits einige wenige CSS-Auszeichnungen können einen positiven Einfluss auf die Wahrnehmbarkeit haben, ohne in das Layout einzugreifen.

1.1 Unterstreichung oder nicht?

Ob ein Link unterstrichen werden soll oder nicht, ist oft Geschmackssache. Manchmal wird die Unterstreichung in den CSS unterdrückt, weil unterstrichene Links den Lesefluss stören können oder aus Layoutgründen nicht erwünscht sind. Die Links sind dann zwar meist farbig hervorgehoben, haben aber abgesehen davon die gleiche Schriftart und den gleichen Schriftschnitt wie der umgebende Fließtext.

Nur über Farbe gekennzeichnete Links haben meist einen Mouse-over-Effekt, der eine Unterstreichung bewirkt. Offenbar ist Designern klar, dass ein Link ohne Unterstreichung nicht automatisch als Link erkannt wird. Ein solcher Hover-Effekt reicht jedoch nicht, denn er setzt voraus, dass der Link identifiziert werden und der Nutzer ein Zeigegerät bedienen kann. Kann er aber aufgrund der Farbgebung einen Link nicht sehen, dann wird er ihn auch nicht mit der Maus ansteuern. Ein typisches Beispiel sind Links in roter Farbe, die bei einer Rotblindheit als Dunkelgrau oder gar Schwarz wahrgenommen werden können.

Abb. 1 und 2: Farbige Links im Fließtext benötigen mindestens eine weitere Formatierung.

Ist eine Unterstreichung nicht vorgesehen oder durchsetzbar, dann können Links zusätzlich fett formatiert und/oder durch Symbole ergänzt werden. Eine weitere Möglichkeit ist der Verzicht auf Links in Fließtexten und eine Auflistung dieser als Linkliste »Weiterführende Links« am Ende des Inhalts. Auch ein Style Switcher oder Color Picker, für das Umstellen der Farben, kommt in Betracht. Links im Fließtext können unabhängig von einer Unterstreichung den Lesefluss stören. Obwohl es in den WCAG20 keine Anforderung gibt, die den Verzicht auf Links in Fließtexten nahelegt, muss dennoch über die Alternative einer Linkliste am Ende eines Artikels nachgedacht werden. Vor allem wenn Texte viele Links enthalten, kann die Umschaltung zwischen der Anzeige von Links im Fließtext und der Anzeige als ausführliche Linkliste am Ende des Dokuments sinnvoll sein.

Eine am Ende eines Textes platzierte Linkliste ist nicht nur eine Lösung im Sinne der Mehrfachkennzeichnung, sondern hilft außerdem die Anforderung an aussagekräftige Linktexte zu erfüllen, denn: Linktexte wie »hier« oder »mehr« sind dann nicht mehr möglich. Auch Brigitte Bornemann kommt in ihrem Artikel »Farbkontraste nach WCAG20« zum Schluss, dass auf Links im Fließtext zugunsten einer Linkliste verzichtet werden kann [1].

1.2 Unterschiede im Kontrastverhältnis

Links in Fließtexten sollten deutlich erkennbar sein und gegenüber dem umgebenden Text ein Kontrastverhältnis von mindestens 3:1 aufweisen. Wenn beispielsweise der Fließtext schwarz auf Weiß ist, dann ist das Kontrastverhältnis des Fließtextes zum Hintergrund 21:1; nach den WCAG20 sollte das Kontrastverhältnis für Links im Fließtext dann zwischen 7:1 (erweiterte Mindestanforderung an Kontrastverhältnisse) und 18:1 liegen.

Diese doppelte Anforderung an Links, d.h., ausreichendes Kontrastverhältnis zum Hintergrund und ausreichendes Kontrastverhältnis zum umgebenden Fließtext, unterstreicht die Bedeutung von Links als wichtiges Navigationselement. Gleichzeitig führt sie dazu, dass das »erlaubte« Farbschema eingeschränkt wird.

Wie so oft bei der Umsetzung der Barrierefreiheit ist auch die Anforderung nach ausreichenden Kontrastverhältnissen kein absolutes Kriterium, sondern von anderen Faktoren abhängig. Ist z.B. ein Link unterstrichen, dann muss diese Anforderung nicht unbedingt erfüllt werden, denn der Link ist bereits auf anderem visuellem Weg erkennbar. Gleiches gilt, wenn sich Links nicht im Fließtext, sondern in einer Linkliste am Ende des Textes befinden. Welche dieser Lösungen auch gewählt wird, es geht darum, durch bessere Lesbarkeit der Links den Spielraum des Farbdesigns zu bewahren.

1.3 border-Technik für Navigationslinks

Auch in Navigationsleisten sollten Links nicht nur über die Farbe erkennbar sein. Wenn die aktuelle Seite in der Navigation hervorgehoben wird, so wird dies oft durch eine Veränderung der Hintergrundfarbe, der Vordergrundfarbe oder beider signalisiert. Auch hier gilt: Haben Nutzer eigene Farbschemata eingestellt, dann sind die Hervorhebungen nicht mehr erkennbar und es muss mindestens ein weiteres Erkennungsmerkmal vorgesehen werden. Das kann eine Veränderung des Schriftschnitts, z.B. eine Fettung, oder ein vorangestelltes Symbol (mit geeigneten Alternativtexten für die Textebene) sein. Eine weitere und bewährte Technik sind sichtbare oder unsichtbare CSS-Rahmen (border).

An dieser Stelle werfen wir einen Blick auf die Gestaltung der Hauptnavigation unseres Beispielauftritts. Die optische Hervorhebung des aktuellen Navigationseintrags erfolgt über Farbe sowie eine CSS-Hintergrundgrafik. Die Vermittlung der Information (»Ich bin kein Link!«) muss durch weitere Merkmale ergänzt werden. Diese wurden im Layout berücksichtigt (vgl. Abb. 3).

Abb. 3: Hervorhebung eines Menüeintrags durch einen farbigen Balken (oben) und einen Pfeil (unten)

Beide Techniken sind auf der rein visuellen Ebene und bei Standardfarben für die Anforderung an Mehrfachkennzeichnung ausreichend, nicht jedoch bei benutzerdefinierten Farbeinstellungen. Der Balken oberhalb des Eintrags wird mit einer Hintergrundgrafik bewirkt, die bei benutzerdefinierten Farben nicht sichtbar sein wird. Der Pfeil wurde ebenfalls über CSS als Hintergrundgrafik eingebunden und wird ebenfalls nicht sichtbar sein.

So schön die Hervorhebung durch Symbole also ist: Werden sie als Hintergrundgrafiken eingebunden, dann wird zur Anzeige der aktuellen Position in der Navigation mindestens ein weiteres Unterscheidungsmerkmal benötigt.

Wir greifen hier auf die bereits erwähnte und bewährte CSS-Eigenschaft border zurück, denn sie wird bei benutzerdefinierten Farbeinstellungen in der vom Nutzer eingestellten Textfarbe dargestellt. Das gilt vor allem für den Internet Explorer und für Mozilla-Browser. Der Rahmen ist also ein ausgezeichnetes Mittel, um einen Hinweis über den Zustand eines Navigationseintrags zu vermitteln. Dieser zusätzliche Rahmen muss bei Standardfarben nicht sichtbar sein, weil in diesem Fall die Symbole zu sehen sind.

Die CSS-Gestaltung wird wie folgt ergänzt:

#navigation ul li.aktiv a {
border-color: #6392a9;
background-position: 0px 0px;
border-top: 6px solid #517C8F;
padding: 1.2em 1.8em 1.5em 1.8em;
background-color: #535353;
}
#navigation ul li.aktiv a:hover,
#navigation ul li.aktiv a:focus,
#navigation ul li.aktiv a:active {
padding: 1.2em 1.8em 1.5em 1.8em;
background-color: #535353;
border-top: 6px solid #ddd;
background-position: 0px 0px;
}

Listing 1: CSS-Eigenschaften für die border-Technik in der Hauptnavigation

Die Haupteinträge erhalten zur Verdeutlichung der Hierarchie eine obere Rahmendicke von 6px. Die Rahmenfarbe ist dieselbe wie die Hintergrundfarbe und nur bei benutzerdefinierten Farbeinstellungen sichtbar. In unserem Beispiel erfolgt die Mehrfachkennzeichnung also über Farbe, über ein Symbol und über Rahmen. Das Symbol ist bei Standardfarben sichtbar und die Rahmen sind bei benutzerdefinierten Bildschirmfarben erkennbar. Diese Hervorhebung wird dann auch für den Tastaturfokus und den Hover-Effekt berücksichtigt.

Abb. 4: Der aktive Menüpunkt bleibt bei benutzerdefinierten Farben wahrnehmbar

Auf die Border-Technik kann verzichtet werden, wenn die Symbole statt als Hintergrundgrafik als Listenaufzählungspunkte verwendet werden oder direkt in das HTML eingebunden sind. Die Symbole dienen als Informationsträger (»Aktueller Bereich«) und die Information muss selbstverständlich auch bei ausgeschaltetem CSS wahrnehmbar sein. Für den aktiven Eintrag reicht im Normalfall die Nichtverlinkung, aber ein zusätzlicher Text fördert die Nutzbarkeit.

[1] Vgl. Bornemann, B., Farbkontraste nach WCAG20.

Das Buch

Der Text ist ein Auszug aus »Barrierefreiheit verstehen und umsetzen – Webstandards für ein zugängliches und nutzbares Internet« von Kerstin Probiesch und Jan Eric Hellbusch. Das Buch ist im dpunkt.verlag erschienen. Wir veröffentlichen daraus das Kapitel »Mehrfachkennzeichnung in der Praxis«, morgen erscheint der zweite Teil. Außerdem verlosen wir drei Exemplare.

Dreamweaver ist ein mächtiges Werkzeug. Es wartet von Hause aus schon mit vielen Funktionen und Shortkeys auf. Trotzdem kommt irgendwann die Situation, in welcher der Entwickler einen Shortkey und eine bestimmte Automatisierung vermisst. Die begrenzte Funktionalität der Snippets kann da nicht immer weiterhelfen. Um meinen Workflow zu optimieren und nervige Tipperei zu vermeiden möchte ich meine eigene Funktion schreiben und diese auf ein Tastaturkürzel legen.
Hier kommt die API ins Spiel. Über sie bin ich in der Lage, das Programm zu reorganisieren, meinen Bedürfnissen anzupassen und um fehlenden Funktionen zu erweitern oder bestehende umzuschreiben.

Die Vorbereitung

Um zu starten brauchen wir natürlich in erster Linie den Adobe Dreamweaver (zum Probieren reicht auch erstmal eine Dreamweaver CS5-Testversion). Befehle in Dreamweaver bestehen aus zwei Komponenten – einer HTML- und einer JavaScript-Datei – und sie werden über einen XML-Baum in die Benutzeroberfläche eingebunden. Grundkenntnisse in den drei Bereichen erleichtern den Einstieg erheblich.

Desweiteren muss nach der Installation der »Dreamweaver«-Ordner mit den Unterordnern »Configuration« und weiter »Menus« auf der Festplatte ausfindig gemacht werden. Dieser befindet sich nicht im Installationsordner, sondern in den Benutzer- bzw. User-Ordnern (bei Vista z. B. C:\Users\"Name"\AppData\Roaming\Macromedia\Dreamweaver\Configuration\Menus).

Um Problemen vorzubeugen, sollte vorher eine Kopie der aktuellen Datei menus.xml angelegt werden.

Ladet nun die vorbereitete zip-Datei (52 KB) herunter und kopiert den Inhalt in den Menus-Ordner. Die neuen Befehle werden nach dem nächsten Start von Dreamweaver angezeigt und sind aktiv.
Um die folgenden Erläuterungen besser nachvollziehen zu können, sollten alle Dateien des entpackten ZIPs mit Dreamweaver geöffnet werden.

Ärmel hochkrempeln und los geht's!

Dem aufmerksamen Beobachter fällt natürlich sofort der neue Menüpunkt in der horizontalen Menüleiste auf. Beim anklicken von »Webkrauts« öffnet sich ein Dropdown mit »ListAll«, »BreakAll« und »AllToNav« und den zugewiesenen Shortkey. Wenn wir jetzt mehrere Zeilen Text markieren und zum Beispiel Strg+Alt+D drücken oder den entsprechenden Menüpunkt auswählen, werden automatisch die Zeilenumbrüche erkannt und in Listenpunkte umgewandelt. Das Gleiche gilt für die Funktionen »BreakAll« (erzeugt einen br am Zeilenende) und »AllToNav«, welche die Listenfunktion »ListAll« erweitert und einen Anchor-Tag ergänzt, um die Basis für eine Navigation zu erstellen.

Diese vorgefertigten Befehle dienen natürlich nur als Beispiele für den Einstieg. Ich denke, je nach Ausprägung der JavaScript-Kenntnisse lässt sich da allerhand anstellen und es sind nicht nur HTML-Tags möglich.

So werden die Befehle angewendet – Screencast

Dreamweaver liest den Code im Bearbeitungsfenster genau wie den Quellcode einer Internetseite. Dadurch wird die direkte Manipulation durch JavaScript erst möglich. Bevor die Befehle also greifen können, muss Dreamweaver das DOM vollständig erfasst haben. Sollte mal keine Reaktion auf die Befehle erfolgen, hilft deshalb ein Klick auf den Button »Aktualisieren«. Das gilt allgemein für die Anwendung von Funktionen in Dreamweaver.

Der neue Befehl

Befehle in Dreamweaver bestehen immer aus zwei Komponenten: einer HTML- und einer JavaScript-Datei. Die HTML-Datei ist lediglich dafür zuständig, die Javascript-Datei zu laden, einzubetten und die entsprechende Funktion im Body-Tag durch »onLoad« auszuführen. Wichtig ist es, daran zu denken, die Bezeichnungen der Datei und der Funktion hier anzupassen.

Der HTML-Code am Beispiel der ListAll()-Funktion sieht (etwas gekürzt) so aus:

<head>
<title>Listen erstellen </title>
<script language="JavaScript" src="ListAll.js">
Menu_HC_AddLineBreaks = dreamweaver.latin1ToNative("Listen erstellen <br>");
</script>
</head>
<body onload="ListAll()">
</body>
</html>

Die JavaScript-Datei dagegen enthält die Programmierung für den Befehl. Hier bekommen wir es mit allerhand Dreamweaver-spezifischen Funktionen zu tun. Die Funktion »canAcceptCommand()« testet zum Beispiel, ob das Menüelement abgeblendet werden soll (Rückgabe: false) oder aktiv geschaltet wird. Außerdem wird hier noch festgestellt, auf welchem Teil innerhalb von Dreamweaver der Eingabefokus liegt (»dw.getFocus()«) und die Selektion aus dem DOM ausgelesen (»dw.getDocumentDOM()«).
Diese komplette erste Funktion ist ein Standard und muss für unsere Zwecke nicht modifiziert werden. Wer will, kann sich im API-Referenzhandbuch unter der »Hilfe« damit näher befassen.
Den Kern bildet die jeweils zweite Funktion »ListAll()«, »BreakAll()« bzw. »AllToNav()« und hier können wir uns austoben. Jeder, der Grundkenntnisse in JavaScript besitzt, kann leicht nachvollziehen was hier passiert. Kurz beschrieben am Beispiel der Funktion »ListAll()«:

1. Zuerst wird die Selektion im DOM aufgerufen.
2. Es werden die Zeilenumbrüche durch </li>\n\t<li> ersetzt. Bei \n und \t handelt es sich um Regular Expressions für einen Zeilenumbruch und einen Tab.
3. Am Ende der Liste wird </li>\n</ul> eingefügt.
4. Am Anfang der Liste wird <ul>\n\t<li> eingefügt.

Für eine bessere Übersicht habe ich die wichtigsten Zeilen nochmal in der Datei kommentiert. Ein Blick auf den Quellcode der jeweiligen Datei verdeutlicht, wie sie modifiziert wird. Wer will, kann hier auch seine eigene Funktion einmal ausprobieren. Man kann nicht viel kaputt machen.

Der neue Menüpunkt

Die dritte und letzte Datei im Bunde ist eine .xml-Datei (menus.xml). Sie hat mit dem Befehl selbst nichts zu tun, denn hier werden alle Menüs und ihre Inhalte samt Shortkeys festgelegt und beim Start von Dreamweaver initiiert. Über diese Datei lässt sich die gesamte Menüstruktur und ihre Funktionen sowie deren Tastaturkürzel reorganisieren. Der Aufbau des XML-Baums ist leicht nachzuvollziehen.
Ganz am Ende der Datei habe ich unsere zusätzlichen Menüpunkte eingefügt. Ein neuer Hauptmenüpunkt wird in unserem Beispiel mit <menu id="Webkraut_Edit" name="Webkrauts"> erstellt und alle Unterpunkte mit <menuitem id="WK_Edit_ListAll" name="ListAll" key="Cmd+Alt+L" file="Menus/ListAll.htm" arguments="'ListAll'" /> aufgelistet. Dabei gilt: »key« bezeichnet den Shortkey, »file« den Pfad und Dateinamen der HTML-Datei und »name« den Menüeintrag. Der Pfad kann beliebig angegeben werden. Ab einer gewissen Anzahl von eigenen Funktionen sollte man über eine eigene Ordnerstruktur nachdenken. Will man ein eigenes Tastaturkürzel anlegen, sollte man mit der Suchfunktion vorher prüfen, ob es wirklich noch nicht anderweitig genutzt wird.

Der neue Menüpunkt und seine Funktionen und überhaupt alle Änderungen werden immer erst nach dem nächsten Start von Dreamweaver initiiert.

Lust bekommen?

Ich hoffe ich konnte mit diesem Artikel einen schnellen Einstieg in ein komplexes Themengebiet schaffen, dessen Vertiefung durchaus lohnenswert ist. Die Idee, sich mit der API von Dreamweaver zu befassen und das Programm ein wenig anzupassen, entstand mit der Version 8. Die neuen Funktionen habe ich einfach in Version CS3 migriert. Bleibt abzuwarten welche Möglichkeiten sich mit Version CS5 ergeben werden.

Die Dateien als .zip-Archiv zum downloaden

Webkrauts_Menue.zip (52 KB)

Weiterführende Links

Accessing Dreamweaver's JavaScript API
Dreamweaver erweitern

Extending Dreamweaver CS4

Zum Autor

Henry Zeitler ist gelernter Mediengestalter und arbeitet als Webproducer in Düsseldorf. Barrierefreiheit, Semantik und Codeoptimierung haben sich zu seiner Leidenschaft entwickelt, die über das berufliche Engagement hinaus geht. In seinem privaten Blog Freizeitler.de veröffentlicht er Experimente und Erkenntnisse.

Dieser Text erschien zuerst im Webstandards-Magazin 01/2009.

Das Letzte, das der Nutzer eines Online-Shops vor dem Button »Bestellung absenden« zu sehen bekommt, ist der so genannte Warenkorb. Der Warenkorb stammt, wie die meisten anderen Elemente eines Shopsystems, aus dem Bereich des klassischen Einkaufserlebnisses in einem Ladengeschäft und wird meist in Form einer Datentabelle generiert und angezeigt.

Da der Warenkorb die Summe der im Shop gesammelten Waren bildet, sollte er im Idealfall noch einmal den Kaufanreiz erhöhen, wirklich alle Produkte auch tatsächlich zu bestellen. Diese Funktion wäre also mit der Wirkung eines perfekt dekorierten Hochzeitstisches zu vergleichen, auf dem ein Brautpaar alle gewünschten Objekte der Kaufbegierde von Deko-Spezialisten des Ladengeschäftes so präsentieren lässt, dass die Gäste möglichst viel und gerne einkaufen.

Nutzer besitzen also nicht nur ein Grundrecht auf angemessene Gestaltung des Warenkorbs – es ist auch verkaufsfördernd, auf eine benutzerfreundlich und motivierend gestaltete Produktanzeige zu achten. Soweit jedenfalls die schöne Theorie.

Der Warenkorb als Datenkasten

Betrachten wir uns die Praxis vieler Online-Shopsysteme, begegnet uns leider oft genug ein Warenkorb, der ein ähnlich sprödes Einkaufserlebnis vermittelt, wie der verregnete Spaziergang durch eine ostrussische Plattenbausiedlung im November. Da empfängt uns ein Tabellenkonstrukt mit Rändern, die wie Eisenstäbe die sprichwörtlichen Zellen umschließen, einbetoniert in das kahle Nichts einer trostlosen Seite. Die Hintergrundfarbe solcher Tabellen reicht von depressivem Eternitgrau bis zu tristem Bahndammgrün, macht aber auch vor großen Flächen in Windows-95-Blau und Feuerlöscherrot keinen Halt. Kurz gesagt: Allein das Vorhandensein solcher Warenkörbe grenzt für sensible Nutzer an optische Körperverletzung und sorgt schon vor dem Bestellvorgang eher für Frust als für positive Kaufanreize.

Moderne Webseiten trennen den Inhalt strikt vom Design. Die Ausgabe der HTML-Tabellen können Sie deshalb bequem per CSS optisch ansprechend gestalten. Der hier vorgestellte Umfang der Gestaltung richtet sich freilich auch nach der Flexibilität Ihres Shopsystems.

HTML stellt uns zunächst verschiedene Elemente zur Strukturierung von Tabellen zur Verfügung. Neben <td>, <tr> und <tbody> gibt es mit <thead> und <tfoot> die weniger bekannten Kopf- und Fußelemente einer Tabelle, die vor den Inhalten von <tbody> steht.

Exkurs: Tabellen und Barrierefreiheit

Man sollte bei Tabellen nicht nur die gestalterischen Aspekte betrachten, bei der Planung ist auch auf eine barrierefreie Umsetzung für Menschen mit Behinderungen zu achten. Ideal ist es, wenn Ihr Warenkorb mit dem Element <caption> eine sinnvolle Überschrift zu Beginn der Produkttabelle bietet, und das Element summary im <table>-Tag assistiven Technologien ein rasches Auslesen einer Zusammenfassung erlaubt. Mit dem Attribut scope kann man Tabellenbereiche schließlich noch für assistive Technologien so zusammenfassen, dass beispielsweise Screenreader-Nutzer vorhandene Zelleninformationen der entsprechenden Kopfzeile zuordnen können. Dieser Bezug wird durch col oder row festgelegt, je nachdem ob die Kopfzeilen sich auf Spalten oder Zeilen beziehen.

Eine neue Digitalkamera

Als einfaches Beispiel soll hier der Warenkorb eines x-beliebigen Shops für Digitalkameras und Zubehör umgesetzt werden. Unser Warenkorb enthält nach dem Einkauf des Nutzers neben einer aktuellen Fuji-Kamera noch zwei Speicherkarten, ein Ersatzakku und eine passende Kameratasche. Die schlichte, aber gut strukturierte und barrierefreie Warenkorb-Tabelle sieht dann ohne jegliche Gestaltung so aus:

In der Quellcode-Ansicht sieht die Grundstruktur der Tabelle so aus

<table summary="Summe der Artikel im Warenkorb">
<caption>Produkte in Ihrem Warenkorb</caption>
<thead>
<tr>
<th scope="col">Anzahl</th>
<th scope="col">Produkt</th>
<th scope="col">Einzelpreis</th>
<th scope="col">Gesamt</th>
</tr>
</thead>
<tfoot>
<tr>
<td colspan="3">Summe Warenkorb:</td>
<td>269,47 EUR</td>
</tr>
</tfoot>
<tbody>
<tr>
<td><input type="text" size="3" value="1"></td>
<td><a href="#">Digitalkamera: FujiFilm FinePix F100fd
</a></td>
<td>209,19 EUR</td>
<td>209,19 EUR</td>
</tr>
<tr>
<td><input type="text" size="3" value="2"></td>
<td><a href="#">Speicherkarte: SanDisk Extreme III SD 4GB
</a></td>
<td>21,75 EUR</td>
<td>43,50 EUR</td>
</tr>
<tr>
<td><input type="text" size="3" value="1"></td>
<td><a href="#">Akku: Fuji AccuPower</a></td>
<td>6,29 EUR</td>
<td>6,29 EUR</td>
</tr>
<tr>
<td><input type="text" size="3" value="1"></td>
<td><a href="#">Tasche: Fujifilm Softcase SC-F</a></td>
<td>10,49 EUR</td>
<td>10,49 EUR</td>
</tr>
</tbody>
</table>

Zur Gestaltung: border: 1px solid #555; definiert den 1-Pixel-Rand, border-collapse: collapse; sorgt dafür, dass mögliche Rahmen innerhalb der Tabelle zusammenfallen.

Warenkorb in klassischem Grau

Datentabellen hübsch machen

Schlanker HTML-Code und ein paar Zeilen CSS garantieren also noch keine schöne Datentabelle, doch mittels CSS kann man die Gestaltung noch weiter verbessern. Beachten Sie bei allen Möglichkeiten von CSS allerdings immer, dass Sie hier einen kommerziellen Warenkorb gestalten und nicht eine schicke Designer-Webseite. Wichtig sind also Usability- und Zugänglichkeits-Aspekte der Datentabelle – analog zum Zitat »form follows function« hat die Gestaltung dieser Funktion zu folgen, nicht umgekehrt. Schick aussehen darf es aber trotzdem.

Da die Tabelle über mehrere Elemente verfügt, lassen sich diese Elemente per CSS separat gestalten, auch ohne in den HTML-Code einzugreifen. Dieses Vorgehen ist wichtig, weil Sie bei vielen Shopsystemen oft nur eingeschränkt in den Code eingreifen können. Das wichtigste für den Nutzer ist die transparente Darstellung der Preise und die klare Zuordnung der gewählten Produkte. In der üblichen Darstellung werden die Preise der Tabelle per text-align: right; rechtsbündig dargestellt, nur die Tabellenüberschrift <caption> soll linksbündig über der Tabelle stehen. Mittels padding können Sie die Innenabstände für die Tabellenzellen festlegen und verschiedene Farben für Zellenhintergründe und -ränder definieren. Die Gestaltung der Schrift dient schließlich der eindeutigen Klassifizierung der Zellinhalte.

Unser Warenkorb sieht nun so aus:

Warenkorb in frischen Farben

Die Links, die in den Zellen des Warenkorbes normalerweise wieder zur Produktbeschreibung im Shopsystem führen, zeigen eine Grafik als Hintergrundbild.

td a {
padding-left: 20px;
background: url(img/u_list.gif) no-repeat left center;
}

Für den Tabellenkopf <thead> wurde übrigens ein Rand definiert. Das Fehlen dieser Definition hätte zur Folge, dass durch die Anweisung border-collapse: collapse; der Tabellenrand zu sehen wäre und daraus folgend eine unschöne Einbindung des Tabellenkopfes. Vermieden wird das mit Hilfe von:

thead th {
background: #681400;
border: 1px solid #681400;
}

Zucker zum Kaffee: Das HTML bearbeiten

Unser Warenkorb hat sich gestalterisch bereits von der mausgrauen Kastenoptik der ursprünglichen Tabelle abgesetzt. Sofern Sie keine andere Möglichkeit haben, in den HTML-Code Ihres Shops einzugreifen, sind Ihre weiteren Möglichkeiten hier natürlich begrenzt. Sie können noch durch Hintergrundgrafiken einzelne Tabellenteile optisch aufwerten oder auf die allgemeine Browserunterstützung von CSS3 warten. Hierauf gehe ich noch kurz gesondert ein. Sofern Sie den HTML-Code für die Datenausgabe des Warenkorbes bearbeiten können, haben Sie durch zusätzliche Klassen die Möglichkeit, die Darstellung der Tabelle weiter zu verfeinern. Das selten genutzte Element <colgroup> können Sie nicht nur dazu verwenden, mittels der Attribute width und span dem Browser Anzahl und prozentuale Größe der Tabellenspalten mitzuteilen, die Attribute steuern damit auch die optische Darstellung der Spalten. Die erste Spalte mit der Angabe der Produktmenge soll möglichst nicht breiter sein als das <input>-Feld. Dafür muss die Bezeichnung im Tabellenkopf auf »Anz.« abgekürzt werden. Die breiteste Spalte soll den Produkten vorbehalten sein. Einzel- und Gesamtpreis sollen dagegen eine einheitliche Breite erhalten. Im HTML-Code sieht das dann so aus:

<colgroup>
<col width="8%" />
<col width="56%" />
<col width="18%" span="2" />
</colgroup>

Da wir in unserem Warenkorb nur die Preise rechtsbündig dargestellt sehen wollen, können Sie auch eine entsprechende Klasse <td class="preis"> mit der CSS-Anweisung text-align: right; für diese Spalten definieren.Wenn Sie schon den HTML-Code bearbeiten, können Sie auch gleich den »Zebra-Effekt« farblich unterschiedlicher Zeilen umsetzen, der für eine bessere visuelle Orientierung in Datentabellen sorgt.
Damit haben wir dann Zellen mit <td class="zebra">, bzw. <td class="preis zebra"> definiert. Für die Tabellenzellen definieren wir einen zarten Verlauf als Hintergrundgrafik, die »Zebra-Zellen« sollen dagegen in einem leichten Grünton und ohne Hintergrundgrafik dargestellt werden.

td {
background: #fff url(img/verlauf.gif) repeat-x left
bottom; }
td.zebra {
background-image: none;
background-color: #ebfbc1;
}

Wenn der Tabellenkopf eine Hintergrundgrafik enthält, sollten Sie die Tabellenbreite in em definieren, um bei Schriftskalierung ein Überlappen des Textes über das Bild zu vermeiden. Erweitert wird auch die Gestaltung des Tabellenfußes, der ein dekoratives und zum Thema passendes Hintergrundbild erhält:

tfoot td {
background: #fff url(img/cam_comp.gif) no-repeat
5px 15px;
}

Die dortige Tabellenzelle mit der Gesamtsumme des Warenkorbs wird über eine id="total" separat gestaltet, ohne Hintergrundbild und mit differenzierter Hintergrundfarbe:

tfoot td#total {
background-image: none;
color: #681400;
font-size: 120%;
background-color: #f4d37d;
}

Das Ergebnis sieht dann so aus:

komplex gestalteter Warenkorb

CSS3: Warenkorb der Zukunft

Tabellen in Zebraoptik sind sehr gut wahrnehmbar, aber es ist nur selten möglich, zusätzliche Klassen in einer Datentabelle generieren zu lassen. Es gibt zwar JavaScript-Lösungen, doch da ist die Angemessenheit der Mittel zumindest diskussionswürdig.

Noch nicht ganz alltagstauglich, aber dennoch interessant sind deshalb die Möglichkeiten reiner CSS3-Lösungen, die bereits von einigen aktuellen Browsern unterstützt werden. Komplett und korrekt werden die nun folgenden Möglichkeiten bisher allerdings nur vom Firefox 3.1 (beta), Google Chrome und dem aktuellen Safari-Browser ab Version 3.1 dargestellt.

Für gestreifte Tabellenzeilen bietet CSS3 das Pseudoattribut :nth-child. Dieses Pseudoattribut wird auch im Opera-Browser korrekt dargestellt:

tr:nth-child(odd) { background: #fff
url(img/verlauf.gif) repeat-x left bottom; }
tr:nth-child(even) {
background-image: none;
background-color: #ebfbc1;
}

Immer wieder gefragt sind auch abgerundete Ecken, die ebenfalls nur über JavaScript-Lösungen oder mit reichlich zusätzlichem Markup umgesetzt werden können – für einen Warenkorb sicherlich zu aufwendig. CSS3 bietet auch hier eine schnelle und unkomplizierte Lösung, die zusätzlich mit interessanten Schatteneffekten kombiniert werden kann. Wir ergänzen lediglich einen zusätzlichen, die Tabelle umschließenden, DIV-Container:

#tablediv {
border: 3px solid #bbb;
-moz-border-radius: 15px;
-webkit-border-radius: 15px;
border-radius: 15px;
-moz-box-shadow: 5px 5px 15px #ccc;
-webkit-box-shadow: 5px 5px 15px #ccc;
box-shadow: 15px;
padding: 25px;
width: 50em;
font-size: 75%;
background: #d6e8ec url(img/back_tablediv.gif) repeatx
0 0;
}

Das Ergebnis sieht dann im Safari so aus:

Warenkorb als CSS3-Lösung

Fazit

Mit zeitgemäßenWebstandards lassen sich auch triste Datensätze in einfach strukturierten Tabellen ansprechend und professionell gestalten. CSS2 bietet bereits heute eine Unmenge von gestalterischen Möglichkeiten – man sollte aber schon einen Blick in die Zukunft und damit auf CSS3 werfen, auch wenn die Umsetzung bei relevanten Inhalten noch nicht hoffähig ist.

Sämtliche Beispieldateien sind auch als ZIP-Datei erhältlich:
www.webstandards-magazin.de/artikel/01-09-warenkorb.zip

Zum Autor

Nils Pooker (Jahrgang 1965) war von 1993 bis 2001 als Gemäldekopist tätig. Seit 2001 arbeitet er als selbstständiger Webdesigner. Nils Pooker ist Mitglied der Webkrauts und Fachbuchautor. Er hält Vorträge und schreibt über Kundenkommunikation, Wahrnehmung, Webstandards und Webdesign.

Startvorbereitungen

Per JavaScript wird die Seite nun ein wenig zurechtgefaltet. Bei den Leistungen und im Impressum werden Inhalte zusammengerückt, sie lassen sich per Klick umschalten. Die Inhaltsleiste startet etwas verschoben mit dem Portfolio. Es sei denn, jemand hat das Kontaktformular falsch ausgefüllt und klickt auf »Zurück«, dann startet die Seite direkt mit dem Kontaktformular. Zunächst gab es nur die kleinen Pfeile, über die der Besucher dann navigieren sollte.

Usability

Soweit, so klar. Habe ich gedacht. Ich habe probeweise eine Freundin an meinen Rechner gesetzt, die dann auch prompt fragte: »Und nun?«

Nur weil ich weiß, dass der Besucher scrollen kann, muss es ja der Besucher nicht begreifen. Also habe ich eine bekannte Navigation hinzugefügt. Da sich das Menü nun aber unter dem eigentlichen Inhalt befindet, habe ich zusätzlich den kleinen Pfeil in grün hinzugefügt. In der Hoffnung, dass mehr Leute die Navigation finden. Zusätzlich steht beim Portfolio die Aufforderung, sich durch selbiges zu klicken. Sobald der User einmal gesehen hat, wie sich der Inhalt bewegt, weiß er hoffentlich, wie die Seite zu bedienen ist.
Ob das bei allen Usern klappt, werden die nächsten Wochen zeigen.

Mit ohne alles

Als professioneller Webworker kommen wir nun nicht umhin zu fragen: Was passiert, wenn?

Was passiert, wenn der User gar kein JavaScript hat? In dem Fall sieht er alle Inhalte in dem kleinen Fenster mit einen horizontalen Scroll-Balken und kann einfach nach links und rechts scrollen. Erst, wenn JavaScript aktiviert ist, erscheint die untere Navigation und diverse Inhalte werden anders angeordnet.

Was passiert, denn der User die Schrift vergrößert? Bei einem reinen Text-Zoom wächst die Seite schön mit. Im Firefox übersteht das Design bei 1280×1054 Pixeln drei Vergrößerungen per Strg+, danach muss der Nutzer den Bildschirm nach unten scrollen.

Was ist mit Bild-Zoom? Opera und Safari schaffen den Bild-Zoom problemlos. Der inkompetente Internet Explorer 7 zerstört leider das Design. Für mich aber kein Grund, irgendetwas an meinem Code zu ändern.

Was passiert, denn der User die Seite mit 800×600 Pixeln anschaut? Pech!

Und ohne CSS? In dem Fall sind die Inhalte zunächst zu sehen. Falls aber JavaScript aktiv ist, schiebt ein Klick auf die Navigation aber Inhalte aus dem Sichtfenster. Ich könnte das Problem umschiffen; aber den Aufwand spare ich mir hier.

Performance

Das große Problem an einem One-Pager ist natürlich: Es muss ziemlich viel auf einmal geladen werden. Insbesondere die Bilder machen sich bemerkbar. Die Navigation ist als CSS-Sprite angelegt. Ich habe darin das Menü, die Links-Rechts-Pfeile und auch den Text im Kopf zusammengefasst. Das spart zwar keinen Speicherplatz, aber einige HTTP-Requests.

In der fast finalen Version kam ich trotzdem auf 33 HTTP-Requests: 1 HTML-File, 3x JavaScript, 2 Style-Sheets, 1 CSS-Image und 26 weitere Bilder. Die Bilder haben mit 732 Kilobyte den größten Anteil; insgesamt liege ich bei 851 kb.

Bei den Bildern habe ich bereits vorher darauf geachtet, dass sie jeweils möglichst klein sind. Im Gegensatz zu anderen Projekten habe ich bei jpgs schon mal eine höhere Komprimierung gewählt, um ein paar kb zu sparen. Ich jage trotzdem alle Bilder noch einmal durch Smush It (ist Teil von Firebug) und spare so noch einmal 26,2 kb. Bei anderen Projekten lässt sich da deutlich mehr herausholen. Die beiden Style-Sheets fasse ich zu einem zusammen.

In dem Versuch, richtig clever zu sein, kam ich auf die Idee, auf die kleinen Bilder im Portfolio zu verzichten. Schließlich muss ich ja ohnehin die großen Bilder laden, da kann ich sie eigentlich doppelt nutzen und den Browser daraus Thumbnails kleinrechnen lassen. D.h. ich packe die Bilder in ein zusätzliches <span>, lasse das Bild dann skalieren und durch das span in der Höhe abschneiden. Das spart zehn HTTP-Requests und noch einmal knapp 100 kb.
Leider bringt das einige Nachteile mit sich. Zum einen rechnet ein Browser die Bilder zwar kleiner, hübsch sehen sie aber nicht aus. Zum anderen wird die Animation langsamer, wenn das kleingerechnete Portfolio ins Bild kommt. Da überwiegen also die Nachteile – übrigens hier zu sehen. So nehme ich lieber die zusätzlichen 100kb in Kauf und bin flexibler, weil das kleine Bild nun was anderes zeigen könnte als das große.

YSlow zählt übrigens noch ein paar Punkte auf, die ich verbessern könnte, etwa jQuery per CDN auslagern. Davon halte ich jedoch nicht allzuviel; irgendwer könnte dann meine Besucher mitzählen. Ich könnte mein JavaScript noch minifzieren, vermutlich lässt sich alles auch cleverer programmieren, viel ist daran aber nicht zu sparen, es ist ja nur 3kb groß.

Barrierefreiheit

Zum Thema Accessibility gab es einen Mini-Mini-Test der Seite mit dem Screenreader. So viel war danach nicht zu optimieren. Die Bilder hatten bereits einen entsprechenden alternativen Text, das Captcha beim Formular ist absichtlich nur eine einfache Frage.

Ich habe ein paar Links der Marke »Webseite ansehen« um die Domain erweitert, damit die Links auch eindeutig sind. Die dynamischen Links bei Leistungen/Zur Person funktionieren auch im Screenreader, allerdings sprang der Screenreader danach zum Bild. Mit etwas JavaScript wird nun nach einem Klick die neue Überschrift fokussiert.

Ein ausführlicher Test mag hier mehr Stellen finden, die optimiert werden könnten. Für den Moment reicht mir der aktuelle Stand.

Suchmaschinenoptimierung

Gibt es nicht.

Ich feile zwar immer noch an den Texten, es geht mir aber nur noch darum, lockerer zu werden. Dabei verschwende ich keinen einzigen Gedanken an Suchmaschinenoptimierung. Wenn ein Keyword auftaucht, ist es eben so, aber ich setze sie nicht absichtlich ein, um ein höheres Maß an SEO zu erreichen.

Sonderbehandlungen

Ich brate zwei Extrawürste: Eine bekommt der Internet Explorer 6, die andere ist fürs iPhone.

Die Seite würde im Internet Explorer 6 grundsätzlich funktionieren. Es gäbe keinen Durchsicht-Effekt in der Navigation und ich müsste die Elemente mit einem Extra-Stylesheet etwas anders formatieren, aber den Look der Seite schafft auch der IE6. Allein, ich gönne mir auf meiner eigenen Seite den Luxus, den IE6 zu ignorieren. Bzw. ignorieren ist das falsche Wort, der IE6 bekommt von mir ganz anderen Inhalt ausgeliefert. Es gibt ein anderes Foto und den mehr oder weniger freundlichen Hinweis, doch bitte den Browser zu wechseln.
Alles andere dazu habe ich schon vor eineinhalb Jahren im Pisto-Magazin erörtert.

Die Webseite im Internet Explorer 6

Auf dem iPhone würde die Seite auch funktionieren. Und zwar so wie sie ist. Allerdings zoomt sich das iPhone das Inhaltsfenster etwas klein zurecht. Und die Animationen sind in dieser Größe eher hinderlich. Also verzichte ich ganz auf JavaScript und ordne die Inhalte untereinander an statt nebeneinander. Die Portfolio-Übersicht fliegt ganz raus und von den Bildern für die Rubriken News etc. kommt nur noch das Leistungen-Bild zum Zuge, damit zum Start ein Bild zu sehen ist. Das spart zehn kleine Portfolio-Bilder und sechs Fotos bei den Rubriken. So müssen nur noch knapp 460kb geladen werden. Durchaus sinnvoll für einen mobilen Browser.
Die iPhone-Sonderbehandlung gibt es nur, weil ich zufällig selbst ein iPhone habe. Weitere Anpassungen für andere mobile Geräte erspare ich mir.

In dem Fall nutze ich übrigens eine Weiche per PHP. Wird entweder ein iPhone oder der IE6 erkannt, wird per PHP anderer oder reduzierter Inhalt ausgeliefert. Sonst wird die normale Seite gezeigt. Wer genau hinschaut, stellt fest, dass ich den Text im Kopf jeweils leicht angepasst habe.

Die ewige Baustelle

Ich habe die Seite online gestellt, damit ich überhaupt weiterkomme. Sonst bringe ich noch zwei weitere Jahre damit zu, hohe Ansprüche nicht erfüllen zu können. Natürlich habe ich noch ein paar Punkte auszusetzen:

• Die Stockfotos sind zwar für den Moment ok, aber eigentlich sollte auch das Design deutlich verspielter sein. Ich träume immer noch von eigenen Robotern, die ich für mein Corporate Design nutzen kann. Ich mag eben Character Design. Vielleicht fange ich erst einmal mit einem Twitter-Vogel rechts über dem Inhalt an.
• Das Print-CSS könnte auch etwas mehr Sorgfalt vertragen. Für den Ausdruck stelle ich aber lieber ein zusätzliches PDF-Portfolio zur Verfügung.

Trotz aller Dinge, die ich noch auszusetzen hätte, ist diese Version aber schon mal online. Und nicht wieder halb fertig am eigenen Anspruch gescheitert.

Zum Autor

Nicolai Schwarz arbeitet unter dem Namen textformer mediendesign als selbstständiger Designer und Webentwickler in Dortmund. Gelegentlich schreibt er darüber, zum Beispiel für das Webstandards-Magazin, t3n, PHP User oder eben auf webkrauts.de

Mittlerweile ist die neue Webseite online. Endlich. Und im Gegensatz zu Kundenprojekten kann ich hier etwas ausführlicher über das Wie, Warum und Wieso erzählen. Viele Aspekte dieses ersten Teils sind rein subjektiv. Es gibt gute Gründe, zu anderen Schlüssen zu kommen.

Alles auf Null

Dieser Relaunch startete ganz am Anfang: beim Namen. Ich firmiere seit 2003 unter dem Namen »textformer«. Ursprünglich sollte es bedeuten: Der Kunde liefert den Text, den Inhalt – ich sorge für die äußere Form, das Design. Nun denken die meisten Leute aber, dass ich texte. Was ich bei einigen Kunden mittlerweile zwar mache, was aber nicht meine eigentliche Dienstleistung ist. Insofern ist der Name – sagen wir mal – zumindest suboptimal gewählt.

Also habe ich mehrere Wochen überlegt, ob ich vielleicht nur unter meinem Namen firmiere. Das funktioniert für andere Dienstleister schließlich auch ganz gut. Die arbeiten dann oft mit ihren Initialen – da bin ich beim Namen »Nicolai Schwarz« schon mal äußerst schlecht bedient. Außerdem läuft mein twitter-Account auf den Namen textformer; diverse andere Seiten verlinken auf und nennen textformer.de, Text ist mir wirklich wichtig und vor allem: Ich mag das Signet. Das t und das f verbinden ideal Text und Form. Leute erkennen in dem Zeichen ein Reagenzglas, eine Leier, ein Drachenschiff, ein chinesisches Schriftzeichen – alles Ideen, mit denen ich sehr gut leben kann.

Ich habe mich also dazu entschieden, bei textformer.de zu bleiben.

Formulierungsschwierigkeiten

Ein Firmenname lädt dazu ein, sich hinter ihm zu verstecken. Alles hat dann eben textformer mediendesign erledigt. Das habe ich auf der alten Webseite so gehandhabt. Nun bin ich aber selbstständig und arbeite erst einmal alleine. Das sollen Besucher ruhig deutlich sehen. Außerdem finde ich die Ich-Form bei einigen Kollegen ganz charmant. Also habe ich mich bemüht, die meisten Text auf ein Ich umzuschreiben.

Eine gewisse Unentschlossenheit ist trotzdem zu erkennen: Im Kopf ist zwar das Signet zu sehen. Statt textformer.de oder textformer mediendesign steht dort aber mein Name. Ideal ist es noch nicht; lediglich das beste, was mir bisher für den Kopf eingefallen ist – und ich habe einige Dutzend Versionen ausprobiert und verworfen.

Charmant finde ich hier übrigens die Lösung von Vibor Viskovic. Er verbindet mit einem einfachen Satz seinen Namen mit dem Firmennamen CreativeSwitch.

Design und Webentwicklung

Eine andere Schwierigkeit bei unsereins ist ja, den Leuten zu erklären, was wir genau machen. Ich mache mehr als Screendesign; bin aber kein Programmierer. Webworker hört sich zwar gut an, ist aber genauso schwammig. Außerdem gestalte ich für einige Kunden auch Logos, was auch nicht alle Webleute machen. Mittlerweile nenne ich mich Designer und Webentwickler – schön kurz und knapp. So handhabt es zum Beispiel auch Matt Hamm, der seine Tätigkeiten ebenfalls schön plakativ in den Vordergrund stellt.

Gut, Design und Webentwicklung also. Das sollte im Idealfall auch auf der Webseite rüberkommen. Webentwicklung lässt sich gut mit ein paar JavaScript-Effekten darstellen; ist nicht so kompliziert, macht sich aber bei vielen Kunden ganz gut. Was das Design angeht: Ich hatte mir früh in den Kopf gesetzt, Illustrationen zu nutzen. Die bastle ich zwar nie für Kunden, wollte sie aber auf meiner Seite haben.

Außerdem habe ich nicht so viele Inhalte, dass ich sie unbedingt auf mehrere Seiten verteilen müsste. Es sollte daher ein One-Pager werden. Und es sollte verspielter wirken als früher. Insofern lautete das kurze Briefing an mich selbst: Verspielter One-Pager, der für Design und Webentwicklung steht.

Die Webseite dient ansonsten nur als erweiterte Visitenkarte. Ich bekomme meine Kunden in der Regel über Empfehlungen oder Vorträge, die ich halte. Ich bin also nicht darauf angewiesen, über die Webseite nach neuen Kunden zu fischen.

Und eins, und zwei, und drei

Es hat mehrere Anläufe und etwas über ein Jahr gebraucht, bis ich tatsächlich eine neue Webseite online geschaltet habe. Zwei, drei erste Varianten liegen immer noch halbfertig auf meinem Server rum.

Bei Version 1 ist bereits alles als One-Pager angerichtet. Eine Infobox am linken Rand gibt eine ständige kurze Beschreibung über das Unternehmen, das Portfolio steht im Mittelpunkt, kleine Boxen enthalten die weiteren Infos. Es war von Anfang so geplant, dass nur wenig Platz für Texte zur Verfügung stehen sollte; ich wollte mich möglichst kurz fassen. Oben sollte es eine Illustration von Dortmund geben, die per Parallax-Scrolling hübsch anzusehen wäre.
Wenig später dachte ich mir: Text-Boxen zu klein, und die Illustration hätte das Dortmunder U enthalten, das hier in der Gegend mittlerweile zu oft für alles mögliche verwendet wird.

Relaunch von textformer.de - 1. Versuch

Variante 2 ist der Versuch, doch stärker meinen Namen (also: Schwarz) zu berücksichtigen. Das heißt alles eher dunkel zu halten. Hier gibt es zwei getrennte Bereiche: Oben allein das Portfolio, hell und damit hervorgehoben. Unten kleine Boxen, die hin- und hergeschoben werden können und wirklick nur Platz für minimale Infos bieten.
Wertung: Schon besser (finde ich zumindest), aber wirklich tierisch wenig Platz unten.

Relaunch von textformer.de - 2. Versuch

Die nächste Iteration ist nur eine Abwandlung. Keine Kästen mehr unten, stattdessen eine Navigation mit den wichtigsten Punkten. Die Inhalte selbst kann man oben schon in einem Rutsch durchscrollen, wenn man will. Das Portfolio bot vorher Platz für 15 Beispiele, das war mir dann doch etwas zuviel. So wurden daraus zehn Beispiele. Eines ist absichtlich hervorgehoben, um es dem Besucher einfacher zu machen, einen Link als ersten anzuklicken. Dazu kommt kurzer Text, der nur den Zweck hat zu sagen: »Ja, hier kann man klicken, also klick!«.
Diese Fassung war eigentlich schon fertig. Kollegen haben mich überzeugt, auf die Anfangsanimation (das Herausfahren der Elemente) zu verzichten; es wäre nicht mehr so viele daran zu tun gewesen. Allein, ich wollte Illustrationen haben, für die ich nie Zeit (oder Talent) hatte.

Relaunch von textformer.de - 13 Versuch

und vier

Bis ich dann wieder Zeit für die Seite hatte, gefiel mir das dunkle Design schon wieder nicht mehr. In dem Fall habe ich mir selbst ein Datum gesetzt, an dem die Seite in jedem Fall online gehen sollte. So ist sie nun in der aktuellen Form online – ohne Illustrationen.

Der eigentliche Inhalt ist auf einer üblichen Breite von 960 Pixeln untergebracht. Im Kopf gibt es eine Mini-Vorstellung. Ich gehe davon aus, dass die meisten Besucher schon vorher wissen, was ich mache. Das bestätige ich noch einmal im Kopf und zeige dann gleich das Portfolio. Die Kurzinfo im Kopf ist noch eine Grafik, ich habe aber absichtlich die Museo als Schrift gewählt, um den Part irgendwann mal als reinen Text zu implementieren.

Idealerweise startet die Seite später mit einer Mischung aus aktuellem Inhalt plus Illustration. Die Hilfsfarbe grün werde ich je nach Jahreszeit wechseln. In der Navigation schiebt sich der grüne Balken lustig unter die Schrift hindurch – auch wenn es kaum jemandem auffallen wird.

Soviel zum Vorspiel. Morgen geht es weiter mit der Umsetzung und dem Handwerk.

Links zum Thema:

• Reduziert aufs Wesentliche – Ein Plädoyer für One-Pager (zufällig auch ein Artikel von mir)
• One Page Love – eine Sammlung von One-Pagern
• One Page Sites – eine weitere Sammlung bei Design Meltdown

Zum Autor

Nicolai Schwarz arbeitet unter dem Namen textformer mediendesign als selbstständiger Designer und Webentwickler in Dortmund. Gelegentlich schreibt er darüber, zum Beispiel für das Webstandards-Magazin, t3n, PHP User oder eben auf webkrauts.de

Welche Herausforderungen bestehen konkret?

Der Großteil der Unterseiten hat jeweils eigene Header, Sidebars und Footer. Zentrale Dateien (php-includes) für Bereiche, die sich auf jeder Seite wiederholen, gibt es nicht. Trotz identischer Layouts werden in jeder Webseite eigene Javascript-, CSS- und Grafikdateien, sowie Inline-Javascript und -CSS verwendet. Dass es bessere Vorgehensweisen gibt, wissen wir natürlich mittlerweile.

Da wir zur Zeit an vielen umfangreichen Erweiterungen aller Bereiche der Webseite arbeiten, ist die Entwicklung schlanker Work-Flows ein wichtiges Ziel. Es sind sehr viele RewriteRules im Einsatz, die teilweise mehrfach weiterleiten. Das macht die Organisation der URLs sehr umfangreich. Es finden sich etwa sehr viele Wiederholungen aufgrund der Mehrsprachigkeit auf den Webseiten wieder.

Außerdem müssen alle Optimierungen im laufenden Betrieb erfolgen.

Was tun mit bestehenden Seiten?

Der Einsatz eines CMS kommt für uns vorerst nicht in Frage, da uns die Zeit fehlt, die große Auswahl an System auf Basis unserer Sicherheits- und Flexibilitätsansprüche zu evaluieren. Es gilt, einen guten Kompromiss zu finden – einerseits wollen wir die bestehenden Work-Flows optimieren, andererseits müssen wir den laufenden Betrieb aufrechterhalten. Wir gehen bei bestehenden Seiten, an denen Änderungen vorgenommen werden müssen, wie folgt vor:

Sich wiederholende Bereiche – wie Header, Navigation, Sidebar oder Footer – ersetzen wir durch Include-Dateien. CSS-Angaben holen wir aus dem Body-Element und sammeln die Angaben im Head-Element. So sparen wir wiederholte Angaben und können Gestaltungsänderungen schneller vornehmen. Wenn der Umfang der CSS-Angaben zu groß wird, lagern wir diese in einer seperaten CSS-Datei aus. Analog sammeln wir die Javascript-Angaben am Ende des Body-Elements. Wenn auch hier der Umfang zu groß wird, greifen wir hier ebenso auf eine seperate Datei zurück. Javascript-Dateien werden am Ende des Dokuments eingebunden, um die Performance zu steigern.

Aufgrund eines eingespannten Zeitplanes können wir meist nicht die gesamte Datei nach Optimierungsmöglichkeiten durchsuchen. Wenn uns jedoch während unserer Arbeit Syntaxfehler auffallen, korrigieren wir diese. Wenn wir bspw. Teile der deutschen Webseite für fremdsprachige Seiten benötigen, überprüfen wir den Code vor dem Kopieren auf Fehler und bereinigen ihn ggf.

Wir erreichen somit zwar kein absolut valides Markup, aber eine höhere Performance und werden flexibler für künftige Weiterentwicklungen. Bestehendes Markup wird stetig qualitativ hochwertiger, Fehler werden nicht weitergetragen.

Was tun mit neuen Seiten?

Neue Unterseiten erhalten automatisch eine höhere Priorität in der Entwicklungsphase. Daher kann hier die Qualität gesteigert werden. Hier gilt folgendes Vorgehen:

Wir wenden möglichst häufig das DRY-Prinzip an. Daher nutzen wir fertige Templates. Diese fügen wiederholte Elemente mittels Include-Dateien zu einem Layout zusammen. Bevor wir mit der formalen Qualitätssicherung beginnen, legen wir ein besonderes Augenmerk auf valides Markup. Wir evaluieren den Bedarf an externen Resourcen (CSS, Javascript), um Overhead zu vermeiden, und setzen auf Open-Source-Lösungen (jQuery, Kirby), um Zeit einzusparen, die wir dann weiteren Optimierungen widmen.

Was tun mit mittlerweile ungenutzen Seiten?

Zunächst ist zu definieren, ab wann eine Unterseite als nicht mehr verwendet gilt und ggf. gelöscht werden kann.

1. Wenn sie nicht mehr intern verlinkt ist?
2. Wenn sie durch eine neue Seite ersetzt wurde?
3. Wenn sie keine Besucher mehr hat?
4. Wenn sie ihre Bedeutung verloren hat, da der Inhalt abgelaufen ist?

Dabei kamen wir zu folgendem Ergebnis: Wenn sowohl 1. als 3. zutreffen, können wir die Datei höchstwahrscheinlich löschen. Doch letztendlich ist das Risiko, Fehler zu produzieren höher, als der Vorteil, der durch das Löschen entsteht.

Der Großteil dieser mittlerweile unnützen Dateien besteht aus Seiten für Aktionen, ehemaligen Partner und anderen zeitlich begrenzten Inhalten. Wenn ein solcher Fall eintrifft, sehen wir folgende Optionen vor:

• Wenn es sich um eine Seite handelt, die Teil einer Sammlung ist (z. B. eine Partnerseite), leiten wir auf die Übersichtsseite weiter. Meist mit einer permanenten Weiterleitung.
• Wenn es sich um eine abgelaufene Aktion oder Ähnliches handelt, wird auf die Startseite der jeweiligen Webseite weitergeleitet, wo dann ein Hinweis erscheint.
• Wenn es sich um Informationen handelt, die nicht mehr kommuniziert werden (Produktentfernung) entscheiden wir von Fall zu Fall, ob wir einen 404-Fehler-Code ausliefern oder zur entsprechenden Startseite weiterleiten.

Diese Ansätze führen dazu, dass sich der Umfang der RewriteRules weiter erhöhen wird. Das Refactoring der RewriteRules und das damit zusammenhängende Anpassen ihrer Tests ist in der Prioritätenliste nachgeordnet.

Fazit: Ist das der heilige Gral?

Die verfügbare Zeit für das Verbessern von bestehenden Seiten ist ausschlaggebend. Je ambitionierter die Zeitpläne für eine Optimierung veranschlagt sind, desto sorgsamer müssen die Prioritäten festgelegt werden: Validität? Semantik? Performance? Das muss jedes Web-Entwicklungs-Team für sich selbst entscheiden.

Über den Autor

Martin Labuschin ist Web-Entwickler und Usability-Experte bei der Trusted Shops GmbH (Köln). Er führt ein Blog über die Themen Design, Usabilty, Produktivität und Web-Entwicklung.