Redaktionelle Richtlinien zur Erstellung barrierefreier Websites mit
1. Einführung Alle Internet Portale des öffentlichen Sektors sollten den Richtlinien der BITV (Barrierefreie Informationstechnik Verordnung) Priorität genügen. Die Stufe Priorität I der BITV umfasst den internationalen Standard der Web Content Accessebility Guidelines 1.0 (WAI) der Stufe A und AA. Um die gesamte Problematik besser verstehen zu können, werden zunächst ein paar grundlegende Informationen gegeben. Im Weiteren werden dann die redaktionellen Grundsätze beschrieben, die von Online Redakteuren beachtet und eingehalten werden müssen, wenn sie Beiträge in das Content Management System (CMS) webcom content einstellen. 2. Grundsätzliches zum Verständnis Um überhaupt mit dem Computer arbeiten zu können, benötigen Blinde und ein Teil der Sehbehinderten zusätzliche Lösungen, die die Signale an den Bildschirm abfangen und interpretieren. Als Lösungen kommen hier zumeist Screen-Reader und Braille-Zeilen zum Einsatz. Eine Braille-Zeile ist eine erweiterte Tastatur, die unterhalb der "normalen" Tasten einen Ausgabebereich für Zeichen in Blindenschrift enthält. Die Übersetzung des Bildschirminhalts für blinde Computerbenutzer durch den Screen-Reader erfolgt entweder in Blindenschrift über die Braille-Zeile oder in synthetischer Sprache, beispielsweise über eine Soundkarte. Die Eingabe in den Computer ist hingegen unproblematisch und geschieht über die Tastatur. Unter diesen Voraussetzungen können Blinde und Sehbehinderte im WWW surfen. Natürlich ist dies mit gewissen Einschränkungen verbunden. Die Inhalte von Bildern und Grafiken bleiben nach wie vor "verborgen". Ein bedeutsamer Nachteil von Screen-Readern ist ihre statische Funktionsweise. Wenn der Bildschirminhalt einmal eingefangen ist, werden dynamische Prozesse nicht mehr erfasst. Änderungen von Grafiken oder anderen Elementen, oder zusätzliche Informationen bei Mouseover bleiben einem Screen-Reader verborgen. Solche dynamischen Seiten werden meist mit JavaScript oder anderen Skripten erzeugt, die Browserseitig ausgeführt werden. Auf solche Scripte muss nicht zwingend verzichtet werden. Jedoch sollte man bei entscheidenden Stellen, die für die Interaktion wichtig sind, eine Alternativeingabe über einen Link vorsehen. Es leuchtet den meisten ein, dass rote Schrift auf grünem Hintergrund schwieriger zu erkennen ist als gelb auf blau oder schwarz auf weiß. Bei der Gestaltung von Buttons und sonstigen Symbolen ist dies besonders wichtig, denn diese sind im Browser nicht manipulierbar. Hingegen besteht die Möglichkeit, bei Fließtext Farbvorgaben zu ignorieren. Aber auch wenn man im Browser Farben ignorieren lassen kann, sind viele Sehbehinderte nicht darauf angewiesen. Jedoch tauchen gelegentlich Seiten auf, die nur einen geringen Kontrast zwischen Text und Hintergrund aufweisen. Bei der Textgestaltung ist also auch auf die Farbgebung zu achten. Oft werden sogenannte "Dummies" (transparente Grafiken) zum Einrücken oder Schaffen von Seite 1
Abständen zwischen Textteilen eingesetzt. Da sie unsichtbar sind und sein sollen, werden sie ohne Alternativtext belegt. Für Blinde sind solche Grafiken ohne Textangabe immer ein Rätsel, da sie nie wissen, ob sich ein informatives Bild dahinter verbirgt. Die Dummies unterbrechen auch den Lesefluss, da sie von den Screen-Readern erfasst und ausgewertet werden. Wenn nicht auf die Dummies verzichtet werden kann, dann sollten die Grafiken sinnvolle Namen wie "layout.gif" und "transparent.gif" statt "lg2.gif" erhalten, damit zumindest über die Zweitinformation des Dateinamens Klarheit geschaffen wird. Was dem "normalen" User zur Orientierung auf einer Seite oft hilft, sind Überschriften. In der Praxis ist es leider oft so, dass die Überschriften zunächst als Absatz definiert werden und der Text danach über Zeichengröße und/oder fett/kursiv hervorgehoben wird. Dabei verfügt HTML über Überschriften-Befehle, die dem Seitenüberblick bei langen Seiten dienen. Die Nutzung solcher Überschriften (H1, H2,... H6) hilft dem Screen-Reader-Nutzer, schneller einen Überblick auf der Seite zu bekommen. Seite 2
3. Bilder Bei der Verwendung von Bildern in einem Beitrag ist darauf zu achten, das jedes Bild mit einem Alternativtext versehen wird. Dieser Alternativtext sollte das Bild ausreichend genau beschreiben. Nutzer, die aufgrund einer Sehschwäche das Bild nicht erkennen können, müssen sich aufgrund des Alternativtextes eine Vorstellung über den im Bild dargestellten Inhalt machen können. Der Alternativtext muss nicht unbedingt eine ausführliche Beschreibung sein. Bei Buttons reicht der Text auf dem Button. Bei anderen Symbolen ist die Bedeutung meist in ein bis drei Worten ebenfalls hinreichend erklärt. Gelegentlich kann es jedoch notwendig sein, eine längere Erläuterung beizufügen, etwa bei Fotos oder Karikaturen. Hier eignet sich besser als der Alternativtext der D-Link (D = Description, zu deutsch "Beschreibung"). Unmittelbar nach der Grafik kann ein Link mit dem Text "D" zu einer gesonderten Seite führen, die die Grafik ausführlich erläutert. Neben der Beschreibung des Bildes sollte jedes Bild einen Namen erhalten. Für die Codierung eines Bildes nachfolgend ein Beispiel: <img src="baum.jpg" width="320" height="400" name="baumbild" alt="abendbaum"> Legende: img: image, src: source, width: Breite des Bildes in Pixel, height: Höhe des Bildes in Pixel, name: Eindeutige Bezeichnung des Bildes, alt: Alternativer Text Erläuterungen Mit name= vergibt man einen Namen für die Grafik. Der Name sollte nicht zu lang sein und darf keine Leerzeichen, Sonderzeichen oder deutsche Umlaute enthalten. Das erste Zeichen muss ein Buchstabe sein. Danach sind auch Ziffern erlaubt. Als Sonderzeichen im Namen sollte höchstens der Unterstrich (_), der Bindestrich (-), der Doppelpunkt (:) oder der Punkt (.) benutzt werden. Im Hinblick auf JavaScript darf der Name sogar nur Buchstaben, Ziffern und Unterstriche (_) enthalten. Groß- und Kleinschreibung werden bei Sprachen wie JavaScript ebenfalls unterschieden. Der alternativ zur Grafik anzuzeigende Text alt= wird innerhalb des Befehls für die Grafikreferenz notiert. Eingeleitet wird die Anweisung für die Textalternative durch alt= (alt = alternative). Dahinter folgt, in Anführungszeichen eingeschlossen, der Alternativtext. Der Alternativtext wird bei größeren Grafiken auch angezeigt, bevor die Grafiken geladen sind. So kann der Anwender sich schon über den Inhalt der Grafik informieren, bevor die Grafik selbst am Bildschirm angezeigt wird. Wird im Webcom-Artikeleditor die Funktion [Bild einfügen] genutzt, so kann neben der Angabe der Höhe, Breite und Bildausrichtung, auch der Alt -Text editiert werden. Seite 3
4. Verknüpfungen Bei der Integration von internen (im eigenen Internet Portal) und externen Verknüpfungen (Links) müssen entsprechende aussagekräftige Linktexte formuliert werden. Es sollten nur Namen für Links gewählt werden, die einen Bezug zum Ziel haben. Vermeiden Sie solche Terme wie "Hier klicken". Sonstige Texte auf Ihren Seiten, die nicht als Link o. ä. einfach angeklickt werden können, sollten ebenfalls eine bedeutungsvolle Bezeichnung bekommen. Folgende Informationen sollten aus dem Linktext hervorgehen: Welcher Inhalt ist auf der verknüpften Seiten dargestellt Öffnet sich bei Auswahl der Verknüpfungen eine neue Browser Instanz, ein Popup Fenster oder wird die neue Seite im gleichen Browserfenster angezeigt Um welchen Dateityp handelt es sich bei der neuen Seiten. Dies ist insbesondere in den Fällen wichtig, wo Seiten im pdf-format angezeigt werden. Um einen Link zu beschreiben sollte das title -Attribut verwendet werden. Es wird innerhalb des Link-Tags genau so verwendet wie das alt -Attribut bei den Bildern, was folgendes Besipiel zeigt: <a href = http://www.t-online.de target= _blank " title="link zur Homepage von t-online"> www.t-online.de [neues Fenster]</a> Links, die durch den Webcom-Linkeditor eingegeben werden, unterstützen das Title-Tag und können, abhängig vom Layout, auch die automatische Kennzeichnung von Seiten die sich in einem neuen Fenster öffnen, übernehmen. 5. Image Maps Bei Image-Maps handelt es sich um besondere Grafiken, meist mit Menüs, Listen oder andere Bereichen zum Anklicken mit der Maus. Die einzelnen Auswahlbereiche von Image Maps können Screen-Reader ausschließlich über den Titel des Bereichs erfassen. Da die Maps meist zur Navigation auf Übersichtsseiten eingesetzt werden und daher eines der wichtigsten Navigationselemente darstellen, sind die einzelnen Titel besonders sorgfältig auszuwählen. Für ältere Screen-Reader sind Image-Maps unüberwindbare Barrieren. Eine parallele "Nur-Text"-Seite ist nach den WAI-Richtlinien dringend zu empfehlen. Seite 4
6. Tabellen Die Verwendung von Tabellen in Beiträgen sollte nicht gestalterischen Zwecken dienen. Grundsätzlich gilt: Tabellen jeder Art, ob sie eine tabellarische Darstellung enthalten oder für ein Layout von Text eingesetzt werden, können dann am besten gelesen werden, wenn die Zellen Zeile für Zeile von links nach rechts gelesen werden können und immer noch einen Sinn ergeben. 6.1. Tabellen zur Listendarstellung In diesem Sinne sollten Tabellen nicht für Aufzählungen benutzt werden, um eine ordnungsgemäße Zuordnung von Aufzählungszeichen und Text zu garantieren. Vielmehr sollte hier das entsprechende HTML-Tag für Aufzählungslisten (ul = unordered list = unsortierte Liste; li = listenelement) verwendet werden. Für die Codierung hier ein Beispiel: <ul> <li></li> <li></li> </ul> Die grundlegende Formatierung erfolgt im Cascading Style Sheet (CSS) vom Web Design. 6.2. Tabellen zur Bilddarstellung Tabellen sollten nicht zur Bildgestaltung verwendet werden, da sie in linearisierter form (s.o.) nur schwer einen Sinn ergeben. 6.3. Benutzung echter Tabellen Werden Tabellen zur geordneten Darstellung von Daten benutzt (echte Tabellen) müssen die Strukturinformationen der Tabelle im HTML-Code integriert werden. Dies sind im Einzelnen: Tabellenkopf Tabellenkörper Tabellenfuß Den Tabellenkopf leiten Sie mit <thead> ein (thead = table head = Tabellenkopf). Daran anschließend können Sie eine oder mehrere Zeilen der Tabelle notieren, die zum Kopfbereich gehören sollen. Mit </thead> schließen Sie die den Tabellenkopf ab. Den Tabellenkörper leiten Sie mit <tbody> ein (tbody = table body = Tabellenkörper). Daran anschließend notieren Sie den eigentlichen Datenbereich der Tabelle. Mit </tbody> schließen Sie die den Tabellenkörper ab. Den Tabellenfuß leiten Sie mit <tfoot> ein (tfoot = table foot = Tabellenfuß). Daran anschließend können Sie eine oder mehrere Zeilen der Tabelle notieren, die zum Fußbereich gehören sollen. Mit </tfoot> schließen Sie die den Tabellenfuß ab. Seite 5
Kopfzeile einer Tabelle Eine Tabelle kann Kopfzellen und gewöhnliche Datenzellen enthalten. Text in Kopfzellen wird hervorgehoben (meist fett und zentriert ausgerichtet). <th> definiert eine Kopfzelle, <td> eine normale Datenzelle (th = table header = Tabellenkopf, td = table data = Tabellendaten). Der Inhalt einer Zelle wird jeweils hinter dem Tag notiert. In einer Tabellenzelle können beliebige Elemente stehen, d. h. außer normalem Text z. B. auch Verweise oder Grafiken in HTML. Sogar eine weitere Tabelle können Sie innerhalb einer Zelle definieren. Kurzinformation für Tabellenzellen Mit dem Attribut abbr im einleitenden Tag einer Datenzelle (<td>) oder einer Kopfzelle (<th>) können Sie eine Kurzinformation zu der entsprechenden Zelle voranschicken (abbr = abbreviated = verkürzt). Der Text muß in Anführungszeichen stehen. Zusammenfassung eines Tabelleninhaltes Mit dem Attribut summary= können Sie im einleitenden <table>-tag eine Zusammenfassung der Tabelle definieren (summary = Zusammenfassung). Die Angabe muß in Anführungszeichen stehen. Codierung einer barrierefreien echten Tabelle Die Codierung einer echten Tabelle sollte demnach in folgender Art und Weise umgesetzt werden. Wichtig ist noch, zu beachten, dass möglichst keine festen Tabellen- oder Spaltenbreiten verwendet werden. Sollten Breitenangaben zwingend notwendig sein, sind prozentuale Angaben zu verwenden. <table width= 80% border= 0 summary="in der folgenden Tabelle werden Daten zu den Städten Berlin, Hamburg und München ausgegeben"> <thead> <tr> <th>berlin</th> <th>hamburg</th> <th> München </th> </tr> </thead> <tbody> <tr> <td abbr=" Einwohnerzahl von Berlin">2 Millionen Einwohner</td> <td abbr=" Einwohnerzahl von Hamburg">1 Millionen Einwohner </td> <td abbr="einwohnerzahl von Berlin">1,5 Millionen Einwohner </td> </tr> </tbody> <tfoot> <tr> <td abbr="es folgen Infos zu Berlin">Hier eine Menge Inhalt</td> <td abbr="es folgen Infos zu Hamburg">Hier eine Menge Inhalt</td> <td abbr="es folgen Infos zu München">Hier eine Menge Inhalt</td> </tr> Seite 6
</tfoot> </table> 7. Formulare Ein "Spezialfall" der Tastatursteuerung ist der Umgang mit Formularen. Formulare werden manchmal auch für die Navigation eingesetzt, indem eine Liste von Themen o. ä. angegeben werden, z. B. per Auswahlliste, Drop-Down-Menü oder Radio-Button. Bei eingeschränkten motorischen Bewegungsmöglichkeiten sind Radio-Buttons für Navigationsfunktionen eine erhebliche Barriere. Für motorisch Behinderte sollten bei Eingabefeldern möglichst alle Voreinstellungen bereits eingetragen sein. Einen Mehrfachtastendruck wie für das @ können viele kaum schaffen. Für sie ist es gut, wenn das @ bereits im E-Mail-Feld steht, oder noch besser bereits zwischen zwei Feldern steht (<TEXTAREA> @ </TEXTAREA>). Für Sehbehinderte trifft das Gegenteil zu, weil sie unter Umständen gar nicht merken, dass da schon was eingetragen ist oder sich die Adresse auf zwei Felder verteilt. Sie schicken dann z. B. eine ungültige Email-Adresse ab. Das W3C empfiehlt deshalb, in Formularen jeweils eine Check Box vorzusehen, so dass ein Benutzer entscheiden kann, ob das Formular bereits ausgefüllt sein soll oder nicht. Die Beschriftung von Eingabefeldern muss mittels einem LABEL und einem id Tag erfolgen, damit die Beschriftung einem Formularelement zugeordnet werden kann. Nachfolgend ein Beispiel für die Codierung: <label for="vorname">ihr Vorname:</label> <input type=text id="vorname"> Es ist geplant, in kurzer Zeit einen Formulareditor in Webcom zu integrieren, der es Ermöglicht, barrierefreie Formulare per Mausklick zu bauen und in Artikelseiten zu integrieren. 8. Richtlinien für die Verwendung verschiedener HTML-Tags Alle Werte von Attributen unterschiedlicher HTML-Tags müssen in Anführungszeichen gesetzt werden. z. B. Ausrichtung innerhalb einer Tabellenzelle <td align= center > Der HTML-Tag <FONT>, welche Angaben zur Schriftgestaltung einleitet, darf nicht verwendet werden. Die grundlegende Formatierung der Schrift erfolgt für die einzelnen HTML-Tags im Cascading Style Sheet (CSS) vom Web Design. Zur Untergliederung von Texten werden Überschriften und Zwischenüberschriften verwendet. Diese sollten mit den HTML-Tags<H1></H1>, <H2></H2>,<H3></H3> etc. umschlossen werden. Die unterschiedliche Darstellung der <H> Tags wird im Cascading Style Sheet (CSS) vom Web Design geregelt. Im Allgemeinen sollten die Webcom-eigenen Überschriften, die Fett und Kursiv- Markierungen, sowie die Styles des Seitenlayouts zur Formatierung ausreichen. Tun sie dies nicht, sind diese Richtlinien zu beachten. Seite 7
9. Die Bedeutung der Style-Sheets (CSS) Die sinnvollste Methode, auf die Anforderungen bezüglich Barrierefreiheit zu reagieren ist die Verwendung von Style-Sheets. Dort definierte Schriftfarben, Schriftformatierungen, grundsätzliche Formatierungen von Links, Standardtexten, Überschriften, Tabellen, Listen, etc. harmonieren mit dem Seitenlayout, lassen sich schnell ändern und gelten immer für die ganze Site. Eine so angelegte Site lässt sich schnell an die Bedürfnisse in Punkto Barrierefreiheit anpassen. Werden Attribute, die im allgemeinen dem Layout dienen, wie zum Beispiel Breite, Höhe, Ausrichtung, Hintergrundfarben, Randeinstellungen, etc. in Styles ausgelagert, anstelle sie zum Beispiel direkt in einer Tabelle zu definieren, kann ein solches HTML-Element direkt und funktionsfähig auch in einem Text-Browser angezeigt werden. Sehbehinderte, benutzen zum Beispiel gerne den Textbrowser Lynx in Verbindung mit einer Braille-Zeile. Styles verhelfen hierbei dazu, dass auch Grafikversion der Website in einem Textbrowser lauffähig ist. Wenn beim Seitenlayout, zugunsten von gestylten DIV s und SPAN s, auf die Verwendung von Tabellen, Dummybildern und sonstigen Tricks zu Layoutzwecken verzichtet wird, erhält man als Ergebnis eine schnelle und browserkompatible Website. Nebenbei ist so auch nicht mehr weit zu einer Textversion der Website. Seite 8