Was heisst das nun konkret für den XHTML Markup bzw. die Programmierung einer barrierefreien Homepage?

• 1. Graphiken und Bilder für barrierefreies Webdesign
  • Jedes Bild sollte im möglichst kleinsten Format gespeichert werden. Maximal sollten 60 bis 120 Kilobyte pro Seite einer Homepage Bilder sein.
  • Für Graphiken benutzt man nach XHTML 1.0 das <img> Tag
  • Das alt Attribute muss eine kurze Beschreibung enthalten, was auf dem Bild zu sehen ist
  • Das optionale longdesc Attribut enthält eine lange und ausführliche Beschreibung des Bildes oder einen Link zu einer Datei mit der Beschreibung
  • Das title Attribut enthält eine ganz kurze Informationen zur Funktion des Bildes, einen sprechenden Titel eben
  • Die Attribute width und height enthalten die Maße des Bildes in Pixel
  • Beispiel: <img src=”bild-barrierefreies-webdesign.png” alt=”Blauer Schriftzug barrierefreies Webdesign” title=”Werbebanner barrierefreies Webdesign” widht=”250″ height=”50″ />
• 2. Links für barrierefreies Webdesign
  • Links auf Phrasen wie “hier klicken” oder “hier” oder “weiteres” vermeiden
  • Der Text, um den ein Link gelegt ist sollte zudem noch aussagekräftig sein
  • Das title Attribut beschreibt kurz was die gelinkte Seite bietet
  • Links sollten sich einheitlich vom Rest der Seite farblich oder durch Textformatierungen abheben
  • Es wir zusätzlich dringend empfohlen Links zu unterstreichen
  • Links besitzen kein _target Attribut, ein Besucher der Homepage will selber entscheiden (klick durch mittlere Maustaste, Mausrad) ob sich ein neues Fenster öffnet oder nicht
  • Beispiel: Im Internet findet man viele <a href=”barrierefreies-webdesign.html” title=”Informatione über barrierefreies Webdesign”>barrierefreie Homepages</a>
  • Mit dem link Tag im Header einer XHTML Datei, kann man außer einer CSS Datei auch hilfreiche Links angeben. Diese werden zwar von Browserm wie dem Firefox nicht dargestellt, von Screenreadern oder Textbrowsern (Lynx) verarbeitet. Diese zusätzliche Navigationshilfen können auf home, prev oder next zeigen, also auf die Startseite, die nächste und die vorherige Seite einer Homepage, Syntax: <link rel=”prev” src=”webdesign-tübingen.php”>
• 3. Navigationsmenüs für barrierefreies Webdesign
  • Dürfen Bilder enthalten
  • Müssen gut gegliedert und Aussagekräftig sein
  • Werden am besten in Listen gehalten
  • Können durch display:block und float:left oder display:inline und list-style-type:none beliebig positioniert und formatiert werden
  • Umfangreiche Homepages sollten zudem eine eigene Seite mit einer Sitemap enthalten, welche wiederum in einer Liste darstellt, welche Seiten alle in welcher Tiefe verfügbar sind
  • Subnavigationen sollten nah der Hauptavigation platziert sein, getreu dem Prinzip der kurzen Wege
  • Ebenfalls extrem Hilfreich ist eine Breadcrumb, welche Anzeigt wo ich derzeit auf der Homepage mich befinde, vorallem auf Homepages mit vielen Unterpunkten und Themenbereichen
  • Aktive Links sollten im Navigationsmenü hervorgehoben werden, damit man sieht wo man sich gerade befindet.
  • Hover Effekte etc. unbedingt mit CSS lösen, die Navigation muss ohne Javascript funktionieren
• 4. Access Keys für barrierefreies Webdesign
  • Man kann durch das Attribut accesskey einem Link einen Tastatur Short Cut zuweisen
  • Das ist aber nur bedingt sinnvoll, da 20 Shortcuts pro Seite sich sowieso niemand merken kann
  • Es gibt eine Art offenen Standard, wo man sich einfach bediehnen sollte und die relevanten Access Keys definieren – mehr nicht
• 5. Tab Index für barrierefreies Webdesign
  • durch das Attribut tabindex in Links kann man die Reihenfolge, in der Links oder auch Form Elemente, durch die Tabulator
    Taste angesprochen werden beeinflussen
  • Elemente ohne Tabindex werden einfach in der Reihenfolge wie sie im Quelltext stehen angesprochen
  • Oftmals macht es Sinn, diese “natürlich” Reihenfolge einfach beizubehalten
  • Beim Einsatz des Tabindexes sollte darauf geachtet werden, nicht Verwirrung, sondern wenn dann eine Navigationserleichterung zu schaffen
• 6. Hidden Tags und Skiplinks für barrierefreies Webdesign
  • Durch Überschriften mit dem CSS Attribut display:none kann man Struktur in eine Homepage bringen, ohne störende Überschriften wie “Navigationsbereich” oder “Header” etc. zu erzeugen
  • Es gibt auch die alternative Möglichkeit per position:absolute mit left:-1000 und overflow:hidden die Element einfach ausserhalb des Browser zu positionieren, wo sie auch nicht mehr sichtbar sind
  • Diese Elemente werden nun nur noch von Vorlesebrowsern erfasst.
  • Je nach Zielgruppe macht es aber auch Sinn, diese Elemente sichtbar zu gestalten und ins Design der Seite aufzunehmen
  • Sogenannte Skiplinks (interne Links zu Bereichen, meistens “divs” der Homepage) Helfen vorallem Blinden und Surfer mit Textbrowsern wie Lynx beim Navigieren, auch sie können durch hidden Tags für sonstige Besucher der Seite versteckt werden
  • Was eine Barrierefreie Homeapage auf jeden Fall bieten sollte, sind zwei Sichtbare Links ganz oben auf jeder Homepage, einen direkt zum Inhalt, einen direkt zum Navigationsmenü, sodass Besucher der Homepage diese per Tastatur leicht ansteuern können
• 7. Überschriften für barrierefreies Webdesign
  • Vorneweg, in den Header einer XHTML Datei gehört ein aussagekräftiges title Tag mit einem individuellen Titel für jede Seite der Homepage
  • Wichtig ist, dass jeder Bereich (div) einer Homepage eine Überschrift erhält, welche diesen Bereich beschreibt, bzw. kennzeichnet
  • Auch sollte die Reihenfolge der Überschriften Tags eingehalten werden, nach H1 kommt H2 und so weiter.
  • Jede Homepage enthält genau eine H1, diese steht an oberster Stelle und trägt den jeweiligen Titel der aktuellen Seite der Homepage, sie muss aber nicht die optisch Größte sein, sondern kann auch ganz klein oder in einer Breadcrumb realisiert werden.
  • Überschriften H1 bis H3 können für Strukturzwecke als Hidden Tags umgesetzt werden
  • Überschriften können auch durch Graphiken ersetzt werden, dazu setzt man innerhalb der H1-6 Tags ein img Tag.
    Allerdings sollte man dann noch treffendere alt Tags vergeben, da dieser Text ja die alternative Überschrift darstellt.
• 8. Schriftgröße und Styleswitch für barrierefreies Webdesign
  • Homepages mit vielen Farben oder wenig Kontrast, sollten alternativ ein Schwarz/Weiss design anbieten
  • Basierend auf einer Standardgröße des body von z.B. 10px (62,5%) sollte eine Homepage per CSS so designed werden, dass sie skalierbar ist beim Vergrößern der Schriftart.
  • Alles, was skalieren soll wird in em (bei 62,5% sind 1em gleich 10px)angegeben, was fix bleiben soll als px.
  • Dann kann man ein kleine Skript bauen, welches die Schriftgröße auf z.B. auf 100% setzt und so die Seite perfekt skalieren wird.
  • Der Firefox Browser z.B. kann auch ohne so ein Script mit den Tasten strg + + und strg + - eine Homepage skalieren
• 9. Sprache für barrierefreies Webdesign
  • In jedem Fall muss die Sprache im Quelltext angegeben werden
  • Das attribut lang nimmt Länderkurzel wie de oder en entgegen
  • Das sollte einemal im html Tag global bestimmt werden und in Tags, welche Inhalt anderer Sprache enthalten dann individuell gesetzt werden
  • Es ist eine der Zielgruppe angepasste Sprache und Sprachstil zu verwenden, eine Homepage mit technischem Know How sollte auf Fachsprache setzen, eine allgemein gehaltene Seite eher auf leicht Verständliches mit vielen Erklärungen.
• 10. Textauszeichnungen für barrierefreies Webdesign
  • Abkürzungen, welche man nicht liest wie sie dastehen, z.B. XML spricht man “ix em ell” oder z.B. für “zum Beispiel” sollten in das Tag abbr gepackt werden. Mit dem attribut title wird dann die ausgeschrieben Version präsentiert Beispiel: <abbr title=”barrierefreies Webdesign”>b.W.</abbr>
  • Acronyme sind wie Abkürzungen, haben jedoch noch einen erklärenden Charackter. z.B. <acronym title=”eXtensible Markup Language – Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien”>XML</acronym>
  • Acronyme sind den sematisch eng verwandten Abkürzungen vorzuziehen, da der Internet Explorer das abbr Tag nicht kennt
  • Quellcode kann durch das Tag code gekennzeichnet werden, dies ist standardmäßig ein inline Element
  • Zitate werden durch das block element blockquote dargestellt. für kleinere Zitete gibt es das inline element q welches als attribut cite den Autor oder einen Quellink aufnehmen kann.
    Das blockquote element kennt hingegen ein Tag cite mit selber Semantik
  • Mit dem Tag kbd kann man Tastenanschläge auszeichnen. Beispiel: drücken sie <kbd>strg</kbd> + <kbd>D</kbd>
• 11. Tabellen für barrierefreies Webdesign
  • Man darf und soll Tabellen natürlich auch für barrierefreies Webdesign benutzen, allerdings nicht zu Struckturzwecken, dafür gibt es divs
    sondern eben da, wo die Semantik eine Tabelle ergibt.
  • Jede Tabelle sollte ein Tag caption enthalten, welches die Überschrift der Tabelle darstellt
    und ein Attribut summary mit einer Beschreibung des Inhalts.
  • Der Tabellen Kopf, also die Überschriften der Spalten stehen in einem thead Bereich und wird durch th, nicht durch td repräsentiert
  • Ein tfoot Bereich enthält zum Beispiel Zellem mit Zusammenfassungen der Spalten…
  • im tbody Tag stehen die Tabellen Inhalte
  • mit dem Attribut scope beschreibt man den Bezug eines th Tags, nämlich ob es eine Überschrift einer Spalte (scope=”col”) eine Zeile (row) oder evtl einer gruppierten Zelle (colgroup, rowgroup) handelt
  • komlexe Tabellen enthalten in jedem th Tag ein id Attrinut und in den td Tags ein headers Attribute mit einer Anreihung (Leerzeichen getrennt) von zugeordneten th Tags
  • Tabbelen barrierefrei bzw. einfach mit korrekter Semantik zu gestallten ist zwar aufwendig und etwas stressig, mit einem einmal angelegten Template, vorallem auch mit zugehöriger CSS Datei, ist es aber allemale die Mühe Wert.
• 12. Formulare für barrierefreies Webdesign
  • Formulare sind einfach zu halten, sind viele Informationen nötig, dann sind diese auf jeden Fall in fieldset Gruppen zu ordnen
  • in jedem fieldset ist ein legend Tag anzugeben als Überschrift
  • Besser noch wäre in mehrern Schritten, auf mehreren Seiten die Daten abzufragen
  • jedem input oder select Tag ist eine id und ein name Attribut zuzuweisen, damit ein entsprechendes label Tag mit for Attribut dieses Element bechreiben kann
  • Für noch mehr Verständnis kann jedem input Tag ein Attribut title zugewiesen werden, mit einer genauren Beschreibung dieses Eingabfeldes
  • noch besser sind kleine Fragezeichen, Symbole oder ähnliches, welche man anklicken, oder per CSS gesteuertem Mausover aktivieren kann, mit einer jeweiligen Hilfestellung zum Element (besser, da hier CSS Formatierungen gemacht werden können im Gegensatz zum nur durch den Browser angezeigten title Attribut)
  • Auch wenn es der Internet Explorer nicht kann, sollte mit dem CSS Selector :focus gearbeitet werden, um Formular Felder, in welche man geklickt hat optisch hervorzuheben
  • Ganz wichtig sind auch aussagekräftige Fehlermeldungen. Wenn ein Besucher der Homepage falsche Eingaben macht. Perfekt ist, wenn Felder mit Fehleingaben im Formaular markiert werden und darunter eine Erklärung zum Fehler angezeigt wird.
  • Die Formular Verarbeitung darf ruhig, und sollte auch auf jeden Fall, per AJAX geschehen, natürlich muss das Formular aber auch ohne JavaScript funktionieren
  • Ein Formular sollte gegen Spambots und so natürlich gegen Spam über einen Spamfilter geschützt werden. Ein sogennantes Captcha ist allerdings nicht die beste Variante. Zunächst ist es dank OCR Software auch nicht 100% sicher, zudem braucht selbst ein Mensch mit scharfen Augen meist 2 oder 3 Versuche diese Captachs zu lesen. Barrierefreie Spamfilter bauen mehr auf das Lösen von Aufgaben, wie der ilimitado barrierefreie Spamfilter. Er stellt einfache Rechenaufgaben, die als Text gestellt und von jedem Menschen lösbar sind.
• 13. JavaScript, Flash, Filme etc. für barrierefreies Webdesign
  • Flash lässt sich nicht barrierefrei gestalten. Alle Inhalte, welche in Flash präsentiert werden sind weder dynamisch anpassbar, noch sind sie als reine Textversion verfügbar, nicht einmal ein Suchmaschinen Robot kann eine Flash Homeapage crawlen
  • Wenn mann Flash braucht, kann man also keine barrierefreie Homepage anbieten. Es sei denn, man präsentiert den Flash Inhalt alternativ in barrierefreiem XHTML (nicht als Plain Text Datei)
  • Filme können von Blinden selbstverständlich nicht gesehen werden, von Tauben Menschen nicht gehört werden etc… es ist im Einzelfall zu entscheiden, ob es Sinn macht Inhalte in alternativen Formen anzubieten. Vorallem Intervies kann man leicht auch in XHTML präsentieren und so mehr Leuten noch zugänglich machen
  • JavaScript ist prinzipiell mal ein Barrierefreiheit Killer… durch AJAX Technologieen kann eine Homepage Clientseitig nach dem Laden sogar ohne zutun des Surfers verändert werden. Dies bedeutet nicht, dass man auf AJAX und JavaScript verzichten muss, denn für einen Großteil der Surfer und Homepage Besucher stellt AJAX und JavaScript ja einen hohen Komfort bereit. Man muss nur sicherstellen, dass die Homepage eben auch ohne JavaScript funktioniert und leicht bediehnbar bleibt. Es ist aber auch klar, dass Web Applikationen wie Google Maps nicht ohne JavaScript funktionieren und das auch nicht müssen, da hier das Zielpuplikum deffinitiv JavaScript zur Verfügung hat.
• 14. CSS und XHTML für barrierefreies Webdesign
  • Es sollte eingltich klar sein, dass sämtliche Formatierungen des Inhalts in eine externe CSS Datei gehören und die XHTML Datei nur den semantischen Markup in XHTML enthält. Dazu gehört auch ein korrekter DOCTYPE
  • Genauso verhält es sich mit JavaScript. Alle Scripts sind auszulagern und es sind keine Handler (onklick oder Ähnliches) im Markup zu verwenden, sondern zum Beispiel durch Behaviour auszulagern
  • eine Homepage ist nich barrierefrei, wenn sie Fehler im Markup enthält. Jede einzelen Seite einer Homepage muss W3C XHTML und W3C CSS valid sein
  • CSS Angaben und XHTML Markup sind so zu gestalten, dass in allen Browsern das gleiche Erscheinungsbild vorliegt, im größten Notfall muss durch eine Browserweiche für einzelen Browser spezielle CSS Angaben zur Korrektur gemacht werden. Das ist aber selten notwendig und trifft meistens nur den Internet Explorer, welcher in Version 6 und Abwärts viele Bugs und abweichende Standards hat. Mehr Informationen, wie CSS in allen Browsern gleich gestaltet werden kann gibts hier.
• 15. Was sonst noch zu barrierefreies Webdesign zählt
  • Die Homepage sollte eine klare übersichtliche Aufteilung haben und auf keinen Fall aus diesem Design herrausspringen
  • Dank CSS können Navigation und Inhalt im Quellcode ganz oben stehen und Sidebars, Footer, Werbung etc. darunter, so werden in Screenreadern die wichtigsten und relevanten Inhalte zuerst vorgelesen und nicht erst eher uninteressante Zusatzinformationen.
  • Listen oder divs können und sollten ein title Attribut mit einer kleinen Funktionsbeschreibung enthalten
  • Jede Homepage ist ein individuelles Produkt und muss daher stets individuell betrachtet werden. Manchmal müssen Regeln angepasst oder gar “gebrochen” werden da so mehr Barrieren verhindert als erzeugt werden.
  • Zu guter letzt gehört zur Barrierefreiheit auch das Verständniss, dass barrierefreies Webdesign bei der Entwicklung von XHTML und anderen Techniken wie AJAX überhaupt nicht vorgesehen war, sondern ein sehr junges Produkt ist, ja viel mehr noch sogar ein neues Verständnis und eine neue Auffassung des Internets an sich. Barrierefreies Webdesign macht vieles Möglich, alle diese Tipps und Regeln erleichtern behinderten oder eingeschränkten Menschen des Surfen ungemein. Die Zukunft wird mit Techniken wie dem semantischen Web (manchmal auch Web3.0 genannt) das alles noch auf eine ganz andere Ebende stellen.
  • Barrierefreies Webdesign ist also nicht die perfekte Lösung, aber ein sehr gute Übergangstechnologie hin zu semantischem Web

So, ich hoffe diese Checkliste für barrierefreies Webdesign hilft dabei barrierefreie Homepages zu gestalten und vor allem Kleinigkeiten nicht zu vergessen. Falls hier noch was wichtiges fehlt freu ich mich auf Rückmeldungen, Tipps und Kommentare.

Weiterführende Links über barrierefreies Webdesign:
Web Accessibility Initiative des W3C
Bachelor-Thesis “Barrierefreie Gestaltung von Internetseiten”
Liste von Vorlesebrowsern
Webportal mit Schwerpunkt barrierefreies Webdesign
Brandneu: Lesezeichen der ilimitado OHG bei Mr Wong zum Tag barrierefreies

Weiterführende Literatur über barrierefreies Webdesign:

• Visuelle Barrieren blinder oder sehbehinderter Menschen
  • zu kleine Schrift, keine Möglichkeit den Schriftgrad zu erhöhen oder die Seite skaliert nicht so, dass sie noch lesbar ist.
  • zu wenig Kontrast, zu viel Farben keine Möglichkeit das Design anzupassen behindern sehschwache Surfer (Generation 50+) sowie farbenblinde Besucher der Homepage
  • (zu viele) Animationen lenken vom Text ab. Wenn man Informationen sucht, ist es sehr lästig, wenn Animationen (gif, flash) die Aufmerksamkeit auf sich ziehen und einfach nur ablenken. (und wenn es nur ein animiertes Favicon ist)
  • die Homepage wird von einem Vorlesebrowser (siehe Liste von Vorlesebrowsern) nicht korrekt wiedergegeben. Blinde haben dann keine Chance die Homepage zu benutzen.
• Technische Barrieren des Systems oder Browsers
  • Die Homepage kann nur in einem bestimmten Browser oder nur in bestimmten Versionen angezeigt werden. Schlecht für Besucher, welche den benötigten Browser nicht haben, nicht installieren können oder einfach nicht wollen.
  • Die Homepage ist so groß, dass sie einen schnellen Breitband Internetanschluss (DSL) braucht. Es gibt immer noch viele ISDN und Modem Surfer.
  • Ohne JavaScript funktioniert die Homepage nicht, aber nicht jeder hat JavaScript. JavaScript, vor allem in Kombination mit AJAX, kann ein absoluter barrierefrei Killer sein. Eine barrierefreie Homepage sollte auf jeden Fall ohne JavaScript funktionieren!
  • Informationen werden in Flash Filme verpackt, Flash hat nicht jeder. Flash ist schön für Werbung und eben Animation/Filmmaterial, aber nicht geeignet zur barrierefreien Präsentation von Informationen
  • Pop-Up Fenster werden oft durch Pop-Up-Blocker unterdrückt und sind somit einfach nicht sichtbar.
  • Die Homepage ist nicht XHTML konform (W3C valid) was zu unerwarteten Anzeigefehlern führen kann.
• Verständnis Barrieren kognitiv eingeschränkter Menschen
  • zu komplizierte Sprache
  • zu viel oder aber auch zu wenig Fachsprache, je nach Zielpublikum
  • extrem verzweigte Navigation (Alternative wären zum Beispiel Tagclouds)
  • Fehlende Suchmöglichkeiten auf Homepages mit viel Inhalt
  • Anmelde/Bestell Formulare mit zu vielen Optionen oder ohne Gliederung
  • Schwer identifizierbare bzw. schwer erkennbare Graphiken oder Piktogramme
  • Überladene Homepage mit vielen Bereichen ohne klare Trennung
  • Die Homepage ändert je nach Seite das Aussehen oder die Struktur
  • Frames sind teilweise schwer zu bedienen und zu begreiffen, sie scrollen jeder für sich und manche Browser kennen gar keine Frames
• Körperliche Barrieren motorisch eingeschränkter Menschen
  • Hörgeschädigte brauchen statt Audio Kommentaren Text
  • Menschen, welche keine Maus benutzen können, müssen die Homepage mit der Tastatur steuern. Das ist ein nicht zu unterschätzender Punkt und bietet auch erfahrenen Internetnutzern eine Möglichkeit schnell und einfach auf der Homepage zu navigieren.
• Subjektive Barrieren
  • schlechtes, nicht ansprechendes Design
  • zu viel Werbung schreckt ab
  • Informationen sind zu tief in der Homepage und erst nach mehreren Klicks erreichbar
  • Der gesamt Eindruck der Homepage vermittelt ein ungutes Gefühl (unseriös, spießig, überheblich etc.)
  • Der Zurück Button des Browsers ist nicht einsetzbar wegen AJAX oder Flash
  • Menschen, welche die Homepage nicht kennen und nach ihren erste 5 Minuten auf der Seite immer noch nicht sagen können worum es da geht verdeutlichen im Zweifelsfall ob man sein Ziel erreicht, hat oder eben nicht.

Man sieht, es gibt für fast jeden Menschen eine, wenn nicht mehrere, Barrieren eine Homepage zu besuchen, sie zu bedienen oder nur auf ihr zu navigieren etc.

Mögliche Szenarios wo Barrieren auftreten:
Ist die Homepage gut strukturiert (XHTML strict, Tabellenlos, CSS), die Navigation übersichtlich, auf Bilder verzichtet worden, große Schrift und hoher Kontrast eingesetzt ist diese Seite mit Sicherheit für sehbehinderte Menschen barrierefrei. Fehlt es ihr aber an optischen Effekten, ist sie für viele, vor allem jüngere Surfer eher uninteressant und nicht ansprechend genug. Dann stellt hier die Optik eine Barriere dar und man kann durchaus sagen, hier liegt ein “Verstoß” gegen die Grundregel barrierefreien Webdesigns vor.
Hat man dagegen eine schöne Homepage mit vielen Bildern, Farben, verzichtet aber darauf wenigstens durch hidden-Tags Strukturierungen einzubauen kann man wieder nicht von barrierefreiem Webdesign sprechen.
Sitzt man in der (Uni) Bibliothek kann man schlecht Videokommentare, oder Intervies anhören, da wäre eine Abschrift enorm hilfreich.

Barrierefreies Webdesign verlangt die Einhaltung aller Regeln, das Beachten aller Barrieren, egal ob es Barrieren für behinderte Menschen oder für nicht behinderte sind. Barrierefreies Webdesign bedeutet also nicht eine Homepage auch für blinde Menschen nutzbar zu machen, sondern allen Surfern zu möglichst gleichen Teilen.

Das klingt nach einem riesen Haufen Arbeit. Es ist jedoch gar nicht so schlimm. Barrierefreies Webdesign wäre nicht barrierefreies Webdesign, würde es dem Designer oder Programmierer einen Berg von Barrieren aufstellen. Und es sei hier noch mal angemerkt, wer sein Handwerk nicht beherrscht, oder zu Faul ist sich (weiter) zu bilden und dann Regeln sowie Techniken einzuhalten, der kann sich auch nicht professioneller Webdesigner nennen.
Durch Einhalten von XHTML Regeln, und Formatieren des Designs durch CSS erleichtert barrierefreies Webdesign das Erneuern oder Abändern des Designs enorm, da hier nur eine einzige Datei geändert werden muss. Dazu kommt, dass die Dateigrößen enorm zurückgehen. Gut besuchte Homepages haben einen monatlichen Traffic von mehreren Gigabyte. Wenn hier nur durch die
Änderung des XHTML Markups vielleicht nur noch die Hälfte an Traffic entsteht, liegt hier sogar ein enorme Kostenvorteil auf der Hand.

Letztendlich ist es ja auch ein beruhigendes Gefühl eine Homepage zu betreiben, die wirklich jeder beliebige Mensch in jeder Situation besuchen, lesen und verstehen kann.

Weiterführende Links über barrierefreies Webdesign:
Web Accessibility Initiative des W3C
Bachelor-Thesis “Barrierefreie Gestaltung von Internetseiten”
Liste von Vorlesebrowsern
Webportal mit Schwerpunkt barrierefreies Webdesign
Brandneu: Lesezeichen der ilimitado OHG bei Mr Wong zum Tag barrierefreies

Weiterführende Literatur über barrierefreies Webdesign:

!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”

als Doctype XHTML 1.0 Strict anzugeben. Man muss sich dann auch an die Regeln halten.
Manch einer wird jetzt sicher sagen, es funktioniert doch alles. Ja tut es aber auch nur weil die Browser den XHTML Code als Tag Soup interpretieren.

Man muss nicht Fehlerfrei sein aber 405 Fehler sind inakzeptabel.
Digg hat auf der Startseite gerade mal 10 Fehler!!
Immer diese Startups LOL.

Auch die einzigen Fehler in unserem Blog kamen von Yigg, weil im script Tag das type Attribut fehlt!!

Einen ausführlichen Artikel über das Thema barrierefreies Webdesign haben wir bereits auf der ilimitado Firmenhomepage veröffentlicht.
Dort kann man lesen, was barrierefreies Webdesign ist. Interessant ist aber auch, was barrierefreies Webdesign nicht ist:

Hier möchte ich auf Gerüchte und vielleicht auch falschen Tatsachen oder falsche Informationen, sowie Vorurteile rund um barrierefreies Webdesign eingehen.

Vorurteil und Gerücht Nummer eins lautet: Barrierefreies Webdesign ist hässlich

Man könnte bei einer optisch nicht ansprechenden Homepage, welche die Nutzer nur abschreckt, ja gar nicht über barrierefreies Webdesign sprechen, denn dann wäre das schlechte Design eine Barriere die Homepage zu besuchen. Ganz im Gegenteil durch das konsequente Trennen von Inhalt, Logik und Design hat man eher noch mehr Gestaltungsmöglichkeiten, als sonst.

Ein weiteres Gerücht behauptet das alternative Anbieten der Homepage im Plain Text Format ist Barrierefreies Webdesign. Das ist natürlich überhaupt nicht der Fall.
Klar, kann ein Screenreader (Vorlesebrowser) alles, was in der Text Datei steht vorlesen und so z.B jemand der blind ist noch einigermaßen an die Informationen herankommen, aber es fängt schon damit an, dass der Screenreader (Vorlesebrowser, siehe: Liste von Vorlesebrowsern) nicht entscheiden kann, was in einer Textdatei ein Link, was eine Überschrift und vor allem, was wichtig ist und was nicht.

Eine alternative Darstellung der Homepage als Text Datei ist also kein barrierefreies Webdesign.

Das nächste Gerücht, welches mir häufig begegnet ist barrierefreies Webdesign ist nur für behinderte Menschen.
Das ist so nicht richtig. Barrierefreies Webdesign (auch Web- Accessibility) beschreibt zunächst einfach die Gestaltung von (web basierten) Informations- und Kommunikationssystemen, die die Benutzung einer Homepage ohne Hindernisse erlaubt und keinen Benutzer von der Möglichkeit ausschließt, diese Homepage zu verwenden.
Das Wort “barrierefrei” bedeutet mehr als nur “behindertengerecht”. Es geht darum, möglichst alle Barrieren abzubauen, die es Benutzern erschweren oder sogar unmöglich machen, Inhalte einer Homepage zu erfassen.
Barrierefreies Webdesign bedeutet deshalb, dass jeder, egal welchen Webbrowser er benutzt, welche Schwächen er hat, in der Lage sein soll, jede beliebige Homepage zu besuchen. Wichtig ist hierbei, dass der Besucher ein komplettes Verständnis der angebotenen Informationen bekommt und vollständig mit der Homepage interagieren kann.

Ebenfalls nicht korrekt ist, dass barrierefreies Webdesign sehr teuer ist. Was bei der strukturierten Trennung von Inhalt, Design und Programmier Logik mehr aufgewendet wird, muss an anderen Stellen, z.B. dem Anpassen, Ergänzen, Erweitern und Verwalten der Seite nicht mehr aufgewendet werden. Letztendlich ist der Zeitaufwand beim Erstellen der Homepage sicherlich höher, wie beim Verzicht auf barrierefreies Webdesign, aber dafür später beim Verwalten und Einstellen der
Inhalte kleiner. Deswegen sind die Kosten beim Portieren einer Homepage in barrierefreies Webdesign fast so teuer, wie das neu Erstellen einer barrierefreien Homepage, da es nämlich nahezu auf genau das hinausläuft. Plant man aber sowieso ein Redesign seiner Homepage, zum Beispiel im Zuge mit Web2.0 lohnt sich barrierefreies Webdesign schon wieder. Es bietet vor allem auch Investitionssicherheit für Unternehmen, weil die Entwicklung des WWW´s in genau diese Richtung, der Trennung von Modell und Präsentation, geht.

Zu guter Letzt, noch die Behauptung Ein barrierefreies CMS ist nicht möglich. Dazu kann ich nur sagen, das ist absoluter Quatsch.
Ein CMS ist, wie der Name schon sagt nichts weiter, als ein System, was den Seiteninhalt verwaltet. Also letztendlich die Schnittstelle zu einer Datenbank. Wir setzen in diesem Bereich aber sowieso meistens XML Dateien ein, diese sind dynamischer und flexibler.
Wie der Inhalt dieser XML Dateien oder der Datenbank dann dem Surfer und Besucher der Seite präsentiert wird, hat nichts mit dem CMS zu tun.
Hierfür ist im Normalfall eine Template Engine zuständig. Ein gutes CMS ist also allein durch das Anlegen eines barrierefreien Templates fähig eine Homepage barrierefrei darzustellen. Ganz abgesehen davon kann man auch jederzeit ein eigenes kleines CMS (oder auch nur ein kleines Backend) programmieren und so natürlich jederzeit garantieren, sich an barrierefreies Webdesign zu halten. Schwierig wird es nur bei einem CMS welches ausser der Anpassung eines Templates noch einen größeren Programmier Aufwand mit sich bringt, da es nicht unabhängig genug programmiert worden ist.

Nochmal: Ein gutes CMS verwaltet nur den Inhalt einer Datenbank, besitzt eine Templateengine welche den Datenbankinhalt als Homepage präsentiert, welche wiederum in ihrem Aussehen und Format durch ein Template bestimmt wird. Zugegeben ich habe so ein “Traum” CMS auch noch nicht gefunden, ilimitado ist aber grade dabei in der iEngine so etwas zu implementieren.

Letztendlich ist barrierefreies Webdesign und auch Webdesign allgemein ein Handwerk, welches erlernt werden muss. Aber ich möchte folgenden Vergleich wagen: Hat mein Auto einen Schaden, gehe ich ja nicht zum nächsten Hobbyschrauber und lasse mein Auto reparieren sondern bringe es in eine Fachwerkstatt, wo ein Automechaniker sein Handwerk gelernt hat und weiss was er tut. So verhält es sich auch beim barrierefreien Webdesign, der Webdesigner muss sich hinsetzen, lernen, üben und testen, bis er die Standards, die Regeln und die Eigenarten der Browser, die Wünsche der Kunden barrierefrei umsetzen kann.
Webdesign, vorallem professionelles Webdesign ist kein Hexenwerk aber auch kein Kinderspiel. Wer professionell Homepages programmiert bzw. designed, sollte eigentlich fast automatisch eine barrierefreie Homepage erzeugen. So wie ein Mechaniker auch ganz automatisch in jedem Motor gleich die Zündkerzen findet.

Barrierefreies Webdesign ist also weder überaus teuer, barrierefreies Webdesign ist nicht einfach nur etwas für behinderte Menschen, barrierefreies Webdesign ist auch in einem CMS realisierbar und barrierefreies Webdesign ist mit ganz großer Sicherheit auch nicht hässlich.
Von daher sollte doch jeder, der sich für eine neue Homepage bzw. ein Redesign seiner Homepage entscheidet, den Weg des barrierefreien Webdesigns gehen. Es ist eine Investition in die Zukunft.

Weiterführende Links über barrierefreies Webdesign:
Web Accessibility Initiative des W3C
Bachelor-Thesis “Barrierefreie Gestaltung von Internetseiten”
Liste von Vorlesebrowsern
Webportal mit Schwerpunkt barrierefreies Webdesign
Brandneu: Lesezeichen der ilimitado OHG bei Mr Wong zum Tag barrierefreies

Weiterführende Literatur über barrierefreies Webdesign:

The Mozilla/Firefox Accessibility Extension makes it easier for people with disabilities to view and navigate web content. Developers can use the extension to check their use of structural and styling markup that support functional web accessibility.

Die barrierefrei Erweiterung integriert sich nach der Installation als Toolbar im Kopfbereich des Firefox Browsers und kann optional auch (standardmässig) ausgeblendet werden.

Wie man schon im Bild sehen kann, gibt es folgende Unterteilung:

• Navigation:
  Unter dem Punkt Navigation kann man sich in kürzester Zeit einen Überblick über das Dokument verschaffen. Unter anderem können so sehr schnell Titel, Überschriftshierarchien, Menü- und Navigationsteuerung und Accesskeys erfasst werden, was vor allem Menschen mit Beeiträchtigungen eine Menge Zeit sparen kann. Neben den gerade genannten kann man noch diverse andere Informationen abrufen, die einem dabei Helfen den Aufbau und die Struktur einer Homepage schneller zu erfassen.
• Text Equvalents:
  Unter dem zweiten Punkt Text Equivalents können Listen mit allen angezeigten Bildern incl. Alternativtext und Größe oder dem Abkürzungsverzeichnis des Dokumentes angezeigt und manipuliert werden.
• Scripting:
  Wie der Name schon sagt können hier interaktive Elemente gesteuert werden: z.B. kann man so alle Java Scripts anzeigen oder ganz bzw. teilweise abgeschalten. Mit teilweise ist gemeint, dass z.B. nur die Mouse- oder die Window Handler abgeschaltet werden können
• Style:
  Dieser Punkt bietet eine umfassende Möglichkeit die CSS Steuerung zu beeinflussen. So kann natürlich die CSS Datei abgeschaltet werden, es kann aber auch einfach ein lokales CSS-Stylesheet eingebunden werden, was natürlich ungeahnte Möglichkeiten bietet. Des weiteren gibt es ein automatisches Kontrast Rendering einer jeder angezeigten Seite. So können auch Homepages die nicht barrierefrei umgesetzt sind in einem höheren Kontrast betrachtet werden.
• Validators & Tools:
  Die beiden nächsten Punkte Validators und Tools sind hauptsächlich für Entwickler Gedacht. So können unter Validatoren, die jeweiligen Webseiten auf einhalten der technisch überprüfbaren Regeln überprüft werden. U.a. sämtliche W3C
  und WDG Validatoren. Unter Tools finden sich einige sehr gute Analysewerkzeuge zum überprüfen auf Einhaltung der WAI Best Practises zur Barrierefreiheit. U.a FAE, TAW, Cynthia .
• Keyboard:
  Der Punkt Keyboard ermöglicht es benutzterspezifische Shortcuts zu definieren und erweitert somit die Funktionalität der accesskeys.
• Options:
  Hier können einige Konfigurationseinstellungen für die firefox barrierefrei Erweiterung gesetzt werden.
• Zoom:
  Ermöglicht ein stufenweises vergrößern und verkleinern der Homepage

Mein Fazit fällt wirklich sehr positiv aus, Mit den Navigation und Text Equivalents kann man sehr schnell seine Überschriften- und Navigationshierarchien überprüfen.
Mit den Validator und vor allem den Tools können Struktur und Programmierfehler sofort erkannt und verbessert werden. Die Möglichkeit Handler abschalten zu können, bietet außerdem eine einfache Möglichkeit seine Rich Client oder Java Script Anwendungen auf Barrierefreiheit zu testen.

Weiterführende Links:


iCITA Firefox barrierefrei Erweiterung
WAI
FAE
TAW

Das impliziert eigentlich schon, das ein Impressum nicht per Pop-Up-Fenster dargestellt werden darf, denn ein solches Pop-Up-Fenster lässt sich nur durch JavaScript realisieren. JavaScript ist aber nicht automatisch in jedem Browser verfügbar/aktiviert. Somit ist Surfern ohne JavaScript bei einem Impressum per Pop-Up-Fenster gar nicht möglich es zu erreichen. Die Bedingung “ständig verfügbar” wäre also nicht erfüllt. Pop-Up-Fenster sind allgemein ein No-Go in Bezug auf barrierefreies Webdesign.

Ein weiterer Punkt sind sogenannte Pop-Up-Blocker(hauptsächlich gegen nervige Werbung), welche Heutzutage in viele Browser eingebaut sind und Pop-Up-Fenster(auch Impressums) blockiert und gar nicht erst anzeigt, auch wenn ansonsten JavaScript aktiviert/verfügbar ist.

Tatsächlich gibt es auch ein Urteil des OLG Düsseldorf (es trägt das vielsagende Aktenzeichen: VI-U (Kart) 23/05 und ist vom 13.4.2006) in welches tatsächlich den Schluß zulässt, dass es den gesetzlichen Anforderungen nicht genügt, das Impressum in einem Pop-Up-Fenster zugänglich zu machen. Der Richter spricht sogar von “wettbewerbsrechtlich unzulässig”.

Es spricht also allein schon in Bezug auf barrierefreies Webdesign viel dagegen ein Impressum per Pop-Up-Fenster darzustellen und darüber hinaus ist auch rechtlich gar nicht zulässig.