- Design Grundkonzept
- Liquid Design oder fixed Pixel?
- Relative Größenangaben
- Farben und Kontraste
- Alternative Darstellungsformen
- Auch ohne Farben nutzbar
- Textalternativen bereitstellen
- Tastaturbedienung
- Accesskeys und Navigationsnummerierung
- Verbesserungen in TYPO3-Version 4
- Bedienbarkeit ohne JavaScript
- Redaktion
- Test und Qualitätssicherung
- Fazit
Barrierefreie TYPO3-Umsetzung am Beispiel der Chronologie des Holocaust: Keine Mogelpackung
„Echte“ Barrierefreiheit ist akribische Kleinstarbeit, die mit konzeptionellen Überlegungen beginnt und später in umfangreicher Schulung und konsequenter Arbeit des Redakteurs ihre Fortsetzung findet. Für die technische Umsetzung ist fundiertes Wissen über Rahmenbedingungen und moderne Webtechnik erforderlich. Accessibility wird nicht out-of-the-box geliefert, auch wenn TYPO3 seit Version 4.0 mit erheblichen Erleichterungen gegenüber seinen Vorgängern aufwartet.
Design Grundkonzept
Gerade außergewöhnliches Design ist manchmal schwer mit den Grundsätzen barrierefreier Webgestaltung vereinbar. Oft ist das Ergebnis ein „labiles“ Grundgerüst, das nur mit einer Vielzahl von Browserhacks browserübergreifend konsistent dargestellt wird. Schon das Grundkonzept sollte daher in enger Zusammenarbeit zwischen Designer und Entwickler erarbeitet werden.
Die „Chronologie des Holocaust“, eine Arbeit des Historikers und
Journalisten Knut Mellenthin, ist in Art und Umfang
einzigartig. Die Website bietet ein umfangreiches Datengerüst und
sehr viel Quellenmaterial, aus dem die Zusammenhänge und die Denkweise
der Hauptverantwortlichen für den Völkermord an den Juden deutlich
werden.
Die grafische Gestaltung der ursprünglich als Nur-Text-Version in Buchform gedachten Chronologie geriet zur Herausforderung. Das Thema eignet sich naturgemäß nicht für auflockernde Gestaltungselemente im üblichen Sinne. Andererseits benötigen Text und Fakten aber ohnehin keine Visualisierung, das Grauen spricht für sich. Daher sind diese Elemente sparsamst verwendet worden: Stacheldraht als Symbol der Barbarei, dazu der jüdische Grabstein auf der Startseite als Mahnmal und Ehre für die Opfer. Zur Begrenzung des Contents zur rechten Seite Auszüge aus dem Tagebuch der Anne Frank.
Liquid Design oder fixed Pixel?
Für die Chronologie wurde ein „Liquid Design“ entwickelt, damit beim Verändern des Browserfensters die Grafikelemente zueinander stabil bleiben – die äußeren Spalten und deren eingebettete Grafiken verschieben sich dabei nach außen.
Auch bei barrierefreien Umsetzungen haben sich in letzter Zeit feste Layout-Breiten etabliert, wenn auch mit relativen Breitenangaben. So betrifft eine Vergrößerung aber nicht nur die Schrift, sondern das gesamte Layout – lästiges Querscrollen ist die Folge. Echtes Liquid Design passt sich hingegen der jeweiligen Bildschirmbreite an. Das sichert ein bedienbares und übersichtliches Layout für unterschiedlichste Auflösungen.
Um die Zeilenbreite lesbar zu halten, wurden die Containerbreiten der Chronologie-Elemente vollständig relativ zur Bildschirmbreite angelegt – das CSS-Layout passt somit auch bei einer Fensterbreite von nur 610 Pixel ins Display.
Relative Größenangaben
Da der IE als meistgenutzter Browser keine in Pixel definierten Schriftgrößen skaliert, sind relative Angaben für Typo-Größe, Zeilenhöhe und andere schriftgrößenabhängige Attribute eine Selbstverständlichkeit. Das klingt banal, birgt aber einige Stolpersteine. So sind umfangreiche Tests und anschließende CSS-Korrekturen dringend angeraten, denn auch bei kleineren Auflösungen muss schließlich die Schrift vergrößert werden können, ohne dass Texte überlappen, Navigationsbegriffe abgeschnitten werden oder die Website unbenutzbar wird.
Farben und Kontraste
Um Farbfehlsichtigkeit auszugleichen, sollten Vorder- und Hintergrundfarbe inhaltsvermittelnder Grafiken und Texte entsprechenden Kontrast aufweisen oder vom Benutzer individuell festgelegt werden können. Vor allem bei grafischen Bedienelementen und informativen Grafiken kann dies leicht zur Barriere werden. Farbwertanalysen sind unerlässlich, verschiedene Online-Tools leisten dabei eine große Hilfe.
Alternative Darstellungsformen
Das Anbieten alternativer Darstellungsformen eines Webangebots ist laut WCAG- oder BITV-Richtlinien nicht zwingend erforderlich. In der Regel reichen jedoch die Kenntnisse des betroffenen Anwenders nicht aus, die Stylesheets seinen Bedürfnissen entsprechend individuell anzupassen. Deshalb tragen Darstellungsoptionen innerhalb der Anwendung grundsätzlich zu einer Verbesserung der Accessibility bei, auch wenn einige Browser diese Features bereits integriert haben.
Bei der Chronologie erlaubt eine permanent sichtbare, zentral angeordnete Accessibility-Navigation die problemlose Schriftgrößeneinstellung und die Auswahl von Kontrasten oder einer Druckansicht.
Wie in allen anderen Navigationen des Projekts ist auch hier der aktive Status nicht allein durch die grafische Formatierung der Links erkennbar. Ohne CSS-Formatierung wird die Accessibility-Navigation folgendermaßen ausgegeben:
Für die technische Implementierung der Accessibility-Navigation wurde eine Lösung gefunden, die sich grundlegend von den üblichen auf JavaScript basierten Styleswitchern unterscheidet: Ein dynamisch in TYPO3 generiertes Stylesheet steuert dabei die CSS-Definitionen der Größenangaben und die Anzeige der Hintergrundbilder und Farben.
Auch ohne Farben nutzbar
Laut WAI-Richtlinie 2 bzw. BITV-Anforderung 2 [1] müssen Webangebote auch ohne Farben nutzbar sein. Daher ist eine eindeutige Kennzeichnung von aktiven Menüpunkten und ihrer Position in der Dokumenthierarchie erforderlich.
Die Kennzeichnung der aktiven Menüpunkte der Chronologie erfolgt durch Rahmen und Kästen. Alle Layoutgrafiken wurden als Hintergrundbilder eingesetzt, um bei abgeschalteten Farben maximalen Kontrast und eine Reduktion auf die wesentlichen Bedienelemente zu erreichen.
Textalternativen bereitstellen
Für alle inhaltsvermittelnden Grafiken und Bilder müssen Alternativtexte (alt-Attribut) bereitgestellt werden.
Jede Navigationsleiste der Chronologie wurde mit einer Überschrift versehen, das Logo wurde auch als Text bereitgestellt. Diese alternativen Beschriftungen werden im CSS-Layout ausgeblendet und nur bei deaktivierten Stylesheets angezeigt bzw. von Screenreadern vorgelesen. Dazu dient eine CSS-Klasse mit dem Namen „.inv“.
Tastaturbedienung
Um die Navigation auch ohne Maus bedienen zu können, muss unbedingt die CSS-Pseudoklasse a:focus definiert werden, damit beim Anspringen der einzelnen Links per Tastatur der aktive bzw. hervorgehobene Menüpunkt eindeutig erkennbar ist.
Ein zusätzliches Feature sind Sprungmarken am Beginn jedes Dokuments, die ein Überspringen der einzelnen Navigationen per Tastatur ermöglichen. Mit CSS unsichtbar gesetzte Sprungmarken weisen hier einen entscheidenden Nachteil auf: Einige Browser sind nicht in der Lage, diese beim Anspringen mit der Tastatur per a:focus wieder auf sichtbar zu setzen. Es ist daher sinnvoll, ständig sichtbare Sprunglinks anzubieten, denn wenn jemand die Website per Tastatur bedient, bedeutet dies nicht zwingend, dass er auch einen Screenreader benutzt!
Bei der Chronologie wurden diese Sprunglinks deshalb nicht mit der Klasse „inv“ unsichtbar gestellt, stattdessen wurden Vorder- und Hintergrundfarbe auf weiß gesetzt. Somit ist ein Einblenden und Anspringen dieser Links auch bei vollständig geladenem Design möglich. Wichtig: In bestimmten Rubriken nicht vorhandene Navigationen dürfen keinen Sprunglink erzeugen – es werden immer nur Sprunglinks für Navigationen ausgegeben, die auch angezeigt werden.
Am Nutzen von Accesskeys und hierarchischer Nummerierung der Navigationsleisten scheiden sich die Geister.
Accesskeys werden oft durch in den Browsern vordefinierte Kurzbefehle überlagert. Außerdem ist zu bezweifeln, dass Benutzer sich vor dem Besuch einer Website mit einer Reihe von Kurzbefehlen auseinandersetzen möchten. Sinn können Accesskeys machen, wenn in oft genutzten Webapplikationen ständig wiederkehrende Aktionen dadurch beschleunigt aufgerufen werden können.
Die Nummerierung der Navigation per <dfn>-Tags wird häufig für verschachtelte Navigationsleisten eingesetzt und erleichtert die Orientierung in der Dokumenthierarchie. Werden jedoch mehrere Navigationen angeboten, kann diese Definition kontraproduktiv sein, zumal verschachtelte Navigationsleisten nicht immer als die übersichtlichste Darstellungsform angesehen werden.
Unbestritten ist eine logisch nachvollziehbare Tabulator-Reihenfolge für Tastatur-Benutzer äußerst wichtig. Wird die Navigation allerdings bereits im Quelltext logisch und linear aufgebaut, erübrigt sich das Festlegen der Tabulator-Reihenfolge.
Auf den Einsatz von Accesskeys wurde im Beispiel-Projekt bewusst verzichtet. Stattdessen wurde im Quellcode eine optimal linearisierte logische und nachvollziehbare Reihenfolge der Links zum Anspringen mit der Tastatur festgelegt und eine Meta-Navigation bereitgestellt. Über im Seitenheader vorhandene <link>-Tags können Browser, die diese Auszeichnung unterstützen, auf wichtige Seiten der Website sofort zugreifen. Startseite, Glossar, Suchfunktion, Sitemap, Impressum, Kontakt sowie die Blättern-Funktionen der Chronologie-Vollversion können über <link>-Tag direkt angesteuert werden.
Die Navigation für die gesamte Site wurde auf mehrere Navigationsleisten aufgeteilt. Die Links zu den gerade aktiven Rubriken und Seiten sind inaktiv und mit einer entsprechenden Kennzeichnung („Aktive Rubrik“, „Aktueller Zeitraum“, „Aktuelle Position“ etc.) versehen. Die üblichen Links in der Fußzeile wurden auf den Seiten der Chronologie-Vollversion um Blättern-Links erweitert, die ein seitenweises Vor- und Zurückblättern der Chronologie ermöglichen. Die mit „nächster Monat“ oder „weiterblättern“ bezeichneten Links wurden zusätzlich per title-Tag mit dem eindeutigen Datum, auf das verlinkt wird, gekennzeichnet.
Verbesserungen in TYPO3-Version 4
In TYPO3-Version 4 und einigen grundlegenden Extensions ist mittlerweile vieles vorbereitet, um barrierefreie Websites einfacher erstellen zu können. Die Extension css_styled_content ist inzwischen ausgereift und tabellenlose Layouts sind auch mit dem „Text mit Bild“-Inhaltsmodul möglich. Tabellenauszeichnungen wurden um Accessibility-Features erweitert, Sitemaps sind korrekt über Listen ausgezeichnet, für Bilder und Grafiken können die alt- und title-Attribute gefüllt werden und eine valide HTML-Ausgabe ist problemlos möglich.
Bedienbarkeit ohne JavaScript
Scripts und Applets sind für assistive Technologien zugänglich zu gestalten. Laut WAI-Richtlinie 6 müssen Seiten auch funktionieren, wenn zum Beispiel JavaScript im Browser deaktiviert ist. Die oft implementierten Styleswitcher auf JavaScript-Basis sind demnach ein Grenzfall, ebenso ist die Erweiterung indexed_search nur eingeschränkt zugänglich, da die Blättern-Funktion durch die Ergebnis-Seiten derzeit per JavaScript realisiert ist. Ein alternativer Zugang zu allen Ergebnisseiten muss daher berücksichtigt werden.
Um die mächtige indexed_search nutzen zu können, wurde im Projekt eine zugängliche Lösung realisiert. Das Array für die Einschränkung der Ergebnisseiten wurde erweitert, um alternativ „alle“ Ergebnisse ausgeben zu können. Außerdem musste das Suchformular angepasst werden, da die Ausgabe standardmäßig noch nicht XHTML-Strict-konform ist.
Redaktion
Barrierefreies Internet endet weder bei der Implementierung eines CMS noch mit valider HTML-Ausgabe. Zitate müssen in HTML mit <blockquote>- oder <q>-Tags, Sprachwechsel mit <span lang=““>, Quellenangaben mit <cite> ausgezeichnet werden, und eine valide Ausgabe jeder eingepflegten Seite ist zu gewährleisten. Die Vergabe von Alternativtexten zu Bildern ist eine Selbstverständlichkeit, Tabellen müssen ausgezeichnet und Linkziele treffend und zuverlässig angegeben werden.
Nicht zuletzt ist auf eine klare, für die Zielgruppe verständliche Sprache und auf einen einheitlichen Präsentationsstil zu achten.
Die Redaktion muss daher entsprechend geschult werden, die Auszeichnungen müssen über den Rich Text Editor so einfach und unkompliziert wie möglich sein.
Die Chronologie besteht aus tausenden Einzeltexten und einer Vielzahl von Zitaten, Quellenangaben, Abkürzungen und Akronymen. Das gesamte Backend und der Rich Text Editor wurden daher entsprechend „abgespeckt“, um Fehlerquellen zu vermeiden. Benutzerdefinierte Funktionen zur Kennzeichnung von Zitaten und Quellennachweisen wurden den Redakteuren zur Verfügung gestellt. Die Extension „Page Validator“ (sf_validator) unterstützt die Redaktion bei der Einhaltung der Validität. Die Extension „Accessibility Glossary“ (a21glossary) wurde für das Glossar sowie für die Kennzeichnung von Akronymen, Abkürzungen und fremdsprachigen Begriffen eingesetzt.
Für das inhaltliche Verständnis wird neben der Vollversion eine Übersicht in zwei unterschiedlich gekürzten Fassungen zur schnellen Orientierung oder als erster Einstieg angeboten. Der Bereich „Artikel“ wurde mit Teasertexten versehen und die Verlinkung der „Zum Artikel“-Links eindeutig gekennzeichnet. Zum Teil in den Fließtexten verlinkte Glossarbegriffe und eine vollständige Sitemap tragen inhaltlich zum Abbau von Barrieren bei.
Test und Qualitätssicherung
Einen wesentlichen Zeit- und Kostenfaktor bei barrierefreien Projekten stellen Tests und die Qualitätssicherung zur Einhaltung der BITV/WAI-Richtlinien dar. Erfahrung und Kenntnisse der Richtlinien seitens der umsetzenden Agentur sind dabei unabdingbar, es gibt jedoch einige Tools, die beim Auffinden von Barrieren behilflich sein können:
Total Validator [2] : Das Online-Tool prüft nicht nur auf verschiedene Doctypes und die Accessibility-Stufen A, AA, AAA und Section 508, sondern ist auch in der Lage, Screenshots in einer Vielzahl von Browsern und Auflösungen anzufertigen.
Site Valet [3] : Die Stärke dieses Tools sind konkrete Hinweise direkt in den Quelltexten.
Truwex Online 2.0 beta [4] : Dieses Tool bietet umfangreiche Reports zu allen wichtigen Richtlinien, aber vor allem eine grafische Ausgabe der Website mit Angabe von problematischen Farbdefinitionen und anderen Interface-relevanten Accessibility-Hürden.
Colorblind Web Page Filter [5] : Das Tool zeigt die eingegebene URL in verschiedenen Farbschemata, die Farb-Fehlsichtigkeiten simulieren. Dadurch werden problematische Farbkombinationen abgekoppelt von reinen Helligkeits- und Kontrastprüfungen erkannt.
Mit dem Color Contrast Analyser [6] können schließlich Helligkeit und Farbkontrast überprüft werden – je nach Richtlinie sind dafür Mindeststandards definiert.
Neben diesen Online-Tools leisten die in Opera integrierten Funktionen des „Benutzermodus“ sowie die Developer Toolbar Extension in Firefox [7] wichtige Dienste. So kann beispielsweise mit „Disable Page Colors“ in der Firefox Developer Toolbar überprüft werden, ob Informationen lediglich über die Farbe vermittelt werden oder es können direkt Validitätstests für HTML, CSS und WAI oder die US-Amerikanische Section 508 vorgenommen werden.
Nicht zuletzt stellen die obligatorischen Browsertests auf verschiedenen Plattformen (Windows, Mac OS, Linux) einen wichtigen Bestandteil des Qualitätsprozesses dar.
Fazit
Durch die Verbesserungen ab TYPO3 4.0 können bereits viele grundlegende Barrieren einfach vermieden werden. Gute barrierefreie Internetseiten leisten jedoch noch wesentlich mehr – ein valides CSS-Layout stellt dabei bestenfalls die Grundlage für eine hohe Accessibility dar. Der gesamte Prozess von der Design-Idee bis zur Einpflege des Contents muss einem umfassenden Qualitätsprozess unterzogen werden, denn nur durch das entsprechende Know-how kann die „Mogelpackung Barrierefreiheit“ verhindert werden.