Gedanken zu guten Websites

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.

Zusammenfassend:

  • Auf Gültiges HTML achten.
  • Dauerhaft gültige URLs – ggf. alte URLs auf die aktuellen Adressen weiterleiten.
  • Barrierefreies Layout – Größenangaben für Text und Elemente mit Textinhalten in „em“, maximale Zeilenlängen beachten, Inhalte unabhängig vom Ausgabegerät zugänglich, Links auf die aktuelle URL vermeiden.
  • Tests – die Darstellung sollte mit unterschiedlichen Browsern auf verschiedenen Geräten oder Betriebssystemen überprüft worden sein, auch solche, wo JavaScript oder CSS gar nicht oder nur unvollständig unterstützt werden.

Gültiges HTML

HTML ist ein technischer Standard, an dem sich auch Browser-Hersteller orientieren. Auch wenn die meisten 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 selbstverständlich noch keine gute Website aus – man kann auch damit schlecht lesbare Artikel und unübersichtliches Layout produzieren. Formal fehlerfreie Dokumente stellen aber sicher, dass Browser 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/innen 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.

Welche HTML-Version?

HTML 4.01

HTML 4.01 war lange Zeit de facto der Standard für Websites und wird von praktisch jedem Browser unterstützt. Die Syntax, bzw. was formal als „korrekt“ angesehen wird, ist aber teilweise recht „eigenwillig“, weshalb ich HTML 4.01 bei neuen Projekten gar nicht mehr einsetzen würde, wenn es keine sehr gut begründete Anforderung dafür gibt.

XHTML 1.0

Die Spezifikation von XHTML 1.0 wurde bereits im Jahr 2000 veröffentlicht 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 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 ein anderes Vokabular verwendet.

HTML5

HTML5 ist seit Ende 2012 in einem recht „fertigen“ Zustand und wird vielfach (Stand 2014) bereits als Ablösung von XHTML 1.0 oder HTML 4.01 eingesetzt. Älteren Browsern fehlt selbstverständlich die Unterstützung für die Neuerungen, was sich im ungünstigsten Fall so auswirkt, dass Layoutvorgaben durch CSS nicht greifen, weil ältere Browser die unbekannten Elemente schlicht ignorieren und entsprechend auch keine CSS-Regeln darauf anwenden.

Es gibt verschiedene Ansätze, um HTML5 mit Hilfe von JavaScript auch auf älteren Browsern  nutzen zu können, wie z.B. html5shiv oder Modernizr, wo html5shiv mittlerweile auch enthalten ist. Man sollte dabei aber immer bedenken, auch das solche Lösungen kein „rundum sorglos“-Paket sind und es nicht damit getan ist, lediglich eine JavaScript-Datei einzubinden und dass man auch hier das Ergebnis selber mit den entsprechenden Browsern testen muss.

Auswahl von URLs

www…?

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, idealerweise mit HTTP-Status 301 für eine dauerhafte Weiterleitung, damit auch Suchmaschinen wissen, dass die Variante mit „www“ nicht verwendet werden soll.

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=301]

Zweites Beispiel: Weiterleitung auf den kanonischen Namen unter Berücksichtigung von SSL/TLS:

RewriteEngine on

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

RewriteCond %{HTTP_HOST}   =www.domain.example
RewriteCond %{SERVER_PORT} 443
RewriteRule ^(.*)$         https://domain.example/$1 [L,R=301]

Keine ungültigen URLs

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/innen 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 (ich kenne das aus eigener Erfahrung), sollten die ehemaligen URLs über eine Weiterleitung zu den neuen Adressen führen (idealerweise mit Response-Code 301 für „dauerhafte Weiterleitung“, damit auch Suchmaschinen ihren Index entsprechend anpassen) 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, was auch von auch Suchmaschinen berücksichtigt wird.

Beispiel: Weiterleitung alter URLs auf die aktuellen Adressen in Apache

RewriteEngine on
RewriteRule ^ErsteAlteURL$   /ErsteNeueURL [L,R=301]
RewriteRule ^ZweiteAlteURL$  /ZweiteNeueURL [L,R=301]

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

Barrierefreies Layout

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

Keine Änderung des gewohnten Verhaltens

CSS (Cascading Stylesheets) und JavaScript bieten viele Möglichkeiten, das gewohnte Verhalten des Browsers zu beeinflussen. In manchen Fällen ist das aber keine gute Idee – Besucher/innen 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 man 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/innen – man erkennt Links auf einen Blick und sieht, welche Inhalte man bereits gesehen hat. Grafiker/innen 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: Vermeintlicher „Kopierschutz“ mit JavaScript, der Besucher/innen daran hindern soll, 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.

Größenangaben für Elemente

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

„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 mitunter viel zu kleinen Schriften auf Websites sind oft in der Verwendung von „pt“ begründet: Der verantwortliche Designer arbeitet mit einem Mac der eine Bildschirmauflösung von 72 DPI nutzt und dort sehen z.B. die Schriften mit „12pt“, die mit 16 Pixel Höhe dargestellt werden, ausreichend groß aus. Auf einem System mit Windows wird aber eine Auflösung von 96 DPI verwendet, was dazu führt, dass die selben Schriften nur noch 12 Pixel hoch sind (12*96/72). Schriftgrößen oder die Breite und Höhe von Elementen, die Text enthalten, sollten deshalb immer mit „em“ definiert sein, nie mit „pt“ oder „px“. Auch bei Abständen wie Seitenrändern, sollte man dies beachten.

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/die Benutzer/in statt dessen die Standard-Schriftgröße in den Einstellungen des Browsers ändert (z.B. von 16 auf 20 Pixel), 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.

Die Einheit „rem“ als Alternative zu „em“

Manche Websites nutzen statt „em“ die mit CSS3 eingeführte Einheit „rem“. Diese Einheit steht für „root em“ – also die Größe bezogen auf 1em des Hauptelements (in der Regel das Element <html>).

Damit sollte folgendes Problem gelöst werden: „em“ ist eine relative Angabe, die sich immer auf die Textgröße des Elementes bezieht, in dem man sich gerade befindet. Wenn man etwa für den Text in einem DIV-Element die Textgröße 1.5em angegeben hat und darin wiederum ein weiteres DIV-Element als Kind eingebunden wird, sind alle em-Angaben darin bezogen auf die 1.5em des Eltern-Elements. Zur Erläuterung ein vereinfachtes Beispiel:

<div style="font-size:1.5em">
Dieser Text ist 1.5em gross.

  <div style="font-size:1.5em">
  Dieser Text ist jetzt 2.25em (1,5 x 1,5) gross.
  </div>
</div>

Das kann ein Problem werden, wenn man CSS-Regeln für Elemente definieren will, von denen nicht immer klar ist, wo sie am Ende im Dokument eingebunden sind und die immer eine exakt festgelegte Größe haben sollen.

Statt nun eine feste Größe über „px“ festlegen zu müssen, kann man „rem“ verwenden – damit definiert man die Größe ebenfalls relativ zur Standardschriftgröße des Browsers, aber unabhängig davon, wo ein Element im Dokument eingebunden ist.

Ein entscheidender Nachteil: Ältere Browser kennen diese Einheit noch nicht, da sie erst mit CSS3 eingeführt wurde und ignorieren sie komplett oder interpretieren sie falsch.

Es gibt auch den „Hack“, die px-Angaben zusätzlich aufzunehmen, so dass ältere Browser ebenfalls eine korrekte Darstellung liefern, nur eben mehr nicht in Bezug auf die Schriftgröße, während neuere Browser, die CSS3 unterstützen, immer die erste Angabe verwenden:

.myclass {
  width: 60rem;
  width: 960px;
}

Meine Meinung dazu: Nicht machen. Wenn man Wert auf Abwärtskompatibilität legt, darf man „rem“ eben nicht verwenden.

Es mag Sonderfälle geben, wo man ein sonst unlösbares Problem damit beheben kann. Solche Fälle sind aber eher die Ausnahme. Durch die zusätzlichen Angaben in „px“ ist das Stylesheet nicht nur formal ungültig, sondern wächst auch im Umfang enorm an. Darüber hinaus beraubt Nutzer/innen älterer Browser, die ja mit „em“ durchaus umgehen könnten, unnötig einer barrierefreien Darstellung, die auch bei größerer Standardschrift noch funktioniert.

Maximale Zeilenlängen

Solange man es nicht anders 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 viel mehr als etwa 100 Zeichen pro Zeile umfassen (eher weniger). 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 jede/r Besuche/r das Fenster seines Browsers ja einfach auf eine Breite ziehen kann, bei der Texte noch gut lesbar bleiben – und Nutzer/innen 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/innen werden den Browser immer mit einer bestimmten Fenstergröße nutzen. Auch ist es bei manchen Geräten gar nicht möglich, die Größe anzupassen – etwa auf einem Tablet.

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/innen 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/innen 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.

Sonderbehandlung für den Internet Explorer 6

Anmerkung: Mittlerweile ist die Zeit des Internet Explorer 6 eigentlich vorbei – bereits ab der ersten Nachfolgeversion, die ebenfalls kaum noch anzutreffen ist, ist hier beschriebenen „Hack“ nicht mehr erforderlich. Das Ganze ist daher eher als Sonderbehandlung für Ausnahmefälle anzusehen, auf die man in der Regel verzichten kann.

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 960 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 die Besucherin oder der Besucher sein Browserfenster in der Größe ändert, muß die aktuelle Seite also ggf. neu geladen werden.

Beispiel – Vorgabe der maximalen Breite eines Elements (960px) im Internet Explorer 6 als „Conditional Comment“:

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

Mehrspaltiger Textsatz

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 Bildschirm sichtbare Höhe des Textes ebenso wenig vorhersehbar ist, wie die nutzbare Breite. Bei manchen Besucher/innen 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.

Zeilenabstände

Auf Websites werden für die Darstellung von Text häufig serifenlose Schriften, wie Arial, Tahoma oder Helvetica (oder die generische Variante „sans-serif“) verwendet. Da es keine Serifen gibt, die das Auge optisch „führen“, muss dies durch größere Abstände zwischen den Zeilen kompensiert werden. Die Lesbarkeit von Fließtexten wird daher durch größere Zeilenabstände (CSS-Eigenschaft „line-height“) von mindestens 140% (oder 1.4em) deutlich erhöht.

Links auf die aktuelle URL vermeiden

Dieser Punkt ist kein gravierendes Problem, er sollte dennoch beachtet werden: Jeder Link innerhalb eines Dokumentes sollte auf andere Dokumente verweisen, aber nicht auf das Dokument selbst – andernfalls könnten Besucher/innen irritiert werden, weil sie hinter einem Link genau dieses Verhalten erwarten: Wenn man dem Link folgt, wird ein anderes Dokument angezeigt und nicht das gerade angezeigte Dokument erneut geladen.

Häufig entsteht so eine Situation durch Navigationselemente, die unabhängig von der gerade angezeigten URL dargestellt werden. Die entsprechenden Links sollten entweder als regulärer Text angezeigt oder ganz ausgeblendet werden. Wenn es keine elegantere Lösung gibt, ist eine Ersetzung im auszuliefernden Inhalt denkbar, wie hier z.B. mit PHP, um Links auf die aktuelle URL (<a href="...">...</a>) in regulären Text umzuwandeln:

// $htmlOutput enthält das auszugebende HTML-Dokument.
//
// $urlCurrent ist die gerade angezeigte URL.

function removeLinksToUrl($urlCurrent, $htmlOutput)
{
    $urlCurrent = str_replace( '/', '\/', $urlCurrent);
    $htmlOutput = preg_replace(
        '/(<a href="'.$urlCurrent.'")(.*?)(>)(.*?)(<\/a>)/s',
        '$4',
        $htmlOutput);
    return $htmlOutput;
}

Von JavaScript-basierten Lösungen rate ich ab, da sie nur dann funktionieren, wenn JavaScript aktiv ist und die Darstellung verzögern, weil die Links zunächst vom Browser angezeigt und dann per Script wieder entfernt werden.

Tabulator-Reihenfolge von Links beachten

Die meisten Browser bieten auch eine Bedienung mit der Tastatur an. Dabei kann man mit meist der Tabulator-Taste zwischen den einzelnen Links wechseln und diese mit der Eingabetaste öffnen. Die Reihenfolge, in der die Links ausgewählt werden, entspricht ohne weitere Angaben immer der Reihenfolge im HTML-Dokument. Nun ist es durch CSS auch möglich, Elemente in einer anderen Anordnung anzuzeigen, als sie im Dokument auftauchen – etwa durch das „float“-Attribut.

Um sicherstellen zu können, dass Links und andere auswählbare Elemente (Eingabefelder etc.) in der Reihenfolge ausgewählt werden, wie sie auch optisch angezeigt werden, kann man das Attribut „tabindex“ verwenden. Das ist eine Zahl, mit der die Reihenfolge der Elemente angegeben wird. Je höher die Zahl, desto später wird das Element beim Wechsel mit der Tabulator-Taste ausgewählt. Elemente ohne dieses Attribut werden erst nach den Elementen mit „tabindex“-Attribut ausgewählt.

Als Beispiel dazu – in diesem Codefragment wird der zuerst definierte Link an die zweite Position in der Tabulator-Reihenfolge gestellt:

<a href="zweiter.html" tabindex="2">Zweiter Link</a><br />
<a href="erster.html" tabindex="1">Erster Link</a>

Testmöglichkeiten

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

Test der Darstellung bei größeren Schriften

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.

Test der Darstellung ohne Grafiken, CSS und JavaScript

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.clickability.co.uk/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/die Benutzer/in 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.

Test der Darstellung bei kleineren Bildschirmauflösungen

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.

Weblinks

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.