Struktur schafft Durchblick

Webseiten für Sehbehinderte zugänglich machen, Teil 2

Praxis & Tipps | Praxis

Barrierefreies Web-Design hat keineswegs nur den Vorteil, Webseiten für Behinderte zugänglich zu machen. Die Schritte auf dem Weg dorthin führen gleichzeitig zu einer leichter zu pflegenden und flexibleren Site.

Im ersten Teil ging es darum, eine Website von unnötigem Ballast zu befreien, indem man sie von veralteten Syntaxkonstrukten befreit und die optische Gestaltung in externe Stilvorlagen auslagert. Nach vollzogener Umstellung hat man schon einiges geschafft: Die Inhalte durchsetzen keine Tags mehr, die nur das optische Erscheinungsbild beeinflussen. An ihre Stelle treten Syntaxelemente mit struktureller Bedeutung - so hebt etwa statt eines strukturell irrelevanten <b> jetzt <strong> Abschnitte hervor. Die neue Auszeichnung erschließt sich auch einem blinden Anwender sofort, der die Seiten mit einem Screen Reader besucht. Hinzu kommt, dass sich <strong> je nach Wahl des Designers entweder durch Fettschrift oder durch eine auffällige Farbe hervorheben darf - das lässt sich im Style Sheet frei festlegen.

Gültiger Code bildet die Grundlage für alle nachfolgenden Schritte - dies schließt sowohl die HTML/XHTML-Syntax ein als auch die Cascading Style Sheets (CSS).

Das Standardisierungskomitee World Wide Web Consortium (W3C) bietet kostenlose Online-Dienste zur Überprüfung von HTML- und CSS-Dokumenten [1, 2]; ein deutschsprachiger Alternativ-Validator findet sich beim HTML-Tutorial SelfHTML [3]. Im Unterschied zu anderen im Web verfügbaren Tools führen diese Tester eine komplette logische Analyse der Seite durch und finden so auch komplexe Fehler wie richtig formatierte Tags an einer unzulässigen Stelle.

Allerdings klopfen selbst die besten Validatoren Dokumente nur auf Grammatikfehler ab - ob die Seite semantisch sinnvoll aufgebaut ist, beurteilen sie nicht. Man kann dies analog zu einer automatischen Rechtschreibprüfung betrachten, die zwar die korrekte Schreibweise eines Briefes überprüft, nicht aber ihren Wahrheitsgehalt. Hinzu kommt, dass Validatoren gelegentlich auch fehlerhafte Verschachtelungen akzeptieren.

Manch ein Web-Designer ist dennoch der Meinung, valides (X)HTML bedeute automatisch, dass seine Seiten okay sind. Hinter dem Vorhang finden sich dann aber oft genug semantisch sinnlose <div>-Tags, die nur dazu dienen, Inhalte per CSS optisch zu formatieren. Das mag zwar valides HTML sein, ist dann aber alles andere als barrierefrei.

Was das W3C selbst für behindertengerecht hält, hat es in seinen „Zugangsrichtlinien für Web-Inhalte“ festgehalten [4]. Vom Inhalt her entsprechen die Anforderungen grob der „Barrierefreien Informationstechnik-Verordnung“ des Bundesinnenministeriums (BITV); allerdings formuliert das W3C die Richtlinien diplomatischer und einfühlsamer.

Um Barrierefreiheit zu überprüfen, gibt es auch den Validator „Bobby“ [5], der Seiten entweder nach den Kriterien des W3C oder den in den USA geltenden Accessibility-Anforderungen testet. Das Werkzeug gibt es auch als Windows-Programm für 300 US-Dollar. Seine Testergebnisse gibt Bobby in drei Prioritätsstufen gegliedert wieder - nur wer alle meistert, darf sich mit dem Logo „AAA Bobby Approved“ schmücken.

In der Praxis ist Bobby trotz seines imposanten Auftritts nur begrenzt hilfreich. So berücksichtigt der Dienst keine barrierefreien Alternativseiten und scheint bei der Einschätzung der logischen Struktur gelegentlich zu raten. So erkennt Bobby etwa nicht, dass ein mit JavaScript arbeitender Hyperlink auch ohne das Attribut „onkeypress“ tastaturfähig ist. Andererseits schluckt der Validator einige Seiten mit semantischen Fehlern ohne Klage.

So hilft Bobby bestenfalls geübten Entwicklern dabei, aus der Mängelliste diejenigen herauszupicken, die richtig erkannt wurden. Einsteiger verunsichern die falschen Fehlermeldungen eher, als dass sie helfen würden.

Ähnliches gilt auch für andere Produkte der Sorte „Klick’ deine Sorgen weg“. Jetzt wo die Deadline für den obligatorischen Umstieg auf barrierefreie Seiten näher kommt, bieten viele Unternehmen Werkzeuge an, die bestehende Seiten behindertengerecht machen sollen. Die meisten dieser Tools grasen die vorhandenen Seiten aber lediglich stur nach häufigen Formfehlern wie etwa fehlenden alt-Attributen ab. Das mag für den Anfang eine hilfreiche Stütze sein, macht eine Site aber noch lange nicht barrierefrei.

Auf semantisch unstrukturierten Seiten erwartet sehbehinderte Besucher eine chaotische Abfolge von Inhalten, die stellenweise zudem falsch vorgelesen werden. Damit ein Screen Reader die Zeichenfolge „USA“ nicht als Usa ausspricht, sondern durchbuchstabiert, muss sie als Abkürzung gekennzeichnet sein, am besten mit einer Erklärung im title-Attribut.

<acronym title="United States Of America">USA</acronym>

Texte bestehen nicht nur aus Worten und Sätzen; sie folgen auch einer logischen Struktur. Das beginnt mit der Unterscheidung von Überschriften (<h1> bis <h6>) und Absätzen und setzt sich fort mit Aufzählungen und Listen mit Gliederungspunkten.

Für kurze und längere Zitate, Adressangaben, Code-Schnipsel und Definitionen sehen HTML und XHTML spezielle Syntaxelemente vor. Diese Möglichkeit sollte man auch nutzen - sowohl im Sinne der Barrierefreiheit als auch um diese Elemente optisch gezielt per Style Sheet auszeichnen zu können.

Hat man sich erst einmal an die Trennung von Form und Inhalt gewöhnt, will man im nächsten Schritt auch das HTML-Dokument selbst in seine Bestandteile zerlegen. So könnte man Navigationsleisten, Kopf- und Fußzeilen und sonstige Elemente von den eigentlichen Inhalten getrennt bearbeiten.

Zur Umsetzung dieses Vorhabens gibt es mehrere Ansätze. Der bei weitem schlechteste besteht darin, mit Frames zu arbeiten - je ein Frame für den Seitenkopf und -fuß, ein dritter für die Navigationsleiste und der letzte für den Inhalt. Für Suchmaschinen und Screen Reader sind Frames jedoch Gift. Eine bessere Methode besteht darin, die Seitenstruktur nach ihrer Funktion in separate Dateien aufzuteilen, die erst später wieder zusammengeführt werden.

Die einfachste Methode dazu sind Server Side Includes (SSI). Eine detaillierte Beschreibung zur Funktionsweise findet sich unter [6]; daher hier nur die Kurzfassung. SSI ist eine von allen gängigen Web-Servern angebotene Methode, Dateien in andere einzubinden. Der Server jagt dazu jede Seite mit der Endung „.shtml“ durch einen Parser, der die darin enthaltenen SSI-Befehle auswertet und ausführt. Im nebenstehenden Kasten findet sich ein kurzer Überblick über die wichtigsten SSI-Befehle. Eine vollständige Liste findet sich unter anderem bei SelfHTML [7].

Die Folgen der Befehle bekommt man erst zu sehen, wenn sie den Server-Parser durchlaufen haben. Daher empfiehlt es sich, zu Testzwecken einen lokalen Server zu installieren wie die Freeware-Pakete LAMP oder XAMPP [8].

Per SSI lassen sich ohne weiteres Kopf- und Fußzeilen sowie Navigationsleisten in zentrale Dateien auslagern, die nur das relevante Code-Stückchen enthalten. Wie bei CSS muss man dann nur noch ein Dokument bearbeiten, um eine Änderung in allen SHTML-Dateien durchzuführen, die es einbinden. Die Zeitersparnis ist enorm; der Aufwand bei der Site-Pflege schrumpft.

Server Side Includes sind auch sehr suchmaschinenfreundlich, da deren Robots die SSI-Befehle selbst nicht zu sehen bekommen, sondern nur das Ergebnis - so nehmen sie die Seite als ganz normale HTML-Dokumente wahr.

Einen Schritt weiter gehen Skriptsprachen wie ASP oder PHP. Hiermit lassen sich komplexere Anweisungen umsetzen wie etwa Hyperlinks, die in der hierarchischen Baumstruktur eines Server-Verzeichnisses selbstständig von einem Dokument zum nächsten führen. Ähnlich funktionieren auch Content-Management-Systeme (CMS) - die meisten sind letztendlich nicht viel mehr als Skript-Frontends.

Mit ASP, PHP oder Python arbeitende Websites beziehen üblicherweise die Inhalte und Navigationsstrukturen aus einer Datenbank. Ein Klick des Besuchers startet eine Abfrage, aus der das Skript oder CMS eine Seite erzeugt, die dann an den Browser des Anwenders geschickt wird. Die Funktion der Skriptsprache besteht also darin, Seiten aus verschiedenen Datensätzen zusammenzupuzzeln. Im Extremfall bestehen skriptgestützte Websites aus einer einzigen Seite, die stets dynamisch gefüllt wird - die letzte Konsequenz aus der Trennung von Form und Inhalt.

Streng genommen stellt die Trennung von Form und Inhalt nur eine Vorstufe zum barrierefreien Web-Design dar. Will man aber konsequent auf ein behindertengerechtes Design umstellen, sind die vorangegangenen Schritte unvermeidlich.

Behindertengerechtes Web-Design beginnt mit der Wahl geeigneter Farben - auch farbenblinde Internet-Nutzer gehören zur Gruppe der Sehbehinderten. Die meisten von ihnen haben Probleme bei der Unterscheidung von Rot und Grün - diese Farben sollte man daher möglichst nicht kombinieren.

Stärker fehlsichtige Anwender haben dagegen Probleme mit schwachen Kontrasten - einige ziehen sogar negative Kontraste vor. Diesem Publikum kann man zwei Varianten des Site-Designs mit starken Kontrasten anbieten: eine mit schwarzer Schrift auf weißem Hintergrund, die andere mit weißer Schrift und schwarzem Hintergrund.

Geschwächten Augen kommt auch die Möglichkeit zur Skalierung der Schriftgröße entgegen. Am einfachsten geht dies, wenn der Web-Designer ganz auf eine Festlegung von Font-Größen verzichtet - dann kann der Besucher den gewünschten Schriftgrad in den Browser-Einstellungen definieren. Dies schränkt die Design-Möglichkeiten allerdings stark ein, da die meisten Layouts ab einer bestimmten Schriftgröße auseinander platzen. Es kann auch vorkommen, dass Texte ineinander laufen. Hinzu kommt, dass viele Web-Surfer gar nicht wissen, dass ihr Browser überhaupt eine Einstellungsmöglichkeit für den Schriftgrad bietet.

Eine Alternative besteht im Einsatz eines so genannten Style Switcher. Dabei handelt es sich um ein Server-Skript, das die Seiten alternativ mit unterschiedlichen Style Sheets anzeigt. Der im ersten Teil erwähnte CSS Zen Garden nutzt beispielsweise ein solches Skript. Besucher finden im Navigationsbereich der Seite einen Link zum Style Switcher, stellen dort das von ihnen vorgezogene Aussehen ein und nutzen von da an das durch die Auswahl gewählte Style Sheet.

Über einen Style Switcher lassen sich unkompliziert verschiedene optische Varianten der Site mit unterschiedlichen Schriftgrößen und Farbschemata anbieten. Hier zahlt sich die konsequente Auslagerung aller optischen Veränderungen in separate Stilvorlagen aus. Das dazu benötigte Skript kann man entweder selbst entwickeln oder aus dem Web herunterladen - eine Google-Suche führt schnell zu reicher Ausbeute in ASP, JavaScript oder PHP.

Besucher mit motorischen Einschränkungen stellen andere Anforderungen an das Web-Design. Die meisten arbeiten mit technischen Hilfsmitteln, die eine virtuelle Tastatur auf dem Bildschirm einblenden, die mit einem großen Stick bedient wird. Andere navigieren mit Großfeldtastaturen. Zu einer Zugangshürde entwickeln sich hier JavaScript-Menüs, die erst bei genauer Mausplatzierung ausklappen.

Lässt man sich einmal mit einer Testversion von JAWS oder Window-Eyes die eigene Homepage vorlesen, entwickelt sich das schnell zur wahren Geduldsprobe. Ach, gäbe es doch eine Möglichkeit, schnell zum eigentlichen Inhalt der Seite zu springen, oder einen fixen Weg zu den umliegenden Seiten. Die gute Nachricht: Gibt es alles. Jetzt die schlechte: Nur, sofern es der Entwickler vorgesehen hat.

Zwei konkrete Möglichkeiten gibt es zur Erleichterung der Navigation: spezielle Tastenkürzel zum direkten Zugriff auf vordefinierte Seiten sowie die Steuerung der Link-Anwahl über die Tabulatortaste.

Vielen sehenden Anwendern ist unbekannt, dass die Tabulatortaste in allen gängigen Browsern von einem Hyperlink des Dokuments zum nächsten wechselt - bei Frames allerdings stets nur innerhalb des aktuellen Rahmens. Normalerweise geht der Browser dabei die Links in der Reihenfolge durch, in der sie im Quelltext vorkommen.

Mit dem tabindex-Attribut kann der Web-Designer diese Reihenfolge allerdings auch manipulieren, um direkt zu bestimmten Seitenbereichen zu führen. Das Attribut lässt sich bei allen <a>-Tags und Formularfeldern einsetzen. Ein Beispiel:

<a href="dateiname.html" tabindex="5">Linktext</a>

Eine noch direktere Verlinkungsmöglichkeit bieten Accesskeys. Über diese können behinderte Besucher bestimmte Links gezielt und direkt ansteuern, ohne sich mit der Tabulator-Taste durch alle Verweise der Seite zu kämpfen.

Alle modernen Browser unterstützen Accesskeys: Der Internet Explorer kennt sie unter Windows seit Version 4, unter Mac OS seit der Revision 5.5, Netscape seit Version 6 und Mozilla von Anfang an. Opera beherrscht die Funktion erst seit Revision 7.02 und zeigt in der Implementierung noch einige Schwächen.

Unterschiede gibt es allerdings bei der konkreten Umsetzung der Funktion: Internet Explorer fokussiert den mit einem Accesskey belegten Link und öffnet ihn erst nach Bestätigung mit der Eingabetaste. Mozilla und Opera führen den Link dagegen sofort aus.

Im Internet Explorer und Mozilla dient die Alt-Taste zur Aktivierung der Accesskeys; bei Opera ist es die etwas unhandliche Kombination Umschalt+Escape. Die Lösung der beiden großen Browser-Hersteller kollidiert hingegen mit einer Eigenschaft des Windows-Betriebssystems: Alle Anwendungsmenüs werden mit Alt-Tastenkombinationen aufgerufen, darunter Alt+D für Datei, Alt-Leertaste für Fenster und viele andere.

Erschwerend kommt hinzu, dass die konkreten Alt-Kürzel je nach Sprache des Betriebssystems variieren - was hierzulande Alt-D ist, ist für Amerikaner Alt-F (File) und für Spanier Alt-A (Archivo). Da Accesskeys eine höhere Priorität haben als das Dateimenü, würde ein Accesskey „D“ das Dateimenü lahm legen. Es bleiben effektiv also wenig „sichere“ Tasten übrig, eigentlich nur die Zahlen 0 bis 9.

<a href="dateiname.html" accesskey="1">Linktext</a>

Die Auswahl der Hyperlinks für die zehn international verfügbaren Accesskeys sollte wohlüberlegt sein: Um Behinderten tatsächlich eine Orientierungshilfe zu bieten, müssen sie für die gesamte Site gelten.

Ein paar unverbindliche Vorschläge: „1“ verlinkt auf die Hauptseite, „2“ zu einer Auflistung aller Accesskeys, „0“ führt bei mehrteiligen Beiträgen zur folgenden Seite, „9“ dagegen zur vorangegangenen Seite.

Damit der behinderte Anwender überhaupt erfährt, dass die Site Accesskeys bietet, müssen diese im Title-Attribut der Hyperlinks aufgeführt werden. Diese Schaltfläche führt beispielsweise zu einem Impressum:

<a href="impressum.html" accesskey="1" title="Unser Unternehmen - Accesskey 1"><img src="button.jpg" alt="Impressum" /></a>

Der Button ist eine Grafik mit einem alt-Attribut, das den von der Grafik angezeigten Text wiedergibt. Das erklärende title-Attribut steht im a-Tag. Bei abgeschalteten Bildern erscheint also „Impressum“ als Platzhalter. Schwebt der Mauszeiger über dem Hyperlink, erscheint eine QuickInfo mit dem Inhalt des Title-Attributs („Unser Unternehmen - Accesskey 1“). Diesen gibt auch der Screen Reader aus.

Auch hier zahlt sich wieder eine saubere Trennung von Inhalten und dem Drumherum aus: Wer seine Navigation per SSI oder PHP ausgelagert hat, muss die Accesskeys nur einmal in der Datei mit der Navigation definieren. Dynamische Verweise auf die jeweils vorangehende oder folgende Seite lassen sich nur bei dynamisch oder automatisch generierten Sites umsetzen - sei es direkt per PHP oder mittels eines Content Management Systems.

Hartnäckig hält sich bei einigen Web-Designern die falsche Überzeugung, barrierefreies Web-Design bedeute einen vollständigen Verzicht auf Grafiken. Diese Einschränkung bietet lediglich den einfachsten Weg, die Lesbarkeit einer Seite zu gewährleisten. Doch der Verzicht auf Grafiken garantiert noch lange nicht, dass die Seite behindertengerecht ist.

Barrierefreiheit bedeutet vielmehr, dass alle Bildelemente so aufbereitet sind, dass sich deren Inhalt auch für Behinderte erschließt. Dies beginnt bei bedacht eingesetzten alt- und title-Attributen und führt bis zu ausführlichen Beschreibungen in separaten HTML-Dokumenten. Viele Web-Designer stecken Klöpse wie „Klicken Sie hier für unsere aktuelle Angebotsliste“ oder „© 2000 Beispielverlag“ ins alt-Attribut und freuen sich dann, wenn der Internet Explorer (und nur dieser) ein QuickInfo-Kästchen mit dem gewünschten Inhalt zeigt.

Für diesen Zweck sehen HTML und XHTML jedoch das title-Attribut vor: Es funktioniert gleichermaßen unter Linux, Mac OS und Windows bei Internet Explorer, Netscape und Opera. Wenn es um die title-Anzeige geht, sind sogar K-Meleon und Safari mit vollem Einsatz dabei.

alt steht hingegen für „alternate“ - alternativ. Der Inhalt dieses Attributs soll also nur ausgegeben werden, sofern der Browser das Bild nicht anzeigt. Entsprechend sollte hier also etwas stehen, was als Platzhalter dienen kann. Bei einem Button mit der Aufschrift „Angebotsliste“ wäre also alt=“grünes Rechteck mit Schrift“ ebenso deplatziert wie alt=“angebotsl.gif“. Attribute mit dem Dateinamen des Bildes stammen oft von Web-Editoren, die das Attribut übereifrig vollautomatisch ausfüllen - schließlich muss laut XHTML-Spezifikation jedes Bild ein solches Attribut erhalten. Angemessen wäre also nur alt=“Angebotsliste“. Dient ein Bild lediglich als Platzhalter, sollte es ein leeres alt-Attribut enthalten (alt=““) - Screen Reader interpretieren dies dann als „Dieses Bild hat keine Bedeutung“ und überspringen es einfach.

Ein paar Beispiele für sinnvolle alt-Attribute:

  • Button: Beschriftung (alt=“Angebotsliste“)
  • Logo: Beschriftung; bei Logos ohne Text der Herstellername (alt=“Beispielverlag“)
  • Grafik ohne Link, zum Beispiel Wegbeschreibung: kurze Beschreibung (alt=“Wegbeschreibung“)

Sinnlos sind hingegen folgende Attribute:

  • Dateinamen oder -größen (alt =“Bild, 45 kByte“)
  • lange Bildbeschreibungen (alt=“Hier sehen Sie das wunderschöne ...“)
  • Leerzeichen (alt=“ “)

Problematisch wird es bei Bildern mit viel Text - etwa dem Scan eines Presseberichts oder ähnlichem Material. Das führt nicht zuletzt dazu, dass Leser immer wieder anfragen, wie man im alt-Attribut einen Zeilenumbruch hinbekommt. Doch für lange Beschreibungen ist dieses Syntaxelement weder gedacht noch geeignet.

Ausführliche Bildbeschreibungen für Screen Reader lassen sich mit einer längeren Beschreibung verlinken, die in einer separaten HTML-Datei unterkommt. Dazu dient das Attribut longdesc (für „Long Description“), das auf die URL mit der Beschreibung verweist. Ein Beispiel:

<img src="beispiel.jpg" alt="Beispiel" longdesc="beschreibung.html" />

In Zusammenarbeit mit den Mozilla-Browsern werten Screen Reader das longdesc-Attribut schon heute aus - nicht aber beim Internet Explorer. Damit auch Anwender des Microsoft-Browsers die Seite mit der ausführlichen Erläuterung finden, kann man neben das Bild einen kleinen Link unterbringen:

<a href="beschreibung.html" title="Verweis zur Bildbeschreibung">[D]</a>

Long Descriptions ergeben nur dann Sinn, wenn das Bild darin anschaulich in allen Einzelheiten beschrieben wird. Blinde und sehbehinderte Anwender werden die Mühe zu schätzen wissen.

Trotz der vielen Worte gegen den Einsatz von Tabellen in HTML-Seiten gibt es durchaus Bereiche, in denen Tabellen nicht nur ein notwendiges Übel sind, sondern genau das richtige Syntaxelement: zur Darstellung tabellarischer Daten. Dazu gehören nicht nur Quartalsergebnisse und Fußballtabellen, sondern auch Kalender und ähnliche Strukturen.

Auch hier kann man einiges falsch machen - Screen Reader können Tabellen erst dann strukturiert ausgeben, wenn sie strukturiert aufgebaut sind. Tabellenauszeichnungen helfen aber auch dem Web-Designer dabei, den Überblick zu behalten. Dazu empfiehlt sich zunächst das title-Attribut. Sehbehinderten hilft das summary-Attribut, in dem der Inhalt der Tabelle kurz und prägnant zusammengefasst wird.

Um den Tabelleninhalt für blinde und sehende Besucher gleichermaßen zusammenzufassen, sieht die (X)HTML-Spezifikation das <caption>-Tag vor. Ob dessen Inhalt als Über- oder Unterschrift angezeigt wird, entscheidet das align-Attribut. Prinzipiell funktioniert die Positionierung auch über CSS (z. B. caption side: bottom); doch ignoriert der Internet Explorer diese Auszeichnung.

Innerhalb der Tabelle unterscheiden die Tags <th> und <td> Zellen mit Überschriften von Zellen mit Daten. Angenehmer Nebeneffekt: So lassen sich Überschriften und Daten auch zentral über ein Style Sheet getrennt voneinander formatieren. Von sich aus heben die Browser den Inhalt von <th>-Tags durch Fettschrift hervor.

Bei der Entschlüsselung von Abkürzungen in Tabellenüberschriften hilft das abbr-Attribut. So verhindert <th abbr=“Standardabkürzung“>Std-Abk.</th>, dass der Screen Reader dem sehbehinderten Besucher nur „Std Strich Abk Punkt“ entgegenspuckt.

Das unten stehende Code-Beispiel zeigt eine barrierefrei aufgearbeitete Tabelle.

Die meisten grafischen Web-Editoren sind nur begrenzt hilfreich, wenn es um die Erstellung barrierefreier Webseiten geht. Dreamweaver MX bietet zwar einen Accessibility-Check, der sich an den US-amerikanischen Vorgaben orientiert. Doch fehlt meist schon den Dialogen zum Einfügen von Grafiken die Option, überhaupt ein title-Attribut zu setzen, geschweige denn einen longdesc-Verweis. Wenn der Weg zur Barrierefreiheit eh stets in die Quelltext-Ansicht zurückführt, kann man auf den grafischen Bearbeitungsmodus meist ganz verzichten.

Bei einem Design, das die optische Gestaltung der Seite komplett in Style Sheets auslagert, verliert ein WYSIWYG-Editor seinen wichtigsten Vorteil. Nützlicher ist ein brauchbarer CSS-Editor mit einer guten grafischen Vorschau der getroffenen Stilentscheidungen. Den HTML-Teil kann man ebenso gut mit einem HTML-Texteditor wie „Phase 5“ oder HTML-Kit schreiben. Wer viel Text vor sich hat, kann diesen in einem einfachen grafischen HTML-Editor wie den mit Mozilla ausgelieferten Composer verfassen und die relevanten Bereiche dann per Cut & Paste in den Quelltext der eigentlichen HTML-Datei überführen. Diese Aufgabe kann natürlich auch ein anderer WYSIWYG-Editor übernehmen, sofern dieser den Quelltext nicht selbstständig mit Syntaxelementen anreichert, die dort nicht hingehören.

Auf den ersten Blick mag barrierefreies Web-Design wie eine neuerliche Plackerei erscheinen, die viel Aufwand für eine kleine Zielgruppe bedeutet. Diese Betrachtungsweise greift aber erheblich zu kurz; Barrierefreiheit ist kein Selbstzweck. Standardkonform gestaltete Seiten erreichen nicht nur eine größere Zielgruppe, sie sind auch leichter zu pflegen. So profitieren Anwender und Entwickler gleichermaßen von barrierefreiem Web-Design. Das sollte einem die Umstellung wert sein. (ghi)

Die Autorin arbeitet als Entwicklerin bei der Web-Design-Agentur Cyberworking.

[1] HTML-Validator des W3C: http://validator.w3.org

[2] CSS-Validator des W3C: http://jigsaw.w3.org/css-validator/

[3] Deutschsprachiger HTML-Validator von SelfHTML: http://validator.de.selfhtml.org/

[4] Zugangsrichtlinien für Web-Inhalte: http://www.w3c.de/Trans/WAI/webinhalt.html

[5] Bobby 5.0, Accessibility-Validator: http://bobby.watchfire.com/bobby/html/en/index.jsp

[6] Sven Lennartz, Dynamische Seiten, Server Side Includes richtig einsetzen, c’t 20/01, S. 224

[7] SelfHTML zu SSI: http://de.selfhtml.org/cgiperl/intro/ssi.htm

[8] Helge Peter Cramer, Thorsten Schramm, Auswärtsspiel, Der eigene PC als Internet-Server, c’t 14/04, S. 140

[9] Aural Style Sheets: http://www.w3.org/TR/REC-CSS2/aural.html

[10] Mozilla anpassen: http://www.mozilla.org/unix/customizing.html

[11] Barrierefreie Informationstechnik-Verordnung: http://www.bmi.bund.de/dokumente/Artikel/ix_90156.htm

Vorgeschichte

Die wichtigsten Punkte aus Teil 1 (c't 18/04, S. 186):

Der „Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz“ folgend müssen aus der öffentlichen Hand finanzierte Websites bundesweit bis Ende 2005 barrierefrei sein. Diese Eigenschaft ist einklagbar.

Sehbehinderte Anwender besuchen Websites mit einem Screen Reader, der seine Ergebnisse per Sprach-Synthese oder über eine Braille-Zeile ausgibt. Um Seiten sinnvoll wiederzugeben, sind Screen Reader auf logisch strukturierte HTML-Syntax angewiesen. Die Programme lesen alle Seitenelemente in der vom Quelltext vorgegebenen Reihenfolge vor.

Barrierefreiheit setzt eine konsequente Trennung von Form und Inhalt voraus. Zur optischen Gestaltung dienen Cascading Style Sheets (CSS); zur Strukturierung der Inhalte HTML beziehungsweise dessen Nachfolger XHTML. Die Trennung hat den Vorteil, dass sich die Websites einfacher verwalten und pflegen lassen.

Semantisches Web

<h1>Barrierefreies Web-Design</h1>
<h2>Die logische Struktur einer Webseite</h2>
<p>Damit Webseiten allgemein zugänglich sind, müssen u. a. folgende Punkte
beachtet werden:</p>
<ul>
<li>syntaktisch korrekter Quelltext</li>
<li>korrekte Semantik</li>
<li>[…]</li>
</ul>
<p>Wenn Sie weitere Fragen zum <acronym title="World Wide
Web">WWW</acronym> haben, wenden Sie sich bitte an</p>
<address>Name<br />
Strasse<br />
Ort</address>

SSI-Befehle - Kurzübersicht

Alle Befehle führen dazu, dass der Server anstelle der SSI-Anweisung den gewünschten Inhalt einfügt.

<!--#include virtual=“/ordner/datei.html“ -->
Datei datei.html einfügen

<!--#echo var=“DATE_LOCAL“ -->
derzeitiges Datum und Uhrzeit des Servers einfügen

<!--#echo var=“LAST_MODIFIED“ -->
Datum und Uhrzeit der letzten Aktualisierung des aktuellen SHTML-Dokuments

<!--#echo var=“DOCUMENT_NAME“ -->
Name des aktuellen SHTML-Dokuments einfügen

<!--#echo var=“SERVER_SOFTWARE“ -->
Verwendete Server-Software einfügen

<!--#echo var=“HTTP_USER_AGENT“ -->
Browser-Name des Besuchers einfügen

<!--#exec cgi=“/cgi-bin/skript.pl“ -->
Ergebnis des Skripts skript.pl einfügen

Demonstriert und demaskiert

Doch grau ist alle Theorie ... daher steht auf dem Heise-Server eine Beispielseite bereit, um barrierefreies Web-Design zu illustrieren. Unter www.ctmagazin.de/barrieretest findet sich ein Beispieldokument, das die Funktionsweise eines Style Switcher demonstriert.

Dabei stellen Links in der Navigationsleiste das Style Sheet dynamisch um, ohne den HTML-Code zu berühren. Die Seite wurde bewusst spartanisch gehalten. Zu den angebotenen Vorlagen gehören zwei kontrastintensive Style Sheets (Schwarz auf Weiß, Weiß auf Schwarz) sowie eine Ansicht ohne Style Sheet, der den Inhalt der Seite ohne optische Formatierungen zeigt. Eine weitere Stilvorlage dient zur Anpassung der Schriftgröße - so kann der Anwender die Standard-Schriftgröße je nach Bedarf zwischen 9 und 21 Punkt skalieren.

Einen weiteren Anreiz zum Besuch der Testseite bietet ein spezielles CSS, um Seiten auf Barrierefreiheit zu testen. Die Stilvorlage barrieren.css hebt alle veralteten Tags und allein der Optik dienliche Syntaxelemente farblich hervor. Die Farbe richtet sich dabei nach dem Grad der Unverträglichkeit und umfasst ein Spektrum von Rot (schlimm) über Grün bis Blau (okay).

Lädt man dieses Style Sheet auf den eigenen Rechner und bindet es in seine eigenen HTML/XHTML-Dokumente ein, zeigt der Browser schnell, wo etwas im Argen liegt. Knallrot, Orange und Gelb zeigen absteigend schlechte Bereiche auf. Grün, Hellblau und Tiefblau markieren barrierefreie Elemente in aufsteigender Reihenfolge. Rote Bereiche sind also inakzeptabel, blau ist dagegen ein gutes Zeichen.

Im Internet Explorer lässt sich die demaskierende Vorlage auch direkt installieren: Dazu lädt man zuerst barrieren.css auf den eigenen Rechner, klickt dann unter Extras/Internetoptionen/Allgemein unten rechts auf die Schaltfläche „Eingabehilfen ...“. Im darauf folgenden Dialog aktiviert man unter der Überschrift Benutzerstylesheet „Dokumente mit dem eigenen Stylesheet formatieren“ und wählt im Auswahldialog die heruntergeladene Datei. Ähnlich funktioniert dies bei Opera; hier findet sich der Auswahldialog bei Tools/Einstellungen unter Seitendarstellung/Eigenes Stylesheet.

Mozilla/Firefox macht es seinen Anwendern nicht ganz so leicht; hier ist die Stilvorlage zunächst in userContent.css umzubenennen, bevor man sie in das „chrome“-Unterverzeichnis des Anwenderprofils kopiert. Eine detaillierte Beschreibung des Vorgangs findet sich unter [10].

Alle verwendeten Tabellen fallen durch einen zwei Pixel breiten roten Rahmen ins Auge, da das Style Sheet nicht zwischen bösen Layout-Tabellen und gut aufbereiteten tabellarischen Daten unterscheiden kann. Dies sollte der Betrachter aber selbst problemlos unterscheiden können. Bilder mit veralteten Attributen kennnzeichnet die Stilvorlage mit einem roten Rand; transparente GIFs werden zusätzlich durch einen gelben Hintergrund gekennzeichnet. Strukturierter Code wird mit grüner Farbe markiert; speziell für Barrierefreiheit nützliche Tags wie <cite> und <acronym> mit blau belobigt. Eine ausführlichere Aufschlüsselung darüber, was die Farben bedeuten, findet sich auf der Beispielseite.

Stimmen-Tuning

Wer die Hürden zur Barrierefreiheit gemeistert hat, kann noch etwas Fleißarbeit leisten und die Sprachausgabe des Screen Readers per Style Sheets optimieren.

Auf sich gestellt, liest der Screen Reader die Seiten modulationsarm mit einer synthetischen Stimme vor. Dabei reiht die Software die Buchstaben des Textes nach bestem Vermögen aneinander, was nicht immer gut geht. c't spricht der Screen Reader beispielsweise als „Zeh Apostroph Teh“ aus und „...“ gibt er stur als „Punkt Punkt Punkt“ wieder. Fremdwörter ertönen oftmals mit teutscher Aussprache - höchst gewöhnungsbedürftig.

Bereits anhand der Einstellungsmöglichkeiten der Software lässt sich die Sprachausgabe etwas verbessern. Doch auch der Web-Designer kann bei der Optimierung helfen - mit einem auf Screen Reader abgestimmten Style Sheet.

CSS bietet zahlreiche Optionen zur Konfiguration von Screen Readern über Aural Style Sheets - ob die Stimme moduliert oder monoton klingt, wie laut und schnell sie sprechen soll, männlich oder weiblich und sogar eine zur font-family analoge voice-family. Die Implementierung dieser Funktionen in den Browsern ist aber noch nicht abgeschlossen. Mit allen Feinheiten garnierte Style Sheets sorgen also nur für die Zukunft vor, ohne unmittelbaren Nutzen zu bringen. Mehr zu Aural Style Sheets findet sich unter [9].

Behindertengerecht geblitzt

Seit Flash 6 wirbt der Hersteller Macromedia mit den Accessibility Features seines Players. So ist es durchaus richtig, dass aktuelle Versionen des Flash Players die Inhalte von Flash-Animationen grundsätzlich für Screen Reader verfügbar machen. Mittlerweile ermöglicht das Flash-Autorensystem auch eine Trennung von Inhalt und Gestaltung. Mit der Flash-eigenen Skriptsprache ActionScript können Entwickler beispielsweise definieren, in welcher Reihenfolge die Objekte einer Animation mit der Tabulator-Taste angesprungen werden sollen. Weitere ActionScript-Funktionen ändern auch die Farben von Text und Hintergrund oder passen den Schriftgrad an die Bedürfnisse des Betrachters an.

Die Grundlagen für barrierefreies Flash sind also durchaus gelegt. Doch die meisten Screen Reader am Markt können die Informationen des Flash Player 6 noch nicht auslesen - bisher beherrschen dies nur die Programme JAWS, OutSpoken und Window-Eyes. Das kostenlose „Webformator“ hilft allen Screen Readern unter Windows dabei, Alternativtexte und Texte aus Flash-Dateien auszulesen.

Die größten Hürden auf dem Weg zum barrierefreien Flash liegen allerdings darin, wie Entwickler mit den Möglichkeiten umgehen. Damit der Besucher die Accessibility-Features nutzen kann, müssen Flash-Autoren sie erst einmal einsetzen. Zudem wird Flash meist zu Visualisierungszwecken eingesetzt - hier liegt ja gerade der Vorteil des Formats. Nur auf die sprachliche Komponente reduziert, bleibt von den meisten Flash-Anwendungen nicht viel übrig.

Tabellarische Daten

<table title="Beispieltabelle" summary="Diese Tabelle dient als Beispiel für einen
Artikel über Barrierefreiheit.">
<caption>Barrierefreie Tabellen-Layouts</caption>
<tr>
<th>&nbsp;</th>
<th>barrierefrei</th>
<th>Syntaxsuppe</th>
</tr>
<tr>
<th>Textformatierung</th>
<td>in Style Sheet</td>
<td>per Font-Tag</td>
</tr>
<tr>
<th>Layout</th>
<td><acronym title="Cascading Style Sheets">CSS</acronym></td>
<td>Layout-Tabellen</td>
</tr>
</table>

BITV für Dummys

Ganz einfach zu verdauen sind sie nicht, die Forderungen der „Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz“ des Bundesinnenministeriums. Im Folgenden daher eine Zusammenfassung der 14 Punkte [11].

Anforderungen der Prioritätsstufe II finden sich in Kursivschrift wieder - sie sind für „zentrale „Navigations- und Einstiegsangebote“ nötig. Die Forderungen im Einzelnen:

1. Behindertengerechte Alternativen für alle Audio-, Bild- und Video-Inhalte:

  • alternative Texte für Skripte, Applets, Frames und Bilder und Grafiken - auch bei Platzhaltern, Gliederungspunkten und Zeichnungen
  • Text-Alternativen zu Server-Side Image Maps zu Client-Side Image Maps
  • Audio-Beschreibungen für Videoinformationen in Multimedia-Präsentationen; Untertitel für Videos

2. Für Fehlsichtige deutlich erkennbare Texte und Grafiken

  • Unterscheidungen müssen auch ohne Farbe verständlich sein
  • kontraststarke Bilder für Schwarzweiß-Bildschirme und farbfehlsichtige Besucher

3. Standardkonformer Einsatz von HTML und Style Sheets

  • wo immer möglich, Informationen über Sprachsyntax darstellen statt Bildern
  • validierbare Sprachsyntax einhalten
  • optische Präsentation von Text und Bildern durch Style Sheets
  • in Style Sheets relative statt absolute Einheiten verwenden
  • Überschriften, Listen und Zitate strukturell gliedern

4. Abkürzungen und Sprachwechsel erkennbar machen

  • Akronyme und Abkürzungen bei erstem Auftreten durch Syntax-Elemente aufschlüsseln
  • Identifikation der vorherrschenden Sprache durch Syntax-Elemente

5. Tabellen mit Beschreibungen versehen und ausschließlich zur tabellarischen Darstellung verwenden

  • Spalten- und Zeilenüberschriften kennzeichnen
  • Gliederungsebenen (Überschriften, Datenzellen) als solche auszeichnen
  • keine Text- und Bildgestaltung durch Tabellen
  • kein Missbrauch von Strukturierungselementen zur visuellen Formatierung
  • Zusammenfassungen bieten, Abkürzungen aufschlüsseln

6. Internet-Angebote müssen unabhängig vom Browser nutzbar sein

  • ungehinderte Darstellung ohne Style Sheets
  • Seiten auch ohne Skripte, Applets oder andere Plug-ins nutzbar
  • Skripte, Applets und andere Plug-in-Anwendungen unabhängig vom Eingabegerät nutzbar
  • entweder ungehinderter Zugang auf dynamische Inhalte oder Bereitstellung von stets aktuellen statischen Alternativen

7. Nutzerkontrolle aller „zeitgesteuerter“ Inhalte, konkret

  • kein Bildschirmflackern oder blinkende Inhalte
  • keine automatische Bewegung von Inhalten, andernfalls Bereitstellung von Kontrollmechanismen
  • keine automatischen Aktualisierungen in festen Zeitabständen (Refresh u. Ä.)
  • möglichst keine automatischen Weiterleitung auf andere Seiten

8. Behindertengerechter Zugriff auf alle Benutzerschnittstellen

  • Skripte und Applets entweder direkt für Behinderte zugänglich oder zu Screen Readern kompatibel machen

9. Bereitstellung des vollen Funktionsumfangs jedes Internet-Angebots unabhängig vom Ein- oder Ausgabegerät des Besuchers

  • Client-Side Image Maps statt Server-Side Image Maps
  • geräteunabhängige Bedienbarkeit aller aktiven Elemente einer Seite (Buttons, Drop-Down-Listen usw.)
  • logische statt geräteabhängige Event-Handler in Scripts
  • nachvollziehbare Navigation per Tabulatortaste
  • Tastaturkurzbefehle für entscheidende Hyperlinks, Formularanwahl

10. Berücksichtigung älterer Soft- und Hardware, die von Behinderten zum Zugriff auf Inhalte genutzt wird

  • keine Popups oder andere automatisch erscheinenden Fenster
  • Rückmeldung beim Nutzer über Wechsel der Ansicht
  • korrekte Zuordnung von Beschriftungen und Formular-Kontrollelementen
  • linearer Alternativ-Text für Tabellen mit Zeilenumbrüchen
  • Platzhalterzeichen für leere Kontrollelemente
  • klare druckbare Trennung nebeneinander liegender Links

11. Öffentliche und vollständige Dokumentation aller zur Erstellung eines Internet-Angebots verwendeten Technologien

  • Nutzung von öffentlich dokumentierten Technologien in der jeweils aktuellen Version, soweit angemessen
  • keine Nutzung veralteter Funktionen
  • Bereitstellung eines alternativen barrierefreien Angebots mit gleichwertigem Funktionsumfang, sofern primäres Angebot nicht barrierefrei gemacht werden kann; Ersatz bei Verfügbarkeit behindertengerechter Alternativen
  • Möglichkeit für den Benutzer, Inhalte gemäß ihrer Vorgaben zu erhalten

12. Orientierungshilfen für den Besucher

  • Frames benötigen Titel und Beschreibungen von Funktion und Relation zu anderen Frames
  • syntaktische Unterteilung großer Informationsblöcke in handliche Untergruppen
  • genaue Zuordnung von Beschriftungen zu Kontrollelementen

13. Übersichtliche und schlüssige Navigationsmechanismen

  • Kenntlichmachung des Ziels jedes Hyperlinks
  • Metadaten für semantische Informationen
  • Inhaltsverzeichnisse oder Site Maps als Orientierungsmechanismen
  • Navigationsleisten, Gruppierung zusammenhängender Hyperlinks
  • unterschiedliche Suchmöglichkeiten
  • zur Differenzierung aussagekräftige Einleitung für zusammenhängende Informationsblöcke
  • Mechanismen zur Umgehung von ASCII-Zeichen

14. Maßnahmen zur Erleichterung des Verständnisses der angebotenen Inhalte

  • einfache und klare Sprache für alle Inhalte
  • Ergänzung von Texten durch Grafiken oder Audio zur Förderung des Verständnisses

Kommentare

Anzeige