Korrekturen und Anregungen zu diesem Artikel sind jederzeit willkommen!

Was macht die Gestaltung einer guten Website aus? Das hängt ein Stück weit von Moden und Geschmack ab – dennoch gibt es einige Punkte, die man jenseits reiner Gestaltungsfragen generell beachten sollte.

HTML ist ein technischer Standard, an dem sich auch Browser-Hersteller orientieren. Auch wenn viele Browser mit fehlerhaften HTML-Dokumenten umgehen können, sollte dennoch jedes Dokument, das man selbst erstellt oder durch eine Software erzeugen lässt, formal gültig sein, d.h. es sollte bei einer Überprüfung mit einem Validator wie http://validator.w3.org fehlerfrei sein.

Gültiges HTML alleine macht noch keine gute Website – man kann auch damit schlecht lesbare Dokumente und unübersichtliches Layout produzieren. Formal fehlerfreie Dokumente stellen aber sicher, dass alle Browser, welche die verwendete HTML-Version unterstützen, die Inhalte grundsätzlich anzeigen können. Bei Fehlern hängt es dagegen von den Eigenheiten des Browsers ab, wie die Inhalte am Ende erscheinen und ob sie überhaupt angezeigt werden.

Benutzer mit körperlichen Einschränkungen, die sich Inhalte z.B. von einer Software vorlesen lassen oder von einer Braille-Zeile ablesen, haben mit fehlerhaften Dokumenten mitunter Probleme, weil die benutzte Software damit möglicherweise nicht gut umgehen kann.

Die Spezifikation von XHTML 1.0 wurde bereits im Jahr 2000 veröffentlicht – also vor über 10 Jahren – und wird von allen aktuellen Browsern unterstützt, auch in mobilen Geräten. Da XHTML 1.0 stark an HTML 4.01 angelehnt ist, können es ältere Browser, die XHTML nicht unterstützen – wie z.B. der Internet Explorer 6.0 – auch darstellen, solange man Dokumente als „text/html“ ausliefert und die Kompatibilitätsrichtlinien des W3C einhält. Es gibt daher keinen Grund, XHTML 1.0 nicht zu verwenden. Für XHTML 1.1 gilt das aber nicht, da XHTML 1.1 eine anderes Vokabular verwendet.

HTML5 ist derzeit (Stand September 2011) noch in der Entwicklung. Die Unterstützung durch aktuelle Browser ist zwar schon recht weit, aber ältere Browser, die vielfach noch in Verwendung sind, beherrschen viele der Neuerungen nicht oder nur sehr unvollständig.

In den ersten Jahren des World Wide Web waren URLs nach dem Schema http://www... üblich, weil „www“ den Dienst beschrieb, den man ansprechen wollte – so wie „ftp“ für einen FTP-Server oder „mail“ für den Mailserver.

Technisch gibt es dafür keine Notwendigkeit – eine URL ist auch ohne „www“ am Anfang zulässig, sofern der Webserver entsprechend konfiguriert ist – so wie diese Website, die unter http://arnowelzel.de erreichbar ist.

Wenn der eigene Webserver unter beiden Varianten ansprechbar ist, sollte man ggf. eine Apache-Rewrite-Regel in einer „.htaccess“-Datei verwenden, die Anfragen auf die kanonische Adresse weiterleitet.

Beispiel: Weiterleitung auf den kanonischen Namen (hier: domain.example) einer Website in Apache

RewriteEngine on
RewriteCond %{HTTP_HOST}  =www.domain.example
RewriteRule ^(.*)$        http://domain.example/$1 [L,R]

Bevor man Inhalte veröffentlicht, sollte man sich Gedanken machen, wie die URLs dazu aussehen sollen – denn diese sollten dauerhaft gültig sein. Nichts ist für Besucher frustrierender, als „tote“ Links, weil der Anbieter mal wieder seine Inhalte „neu strukturiert“ hat und im Zuge dieser Änderung etliche URLs nicht mehr existieren.

Wenn es wirklich nicht vermeidbar ist, URLs zu ändern, sollten die ehemaligen URLs über eine Weiterleitung zu den neuen Adressen führen oder zumindest zu einem Dokument, wo man nachlesen kann, wieso die alte URL nicht mehr nutzbar ist, ggf. mit Verweisen zu den aktuellen Inhalten. Mit Hilfe von Rewrite-Regeln in einer „htaccess“-Datei ist das bei Apache relativ einfach machbar. Wie im folgenden Beispiel zu sehen, sind die „alten“ URLs ohne den Domain-Teil anzugeben. Als HTTP-Status wird 301 für „moved permanently“ zurückgegeben, damit klar ist, dass alte URL nicht mehr verwendet werden sollte und damit Suchmaschinen die alten URLs künftig nicht mehr verwenden.

Beispiel: Weiterleitung alter URLs auf die aktuellen Adressen in Apache

RewriteEngine on
RewriteRule ^ErsteAlteURL$   http://%{HTTP_HOST}/ErsteNeueURL [R=301,L]
RewriteRule ^ZweiteAlteURL$  http://%{HTTP_HOST}/ZweiteNeueURL [R=301,L]

Siehe dazu auch http://www.w3.org/Provider/Style/URI.

„Barrierefreiheit“ bedeutet, dass ein Besucher unabhängig von der verwendeten Soft- und Hardware alle Dokumente ohne unnötige Hindernisse lesen kann. Es gibt auch konkrete Richtlinien zu diesem Thema: http://www.w3.org/TR/WCAG20/.

CSS (Cascading Stylesheets) und JavaScript bieten viele Möglichkeiten, das gewohnte Verhalten des Browsers zu beeinflussen. In den meisten Fällen ist das aber keine gute Idee – Besucher sind bestimmte Dinge gewohnt und werden unnötig behindert, wenn sich der Browser nicht so verhält, wie man es erwartet.

Wenn man einen Link anklickt, erwartet man in der Regel, dass im aktuellen Browserfenster der verlinkte Inhalt geladen wird – und nicht, dass ein neues Fenster (oder ein neuer Tab) erscheint. Wer einen Link in einem neuen Fenster oder Tab laden will, kann dies leicht mit den Mitteln seines Browsers erreichen – umgekehrt ist es leider nicht so einfach möglich, das Öffnen eines neuen Fensters zu verhindern. Die einzige Ausnahme bilden Links auf E-Mail-Adressen oder Daten, bei denen der Besucher auch damit rechnet, dass diese zum Download angeboten oder mit einem externen Programm geöffnet werden.

Auch die Kennzeichnung von Links mit Unterstreichung und wechselnden Farben für ungelesene und bereits besuchte Inhalte sind eine wertvolle Orientierungshilfe für Besucher – man erkennt Links auf einen Blick und sieht, welche Inhalte man bereits gesehen hat. Grafiker mögen sich daran stören, wenn Texte scheinbar „unnötig“ unterstrichen sind und Links keine einheitlichen Farben haben und das als „unruhig“ empfinden – aber eine Website soll nicht nur „schön“ sein, sondern auch gut zugänglich. Entsprechend sollte man Unterstreichungen im Text auch nur für Links verwenden.

Siehe dazu auch die Artikel von Jakob Nielsen http://www.useit.com/alertbox/20040510.html und http://www.useit.com/alertbox/20040503.html, die auch heute noch gültig sind.

Was ebenfalls unbedingt vermieden werden sollte: Vermeintliche „Kopierschutz“-Funktionen mit JavaScript, die Besucher daran hindern sollen, Texte in einem Dokument zu markieren oder das Kontextmenü des Browser zu benutzen. Einerseits funktioniert so ein „Schutz“ nicht wirklich, da JavaScript jederzeit ausgeschaltet werden kann, und es ist eine normale Funktion des Browsers, angezeigte Inhalte kopieren zu können – um damit z.B. Fachbegriffe nachzuschlagen oder etwa zu einer, im Impressum angegebenen Adresse einen Anfahrtsweg bei einem Online-Kartendienst planen zu können.

Die Einheit „em“ in CSS bezieht sich auf die Größe der Schrift, in welcher der Text beim Besucher normalerweise angezeigt wird. 1em entspricht der Höhe einer Textzeile in der Schrift, die beim Benutzer als Standard-Schrift eingestellt ist. Das ist wichtig, da Schriften nicht bei jedem Besucher gleich groß sind. Man sollte auch keine feste Schriftgröße in Pixeln durch CSS vorgeben – das würde die Einstellung des Besuchers übergehen, so dass er unter Umständen eine viel zu kleine, oder unnötig große Schrift zu sehen bekommt. Möchte man bestimmte Textabschnitte bewusst etwas kleiner oder größer darstellen, sollte auch die Schriftgröße nur in % oder „em“ angegeben werden.

„px“ definiert die Größe von Elementen in Pixeln und „pt“ in „Punkt“, wobei ein Punkt je nach System genau einem Pixel entspricht – aber eben nicht immer, ein „pt“ kann auch mehr als ein Pixel sein, da dies abhängig vom DPI-Wert des Bildschirms umgerechnet wird. Die Breite oder Höhe von Elementen, die Text enthalten, sollten deshalb immer mit „em“ definiert sein, nie mit „pt“ oder „px“.

Ein Beispiel: Wird der Bereich für einen Seitenkopf mit einer Höhe von 20px, also 20 Pixeln definiert, wird das in vielen Fällen funktionieren – aber sobald jemand eine Schrift mit mehr als 20 Pixeln Höhe verwendet (weil er beispielsweise nicht so gut sieht oder einen sehr hochauflösenden Bildschirm nutzt und deshalb die Schrift im Browser größer einstellt), wird der Text abgeschnitten oder ragt über den Kopfbereich hinaus. Umgekehrt wird bei einer kleineren Schrift Platz verschwendet. Gibt man dagegen als Höhe 1.2em an, also das 1,2-fache der Schriftgröße, passt der Text immer in das Element – egal ob die Schrift 12, 18 oder 30 Pixel hoch ist, da sich das Element automatisch der Schriftgröße anpasst.

Viele aktuelle Browser passen beim Vergrößern der Seitenanzeige über den entsprechenden Menübefehl (z.B. bei Firefox mit „Ansicht“ → „Zoom“) die Bedeutung der Einheit „Pixel“ an. Statt nur den Text zu vergrößern, werden auch Elemente in der Größe angepasst, deren Abmessungen in Pixeln angegeben ist.

Beispiel: Bei 150% Vergrößerung wird ein Element mit einer ursprünglichen Größe von 10 Pixeln tatsächlich mit 15 Pixeln abgebildet, damit es im Verhältnis zum Text weiterhin die selbe Größe hat.

Solche Anpassungen finden aber nicht statt, wenn der Benutzer statt dessen die Standard-Schriftgröße ändert (z.B. von 16 auf 20 Pixel in den entsprechenden Einstellungen des Browsers), um Texte generell leichter lesen zu können. Grafische Elemente, deren Größe in der Einheit „px“ oder „pt“ angegeben ist, werden dadurch nicht größer oder kleiner.

Solange man nichts anderes festlegt, wird ein HTML-Dokument bei Bedarf vom Browser immer mindestens so breit dargestellt, wie das Browserfenster abzüglich der Fensterelemente an den Rändern ist. Das bedeutet aber auch, dass bei einer Bildschirmauflösung von 1280×1024 oder 1920×1080 Pixeln ein Browserfenster, das mit voller Bildschirmgröße benutzt wird, eben bis zu 1280 oder 1920 Pixel in der Breite anzeigt. Texte werden in diesem Fall fast immer viel zu breit. Um eine gute Lesbarkeit zu gewährleisten, sollten Texte nicht mehr als etwa 120 Zeichen pro Zeile umfassen. Sind die Zeilen deutlich länger, wird es anstrengend, dem Text zu folgen, weil man den Anfang der nächsten Zeile nicht so leicht wieder findet. Deshalb drucken Zeitungen Artikel auch mehrspaltig ab – um die Texte lesbarer zu gestalten.

Man könnte sich nun auf den Standpunkt stellen, dass jeder Besucher das Fenster seines Browsers ja einfach auf eine Breite ziehen kann, bei der Texte noch gut lesbar bleiben – und Nutzer von Bildschirmen mit einer Breite von 1600 oder 1920 Pixeln nutzen Anwendungen vielleicht ohnehin nicht immer mit maximaler Bildschirmgröße. In der Praxis ist es aber so, dass es vielen Leuten schlicht zu unbequem ist, abhängig von der gerade besuchten Website das Fenster mal breiter oder mal schmaler zu ziehen, um die Texte in einer angenehmen Breite zu haben. Die meisten Besucher werden den Browser immer mit einer bestimmten Fenstergröße nutzen.

Eine bessere Lösung ist es daher, die Breite für Texte auf einen sinnvollen maximalen Wert zu begrenzen. Dafür bietet CSS die Eigenschaft „max-width“, mit der die maximale Breite eines Elements festgelegt werden kann. Steht weniger Platz zur Verfügung, wird das Element nach Möglichkeit auch schmaler dargestellt.

Manche älteren Browser unterstützen „max-width“ noch nicht und ignorieren diese Angabe, was aber kein Problem ist – es gilt dann eben wieder die maximal verfügbare Breite im Fenster und die Inhalte sind weiterhin zumindest lesbar.

Eine absolute Breitenangabe für Inhalte ist zwar verführerisch, da man so eine einfachere Kontrolle über die Seitenaufteilung hat und das auch mit älteren Browsern funktioniert – aber sie ist nicht wirklich barrierefrei, da manche Besucher dann u.U. horizontal scrollen müssen. Auch sollte man im Zeitalter von Netbooks und Smartphones mit mobilen Internetzugängen bedenken, dass Displays mit weniger als 1024 Pixeln horizontaler Auflösung durchaus nicht unüblich sind, auch wenn der Anteil nicht sehr hoch ist.

Die Entscheidung für eine feste Breite sollte deshalb nur getroffen werden, wenn man ganz bewusst nur eine bestimmte Zielgruppe anspricht und damit rechnen kann, dass die Besucher nur Bildschirme mit einer bestimmten Mindestauflösung in der Breite nutzen – und auch dann sollte man nicht mehr als 1024 Pixel in der Breite annehmen, was der Auflösung vieler Netbooks und Tablets entspricht.

Für den Internet Explorer 6, der „max-width“ noch nicht unterstützt, kann man als Kompromiss ein angepasstes Stylesheets mit „Conditional Comments“ einbinden, das von anderen Browsern ignoriert wird, da es sich formal um einen Kommentar handelt.

Im folgenden Beispiel wird dafür gesorgt, dass das Element mit der ID „content“, in dem z.B. der Text einer Website dargestellt wird, maximal 978 Pixel breit ist, sofern die verfügbare Fensterbreite dies zulässt. Dazu wird eine proprietäre Erweiterung des Internet Explorer genutzt, die als CSS-Eigenschaft auch ein Script erlaubt. Das funktioniert allerdings nur, wenn Scripting nicht abgeschaltet ist. Auch wird die Berechnung nur genau einmal beim Anzeigen des Elementes durchgeführt, damit nicht durch hunderte oder tausende Neuberechnungen beim Scrollen oder Mausbewegungen das System „lahmgelegt“ wird – wenn der Besucher sein Browserfenster in der Größe ändert, muß er die aktuelle Seite also ggf. neu laden.

Beispiel: Fragment für die Vorgabe der maximalen Breite eines Elements in Internet Explorer 6

ie6widthfix.txt

<!--[if lte IE 6]>
<style type="text/css">
#content
{
  width:expression((new Function('elem', 'elem.style.width=document.documentElement.clientWidth>977?"978px":(document.documentElement.clientWidth)+"px";'))(this));
}
</style>
<![endif]-->

Manche Leute sehen mehrspaltigen Textsatz auch im Web als Alternative an, um Texte lesbarer zu gestalten ohne dabei Platz auf dem Bildschirm ungenutzt zu lassen. Zudem gibt es ab CSS3 gibt es auch die Möglichkeit, Fließtexte automatisch mehrspaltig darstellen zu lassen.

Das Problem dabei ist aber, dass die auf dem Bildchirm sichtbare Höhe des Textes ebenso wenig vorhersehbar ist, wie die nutzbare Breite. Bei einem Besucher sind 60 Zeilen in der Höhe sichtbar, woanders vielleicht nur 40. Bei längeren Texten kann dies dann dazu führen, dass ein Leser bei jeder Spalte vertikal scrollen muss und am Ende der Spalte erst wieder an den Anfang zurückscrollen muss. Aus ergonomischer Sicht nicht unbedingt ein Fortschritt.

Im Gegensatz zur Gültigkeit von Dokumenten ist Barrierefreiheit nur bedingt automatisch überprüfbar. Es gibt zwar einige Tests, die Dokumente auf die Einhaltung verschiedener Richtlinien hin überprüfen, dennoch ist eine manuelle Beurteilung mit verschiedenen Umgebungen hier unumgänglich.

Verwenden Sie einen älteren Browser der nur die Schrift vergrößert bzw. stellen Sie ihren Browser so ein, dass nur Texte vergrößert werden (bei Firefox etwa mit „Ansicht“ → „Zoom“ → „Nur Text zoomen“) und beobachten Sie, was passiert, wenn Sie die Anzeige stark vergrößern.

Um die Darstellung ohne Grafiken, CSS und JavaScript zu testen, kann man seine Website mit einem rein textbasierten Browser begutachten – wie etwa Lynx. Wer Lynx nicht auf seinem eigenen Computer hat, kann auch einen der „Lynx Viewer“ nutzen, die in einer regulären Website die Ausgabe von Lynx als Text darstellen, wie http://www.yellowpipe.com/yis/tools/lynx/lynx_viewer.php oder http://www.delorie.com/web/lynxview.html. Auch in dieser stark reduzierten Darstellung sollten alle Inhalte noch erkennbar sein – oder wenn dies nicht immer möglich ist (z.B. bei eingebetteten Bildern oder Videos), zumindest für den Benutzer erkennbar sein, wenn Teile des Inhalts aus technischen Gründen nicht darstellbar sind. Bei Bildern sollte das „alt“-Attribut des IMG-Elementes ggf. einen sinnvollen, beschreibenden Text enthalten.

Verkleinern Sie das Browserfenster so, dass es in der Breite weniger als 1280 oder 1024 Pixel bietet – auch dann sollten alle wesentlichen Inhalte noch lesbar sein, ohne dass man horizontal scrollen muss.

Gute Websites sollten folgende Punkte beachten:

• Gültiges (X)HTML – derzeit HTML 4.01 oder XHTML 1.0 empfehlenswert, HTML5 nur bei aktuellen Browsern
• Dauerhaft gültige URLs – ggf. alte URLs auf die aktuellen Adressen weiterleiten
• Barrierefreies Layout – Größenangaben in „em“, maximale Zeilenlängen beachten, Inhalte unabhängig vom Ausgabegerät zugänglich

XHTML 1.0 Recommendation
Web Content Accessibility Guidelines (WCAG) 2.0
Guidelines for Visualizing Links von Jakob Nielsen
Change the Color of Visited Links von Jakob Nielsen
Cool URIs don't change (W3C)
Validator des W3C
Informationen zu Screenreadern von INCOBS