Barrierefreie Website
Nicht ausklammern!
Accessibility vs. Betriebswirtschaft
Barrierefreie Website
Die Zugänglichkeit einer Website ist für Behörden Pflicht, für alle anderen Kür. Hinter Accessibility steckt eine Vielzahl an Regeln, die man beachten kann oder muss, um dadurch höhere Zugänglichkeit zu erreichen. Nicht unterschätzen sollten Sie den Aufwand, der dahinter steckt. Die Regeln müssen überprüft und umgesetzt werden. Im Hinterkopf präsent ist dabei eine relativ kleine Zielgruppe, die die entsprechenden Maßnahmen wirklich benötigt.
So weit die gängige Interpretation von Barrierefreiheit. Sieht man es realistisch, ist damit Accessibility für viele Unternehmen erledigt, die den notwendigen Mehraufwand scheuen. Aus betriebswirtschaftlicher Sicht ist das verständlich: Die Zielgruppe vieler Maßnahmen kann kleiner sein als die mancher Browser, die man damit ignoriert. Und flächendeckend umgesetzt wird Accessibility-konformes Layout hauptsächlich von staatlichen Behörden, die mittlerweile per Verordnung dazu gezwungen sind. Die Grundlage dieses Zwangs ist das Gesetz zur Gleichstellung behinderter Menschen (bundesrecht. juris.de/bgg). Und liest man noch nicht die behördliche Verordnung, sondern nur einmal Paragraf 1 dieses Gesetzes, kann aus einer lästigen Aufgabe eine moralische Verpflichtung werden. Dort steht: »Ziel dieses Gesetzes ist es, die Benachteiligung von behinderten Menschen zu beseitigen und zu verhindern?«.
Hebt die moralische Verpflichtung also die betriebswirtschaftliche Realität auf? Nein, Accessibility-konformes Design hat noch eine Reihe anderer positiver Eigenschaften: Meist verbessert sich schon durch das Nachdenken über Accessibility auch die Nutzbarkeit ? die Usability einer Website, die allen Besuchern zugute kommt. Außerdem bilden einige Regeln zur Accessibility sehr gut die aktuellen Webdesign-Trends hin zu CSS und weg von reinem HTML ab.
Dieser Artikel beleuchtet, welche Regeln Accessibility zu Grunde liegen, wie sinnvoll diese Regeln sind und wie Sie sie einhalten können, ohne andere Ziele wie ein überzeugendes Design aufgeben zu müssen. Anhand eines Beispiels werden dabei einige Grenzbereiche des Accessibility-konformen Webdesigns ausgelotet.
Regelwut
Barrierefreie Website
Accessibility-Regelungsansätze gibt es einige. In den USA heißt die offizielle Verordnung beispielsweise Section 508. Hier zu Lande und auch international hat sich mittlerweile das W3C mit seinen Accessibility-Regeln durchgesetzt. Die zugehörige Arbeitsgruppe heißt WAI ? Web Accessibility Initiative (www.w3.org/WAI). Sie hat unter dem Namen WCAG ? Web Content Accessibility Guidelines ? Regeln veröffentlicht und bietet zusätzlich Regelungsansätze für Browser (UAAG ? User Agent Accessibility Guidelines) und Entwicklungs-Tools (ATAG ? Authoring Tool Accessibility Guidelines). Die WCAG gibt es in zwei Versionen: Nur die erste hat bereits den Status einer W3C-Recommendation, also eines verabschiedeten Standards (www.w3.org/TR/WCAG10). Die zweite ist schon seit einiger Zeit ein Working Draft und ist in weiten Teilen ausgesprochen umstritten (www.alistapart.com/articles/saveaccessibility).
Die deutsche Verordnung für Behörden ? die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz oder kurz BITV ? basiert auf den WCAG in Version 1.0. Auf der offiziellen Website sind die WCAG-Regeln ins Deutsche übersetzt (www.einfach-fuer-alle.de/artikel/bitv). Insgesamt handelt es sich um 14 Regeln, die wiederum in drei Prioritätsstufen unterteilt sind. Das WCAG in Version 2.0 wird dann mit weniger, dafür aber tiefer unterteilten Regeln auskommen.
Layout-Realitäten
Barrierefreie Website
Die erste Überlegung bei der Umsetzung eines Webdesigns gilt dem grundlegenden Layout. Mit der Forderung nach Accessibility bekommt diese Entscheidung eine neue Qualität: Prinzipiell gilt die Meinung, dass ein CSS-Layout dem Tabellenlayout vorzuziehen ist. Was dies in der Umsetzung erfordert, weiß jeder, der sich bereits an einem browserübergreifend funktionierenden CSS-Layout versucht hat. Allerdings steht die CSS-Layout-Forderung gar nicht explizit als Priorität eins in der Richtlinie. Zuständig dafür ist die fünfte Regel, in der sich alles um korrektes Markup für Tabellen dreht. In Priorität eins steht dort nur, dass th-Tags korrekt eingesetzt werden sollen und Tabellen mit thead und tfoot gegliedert werden sollen. Bei diesen Regeln geht es darum, dass der Inhalt korrekt und logisch strukturiert ist, damit der Inhalt erfasst werden kann, ohne das Rendering-Ergebnis im Browser zu sehen.
Priorität zwei von Regel 5 wendet sich dann allerdings schon ein wenig gegen Tabellenlayout: Es soll nicht eingesetzt werden, wenn es linearisiert nicht sinnvoll erfassbar ist. Linearisiert bedeutet, dem normalen HTML-Fluss folgend. Damit ist gemeint, dass der Quellcode einer Website in einem normalen Lesefluss sinnvoll interpretierbar sein sollte und der Quellcode-Fluss nicht vom Layout-Ergebnis im Browser abweichen darf. Auch hier ist der Sinn wichtig: Man möchte damit eine klare Struktur finden, die auch ohne normalen Browser lesbar ist. Prinzipiell ist dies alles mit Layout-Tabellen denkbar ? und dennoch greift man heute für Accessibility-konforme Programmierung meist zu CSS. Denn auch wenn eine Tabelle linearisiert interpretiert werden kann, ist sie ein Dickicht an Konstrukten, während selbst verschachtelte div-Elemente recht einfach zu durchschauen sind. CSS-Layouts entlasten außerdem den HTML-Quellcode, bieten also Screenreadern und ähnlichen Werkzeugen deutlich weniger zu tun. Und zu guter Letzt lässt sich das Layout recht flexibel wechseln oder ändern.
Umsetzung: Beispielwebsite
Barrierefreie Website
Um das zu untermauern, entsteht in diesem Artikel ein einfaches CSS-Layout für eine Website über das Thema selbst: Accessibility und Usability. Ausgangspunkt ist ein in Adobe Illustrator und Photoshop entstandenes Layout. Dieser Weg ist für Tabellenlayouts sehr normal, weil sich Tabellen sehr einfach gedanklich wie ein Raster über ein Layout legen lassen und die Umsetzung so einfacher ist, als wenn gleich drauflosprogrammiert würde. Bei CSS-Layouts ist das genau gegensätzlich. Hier ist die Umsetzung eines Layouts nicht so plastisch vorstellbar, und vielen Webdesignern fehlt verständlicherweise auch die Erfahrung. Dennoch geht dieser Artikel den Weg vom Layout zur Umsetzung, da nur so nicht schablonenartig immer gleiche Lösungen aufgesetzt werden und das Design noch nicht von Anfang an von der Layout-Realität eingeengt ist.
Das vorliegende Layout besteht aus einem Kopfbereich mit einer Pfad-Navigation (Breadcrumb) und der Hauptnavigation unter einem grünen Balken. Auf der linken Seite folgt die Unternavigation und daneben drei Spalten mit jeweils einem Kasten. Da die Hauptnavigation mit einer besonderen Schrift versehen sein soll, müssen ihre Texte als Grafiken eingebunden werden. Um die negativen Effekte auf Accessibility und Suchmaschinenoptimierung einzudämmen, wird eine zweite verkleinerte Version der Hauptnavigation im Fuß der Seite angefügt. Aus diesen Bestandteilen ergibt sich der grundlegende HTML-Code mit den einzelnen Blöcken.
Grafische Navigation
Barrierefreie Website
Die Blöcke folgen einer logischen Reihenfolge, die auch genau so gelesen werden kann. Einziger Kompromiss ist wie erwähnt die Hauptnavigation, die aus Grafiken besteht. Aus Accessibility-Gesichtspunkten können Sie natürlich mit Alternativtext und Titel für Link und Grafiken die nöti
gen Informationen liefern. Auch eine sprechende Link-Quelle hilft hier:
Trotzdem werden Anhänger der reinen CSS-Lehre sagen, dass Navigationsleisten als Grafiken nicht gehen. Mit Fug und Recht entgegnet der Design-Gläubige dann, dass ohne ein wenig Individualismus und eine eigene optische Welt alle Webseiten gleich aussehen und die Arial/Verdana-Konstrukte der erste Weg zur Gleichschaltung aller Websites sind. Letzteres ist übrigens eine These, die ein Blick auf verschiedene Websites staatlicher Institutionen durchaus unterstützt. Zwar spricht nichts gegen ein wenig Governance Identity, aber bei der Frage, bei welchem Amt sich der Nutzer gerade befindet, ist er rein optisch doch schnell verloren.
Flexibilität
Barrierefreie Website
Neben der Schriftfrage ist die Flexibilität ein weiterer Diskussionspunkt. Die WCAG-Spezifikation sieht keine eindeutige Aussage zu flexiblem oder fixem Layout vor. Sogar Frames sind erlaubt, wenn sie nur klar genug beschriftet sind (Regel 12). Wird man auf Frames noch freiwillig und aus anderen Gründen wie Bookmarks und Suchmaschinendiskussionen verzichten, bleibt die Frage nach dem flexiblen Layout. Mit CSS-Layout bietet sich die Flexibilisierung durchaus an, weil man damit einer sehr großen Zielgruppe, den Menschen mit leichten Sehschwächen, erlaubt, die Website nach eigenem Gutdünken zu skalieren. Basis des ganzen sind flexible Schriftgrößen mit em oder Prozentangaben. Aber auch das Layout muss sich anpassen.
Im vorliegenden Beispiel sind der Kopf und die Hauptnavigation absolut positioniert und reichen über die ganze Breite. Bei der Hauptnavigation besteht die Flexibilität darin, dass die Navigationspunkte bei sehr kleinen Auflösungen auf die nächste Zeile rutschen. Die Alternative wäre gewesen, sie als Blockelemente mit float in Reih und Glied anzuordnen.
Am schwierigsten ist die Flexibilität für die einzelnen Spalten, denn die Navigationsleiste soll fix bleiben. Dafür erhält die Navigationsleiste links eine feste Breite von 150 Pixeln:
#navigation {
position: absolute;
left: 0px;
top: 0px;
margin-top: 100px;
z-index: 2;
width: 150px;
height: 70%;
border: none;
}
Damit die Spalten mit dem Inhalt flexibel sind, erhalten sie eine Breite in Prozent:
#spalte1 {
position: absolute;
left: 0px;
top: 150px;
width: 50%;
background-color: white;
border: none
}
Da die Spalte damit auch über die Navigation lappt, wird der Kasten mit margin-left um 150 Pixel eingerückt. Er beginnt also erst direkt an der Navigationsleiste.
#spalte1_kasten1 {
border: 1px solid #666666;
padding: 10px;
margin-left: 150px;
margin-right: 10px;
}
Wie immer ist dies nur einer von mehreren möglichen Tricks. Alternativ kommt für CSS-Layouts auch oft die Flusssteuerung mit float zum Einsatz. Bei der Mischung zwischen fixer Navigationsleiste und flexiblem Inhalt ist die hier gezeigte Variante aber ein wenig praktischer.
Informationen
Barrierefreie Website
Bei der Schriftgröße hat sich heute em als Maßeinheit für flexible und Accessibility-konforme Layouts durchgesetzt. Pixel und Punkt sind als absolute Angaben im Internet Explorer leider nicht größenskalierbar. Die Frage ist, wie Sie mit den Größen von Bildern verfahren. Zwar sagen die offiziellen Regeln nichts darüber, aber bei Bildern im Inhalt kann ein flexibles Mitskalieren doch durchaus sinnvoll sein. Dies erreichen Sie, indem Sie Bilder mit em oder % als Maßeinheit versehen. In der Beispiel-Site finden Sie das an zwei Stellen: Die Hauptnavigationspunkte sind in em bestimmt. Das Problem liegt allerdings auf der Hand: Die Berechnungen sind nur näherungsweise, weil ein em im Browser normalerweise 12 Punkt entspricht und diese Einheit in Pixel umgerechnet werden muss, die Größe eines Pixels aber auf verschiedenen Systemen variiert. Ungefähre Umrechnungsangaben finden Sie unter www.reeddesign.co.uk/test/points-pixels.html. Dem liegt zu Grunde, dass einem em ungefähr 16 Pixel entsprechen. Das zweite Problem ist ebenso offensichtlich: Skalierte Bitmap-Bilder sehen sehr schnell hässlich aus, da der Browser die Skalierung übernehmen muss und recht plump ein paar Pixel hinzurechnet. Eine Bildbearbeitung beherrscht diese Aufgabe einfach deutlich besser.
Alternativ zu em können Sie für Bilder auch Prozentwerte einsetzen. Die Beispiel-Site zeigt dies anhand eines Bildes in einer Spalte. Das Bild passt sich hier in der Breite an die Breite der Spalte an:
Wenn Sie für die Höhe ebenfalls 100% verwenden, offenbart der Safari-Browser einen Bug und stellt das Bild verzerrt dar. Deswegen kommt hier der Wert auto zum Einsatz.
Mehr Regeln
Barrierefreie Website
Bisher fällt auf, dass viele Probleme und viel heiß Diskutiertes wie beispielsweise die flexiblen Schriftgrößen in den offiziellen Accessibility-Regeln gar nicht so exakt definiert sind. Aber welche Regeln machen bei diesem Beispiel eigentlich noch Probleme? Die Empfehlungen zum korrekten Einsatz von Markup und Stylesheets (Regel 3), zum Einsatz von W3C-Techniken (Regel 11) und zu klaren und verständlichen Dokumenten (Regel 14) sind problemlos zu erfüllen und teils so schwammig wie wirkungslos. Klare Navigation (Regel 13) und Orientierungshilfen (Regel 11) liefert die Website über das Navigationskonzept an sich.
Interessant wird es bei der Browser-Kompatibilität und Unabhängigkeit von neuen Technologien (Regel 10). Da das HTML-Dokument logisch strukturiert ist, sieht die Webseite auch ohne CSS hinreichend übersichtlich aus.
Regel 2 ist sogar Inhalt der hier gestalteten Beispielseite. Und zwar geht es dort um Farbkontraste. Besonders betroffen von solchen Problemen sind Menschen mit Farbenblindheit. Die häufigsten Schwächen sind verschiedene Ausprägungen von Rotgrünblindheit. Ein Test des Beispielbildes unter www.vischeck.com zeigt, dass der Unterschied zwischen der roten und der grünen Büroklammer kaum zu erkennen ist. Das heißt natürlich nicht, dass Sie solche Bilder komplett vermeiden sollten. Die Bilder sollten nur keine entscheidende Bedeutung haben. Beispielsweise sind Ampelfarben zum alleinigen Auszeichnen von Verfügbarkeiten nicht sinnvoll.
Fazit
Barrierefreie Website
Das hier gezeigte Beispiel soll nicht alle Regeln und Checkpunkte illustrieren. Viele wichtige Themen wie Accessibility und Multimedia wie Flash und Video sind hier nicht zu Wort gekommen. Außerdem wurde auf Browserhacks verzichtet ? ein Thema, über das heftig gestritten werden kann. Und noch etwas soll dieses Beispiel nicht sein: ein Plädoyer für eine ganz bestimmte Accessibility- und Regelauslegung. So normativ, wie es scheint, sind nämlich weder das Regularium noch die Meinungen der vielen streitbaren Webdesign-Geister.