Webdesign: So wird deine Website valide, barrierefrei, sicher und schnell

Webentwicklung wird zunehmend komplexer. Neben korrekter Auszeichnung von HTML und CSS gibt es zahlreiche weitere Faktoren, die zwar nicht zwingend das korrekte Aussehen einer Website beeinflussen, aber dennoch auf den Erfolg einer Website Einfluss haben. Dazu gehört eine barrierefreie Darstellung der Inhalte, sowie eine schnelle Erreichbarkeit. Das alles selbst im Blick zu haben, ist schwierig. Daher gibt es zahlreiche Tools, die dir dabei helfen, zu dem Werturteil „Alles paletti“ zu gelangen. Das Barrierefreiheitsstärkungsgesetz (BFSG) kommt ab Mitte 2025 und fast alle Website-Betreiber sind betroffen.

Augenerkrankungen und barrierefreies Webdesign

Blinde haben Probleme mit Nicht-Text-Elementen

Eigentlich ein ganz logisches Problem. Grafisch dargestellter Text, Bilder, ImageMaps, animierte Gifs, grafische Menüführungen oder Buttons und sogar ASCII-Zeichnungen benötigen eine Alternative, einen beschreibenden Text. Laut Vorgabe sollen sämtliche Formate, die nicht im Text beschrieben werden, einen alternativen Text bekommen.

Das kann leicht getestet werden, indem einfach in den Einstellungen des Browsers das Laden von Bildern verboten wird. An Stelle des Bildes zeigt der Browser nun den alternativen Text an, sofern dieser auch hinterlegt ist. Selbst schmückende Elemente oder Spacer, die selbst keine Inhalte transportieren, sollten mit einem leeren alt=“” versteckt werden.

Wenn sich jetzt beim Lesen ohne Bilder noch der gesamte Inhalt und jegliche Funktionen der Seite erschließen lassen, kann dieser Punkt getrost abgehakt werden. Denn ein Screenreader liest genau das vor, was jetzt noch auf dem Bildschirm zu lesen ist. Es ist klar, dass auch so der Inhalt weiterhin Sinn macht. Bei Imagemaps bekommt jede aktive Region ein eigenes „alt“-Attribut. Unmittelbar an der Grafik sollten aber die gleichen Ziele als zusätzliche Links angeboten werden.

Auch Blinde nutzen das Internet

Farbenblinde sehen anders

Etwa jeder zehnte männliche Besucher einer Website ist Farbenblind. Wobei es ganz unterschiedliche Arten der Farbenblindheit gibt.

„Die Farbenblindheit (Achromatopsie; auch Tagblindheit) ist eine sehr seltene, autosomal rezessiv vererbte Erkrankung der Netzhaut. Betroffene Menschen sind vollkommen oder partiell farbenblind. Eine Variante, die atypische Achromatopsie, bei der noch eine größere Restsichtigkeit im Blaubereich besteht und die deshalb Blau-Monochromasie genannt wird, wird X-chromosomal vererbt (Genort Xq28). „“Dies ist jedoch nicht mit der häufiger vorkommenden Farbenfehlsichtigkeit (Rot/Grün-Sehschwäche) zu verwechseln. Letztere wird in der Umgangssprache oft mit dem Begriff „Farbenblindheit“ bezeichnet wird, doch medizinisch korrekt ist es, von „Farbfehlsichtigkeit“ zu sprechen.“ Quelle: Wikipedia

Deshalb sollte generell auf hohen Kontrast geachtet und auf Hinweise wie „Bitte klicken Sie auf den grünen Button“ verzichtet werden. Ein hoher Kontrast nützt auch bei besseren Darstellung auf Schwarz-Weiß-Bildschirmen. Ein Graustufentest im Grafikprogramm als Screenshot simuliert diesen Effekt. Wer sich selbst einmal testen möchte besucht die Internetseite von UMDS oder der GFO. Praktisch: Das kostenlose Online-Tool Vischeck oder der Colorblind Filter zeigt Websites mit den Farben an, wie sie Besucher mit den gängigsten Farbfehlsichtigkeiten sehen würden.

Wer die Zahlen lesen kann ist nicht Farbenblind

Problem Sprache

Sprachliche Besonderheiten wie der Wechsel der Sprache oder Abkürzungen sind zu kennzeichnen. Leider verstehen die meisten Browser die in HTML vorgesehenen Elemente für die Anzeige des Sprachwechsels überhaupt nicht. Doch wo liegt das Problem für den Behinderten. Screenreader sprechen zumeist sämtliche Worte in der voreingestellten Sprache aus. Deshalb werden Fremdsprachen etwas komisch klingen. Wer trotzdem die HTML-Seiten passend ausrüsten möchte, beachte das folgende Beispiel:

<span lang="en" xml:lang="en">Highlight</span>

Abkürzungen Akronyme

Die Uneinigkeit macht das zum großen Problem. SCSI zum Beispiel kann sowohl „Skasi“ als auch „ES Zeh Es Ih“ ausgesprochen werden. Hinzu kommt, dass das <acronym>–Tag von vielen Browser nicht verstanden wird, auch vom Screenreader und Sprachbrowser nicht. Verweise auf ein Glossar sind hier wohl die beste Lösung. Mit <html lang=“de“> bekommt der Browser noch die Information mit, welche Sprache die vorherrschend verwendete natürliche Sprache ist.

Auch die Sprache macht Probleme

Was ist mit Tabellen?

Layout-Tabellen aus HTML sind aus guten Gründen out, weshalb auch die BITV CSS empfiehlt. Werden Tabellen wirklich zur Darstellung tabellarischer Daten verwendet, sollen Zeilen– und Spaltenköpfe mit den Überschriften der einzelnen Zellen mit Tags wie <caption>, <thead> und <tbody> sowie <th> und <td> mit den Attributen id und headers beschrieben werden. Verschachtelte Layout-Tabellen sind generell tabu.

Die Verordnung sagt: „Tabellen sind nicht für die Text- und Bildgestaltung zu verwenden, soweit sie nicht auch in linearisierter Form dargestellt werden können“. Für den Webdesigner vermutlich die schwerste Hürde. Notwendig wird es dadurch, dass der Screenreader nicht mehr erkennt, in welcher Reihenfolge er weiterlesen muss.

Tabellen können stören

Problemfall Animationen

Das Internet ist schon sehr lange nicht nur eine einfache Sammlung von Textdokumenten, sondern auch Bewegung mit Flash oder per DHTML. Nun sagt die BITV: „Bildschirmflackern ist zu vermeiden“ und „Blinkender Inhalt ist zu vermeiden“. Die Begründung ist, dass bei Epilepsiekranken bestimmte Frequenzen flackernder Inhalte einen Anfall auslösen können. Daher sollten schnelle Bewegungen und ein zu schneller Wechsel von Hell zu Dunkel vermieden werden. Das gilt für animierte GIFs als auch für alle sonstigen Formate wie Flash oder Java. Nicht nur der Epileptiker wird dafür dankbar sein.

Für Animationen mit viel Inhalt muss es die Möglichkeit geben, den Film anzuhalten und vor- und zurückzuspulen.

Barrierefreiheit im Internet dreht sich beileibe nicht nur darum, Menschen mit Augenkrankheiten, wie schwer diese auch sein mögen, Zugang zu Informationen zu ermöglichen. Dennoch dreht sich dieser Artikel ausschließlich um ausgewählte Einschränkungen der visuellen Wahrnehmung.

Blindheit ist nicht das Einzige, das bei der Entwicklung zugänglicher Angebote zu adressieren ist. Damit soll er der Tendenz vorbeugen und auch dem Vorwurf entgegentreten, dass manche Webdesigner und -entwickler eben nur Blindheit mit „Barrierefreiheit“ verbinden.

Anmerkung: Der Autor ist kein Mediziner. Aus diesem Grund ist dieser Artikel eher knapp gehalten und verweist mit Vorliebe auf weiterführende Dokumente. Etwaige Fehler werden umgehend korrigiert. Ausschließlich medizinische Fragen richten Sie bitte an einen Arzt Ihres Vertrauens.

Skotopische Sensitivität

Skotopische Empfindlichkeit oder auch Meares-Irlen-Syndrom ist ein 1983 von Helen Irlen diagnostiziertes Problem mit Lichtempfindlichkeit, das vor allem bei schwarzem Text auf weißem Grund auftritt. Die prinzipiell sowohl im Zusammenhang mit Papier als auch am Monitor zu beobachtenden Symptome umfassen:

• Die Empfindung, dass die Seite zu hell oder grell ist;
• Buchstaben scheinen sich zu bewegen oder zu verschwimmen;
• Konturen oder „Flüsse“ erscheinen im Text („Rivers of White Space„).

Die Symptome können dabei nicht nur das Lesen erschweren, sondern auch Kopfschmerzen und generelle Unlust am Lesen verursachen.

Verbreitung:

~45 %.

Designmaßnahmen:

„Blassere“ Hintergrundfarben, schwächerer Kontrast.

Kurz-, Weit- und Alterssichtigkeit

Weder Kurzsichtigkeit (Myopie) noch Weitsichtigkeit (Hyperopie) noch Alterssichtigkeit (Presbyopie) sind Krankheiten im eigentlichen Sinne, aber weltweit stark verbreitet (DOC, 43 KB). All diese drei Beeinträchtigungen können in der Regel zudem durch Brillen oder Kontaktlinsen ausgeglichen werden. Aber: Eine Fehlsichtigkeit muss natürlich erstmal bemerkt werden. Und nochmal zum Mitsingen für alle, deren Webseitenschriftgröße maximal zehn Pixel betragen darf: Nicht jeder Mensch verfügt über Adleraugen.

Verbreitung:

15-25 % kurzsichtig (USA), ~35 % weitsichtig (Spanien), ~100 % altersweitsichtig ab 40/45 Jahren.

Designmaßnahmen:

Nicht „zu kleine“ Standardschriftgröße, auch im Internet Explorer (bis Version 6) skalierbar.

Wichtig ist, was Jan Eric Hellbusch treffend anmerkt:

Wer sehr starken Vergrößerungsbedarf hat, wird in der Regel ein Vergrößerungssystem oder eine Bildschirmlupe einsetzen – beides Programme, die einen Ausschnitt des Bildschirms vergrößern. Während Bildschirmlupen im Prinzip wie eine Lupe funktionieren und Inhalte in einem beweglichen Fenster anzeigen, bieten Vergrößerungssysteme komplexe Funktionen, die von der Anpassung von Layout und Veränderung von Farben bis hin zu unterstützender Sprachausgabe reichen.

Nicht jeder mit einer Sehschwäche oder Sehbehinderung benötigt aber starke Vergrößerung. Oft reichen einige kleinere Änderungen am System, um den Bildschirm lesen zu können.

Farbfehlsichtigkeit

Wikipedia sagt:

Die Begriffe Rot-Grün-Sehschwäche und Rot-Grün-Blindheit sind die wissenschaftlichen Fachtermini für über 99 % der Farbfehlsichtigkeiten, die umgangssprachlich als Farbenblindheit bezeichnet werden. Die Betroffenen können hierbei die Farben Rot und Grün schlechter als Normalsichtige unterscheiden. Hervorgerufen wird diese Behinderung durch Veränderungen der Aminosäuresequenz in den Sehpigment-Proteinen (Opsin) der entsprechenden Zapfen der Netzhaut, die aus der Veränderung der Gensequenz des entsprechenden Opsins resultiert.

Bekannte Fehlsichtigkeiten:

• Protanopie: Rotblindheit;
• Deuteranopie: Grünblindheit;
• Tritanopie: Blaublindheit;
• Achromatopsie: Unfarbigkeit (totale Farbblindheit).

Farbfehlsichtigkeit ist in der Regel leicht zu berücksichtigen, indem Informationen nicht nur über Farbe, sondern auch Form oder Beschriftungen vermittelt werden. Zusätzlich stellt es selten ein Problem dar, problematische Farbkombinationen insgesamt zu vermeiden. Webdesigner können sich über diverse Werkzeuge, wie zum Beispiel Vischeck, davon überzeugen, dass Informationsangebote auch für Farbfehlsichtige hinreichend dargestellt werden.

Online finden sich vor allem zu Farbfehlsichtigkeiten (oder „Farbenblindheit“) einige wirklich gut bis ausgezeichnet aufbereitete Hintergrundinformationen, unter anderem bei Joe Clark, der englischen Wikipedia, der Florida State University und auch Terrace L. Waggoner.

Abbildung: Protanopie-Testbild, das Farbfehlsichtigen die Zahl „17“ zeigt, Normalsichtigen „47“ (Lizenzbestimmungen).

Verbreitung:

4-5 %.

Designmaßnahmen:

Entsprechende Farbkombinationen meiden und/oder Farbunterscheidbarkeit gewährleisten.

Retinitis pigmentosa

Die Wahrnehmung von Farben kann im Hinblick auf Kontraste generell eingeschränkt sein. Ausreichender Kontrast sollte zur Informationsvermittlung immer gewährleistet werden; offensichtlich (aber nicht begrenzt auf) ist dies bei Erkrankungen wie Retinitis pigmentosa, bei der verschlechterte Kontrastwahrnehmung eines der Symptome darstellt:

Mit Retinitis pigmentosa bezeichnet man eine Gruppe von erblichen Augenerkrankungen, die eine Zerstörung der Netzhaut zur Folge haben. Diese zur Zeit noch unheilbare Krankheit ist heute noch eine der häufigsten Ursachen des Sehverlustes. Es handelt sich um eine Erbkrankheit, die an die Nachkommen weitergegeben werden kann.

Ein weiteres, wesentliches Symptom von Retinitis pigmentosa ist „Tunnelblick“, so dass am Bildschirm nur ein kleiner Ausschnitt der dargestellten Informationen wahrgenommen wird. Dies erfordert Orientierungshilfen in Form von beispielsweise Umrahmungen oder deutlich unterschiedliche Hintergrundfarben für einzelne Bereiche eines Dokuments.

Verbreitung:

0,025-0,3333 %.

Designmaßnahmen:

Stärkerer Kontrast, deutlichere Abgrenzung von Seitenbereichen.

Fotosensitive Epilepsie

Fotosensitive Epilepsie ist eine besondere Form von Epilepsie und wird durch visuelle, flimmernde Reize verursacht. Untersuchungen zufolge kann „Flackern“ in einer Frequenz von 16 und 25 Hz epileptische Erscheinungen hervorrufen, andere Quellen – via Gez Lemon – sprechen gar von einem Spektrum von 3 bis 60 Hz.

Verbreitung:

~0,0095 %(~5 % der Epilepsiebetroffenen).

Designmaßnahmen:

Vermeiden oder zumindest Verkleinern von flimmernden Flächen.

Farbenblindheit

„Echte“ Farbenblindheit (Achromatopsie) ist ein sehr seltener Gendefekt der Netzhaut und äußert sich darin, dass Betroffene gar keine Farben wahrnehmen können. (Nahezu) vollständige Farbenblindheit, Lichtscheu (Photophobie), Augenzittern (Nystagmus) und reduzierte Sehschärfe sind typische Symptome von Farbenblindheit.

Anmerkung: „Farbenblindheit“ wird im Deutschen fälschlicherweise und vermutlich aufgrund des im Englischen leicht abweichenden Wortgebrauchs oft mit Farbfehlsichtigkeit verwechselt. (Der Autor bildet da kaum eine Ausnahme.)

Verbreitung:

< 0,0001 %.

Designmaßnahmen:

Farbunterscheidbarkeit gewährleisten, stärkerer Kontrast.

Fazit

Auch wenn die vorgestellte Auswahl an Limitationen nicht allumfassend ist – der Einfachheit halber fehlen insbesondere Anmerkungen zu Makuladegeneration und Usher-Syndrom -, sollte deutlich werden, dass eingeschränkte optische Wahrnehmung, ob nun durch eine Sehbeeinträchtigung oder Sehbehinderung bedingt, wirklich nicht nur Blindheit bedeutet. Ganz besonders sollte sie dabei aufzeigen, dass:

• wesentlich mehr Menschen keine „perfekten“ visuellen Fähigkeiten besitzen, als man denken mag;
• viele Wahrnehmungsprobleme relativ leicht zu adressieren sind, trotz scheinbarer Konflikte (wie zum Beispiel die Kontrastempfehlungen bei skotopischer Sensitivität und Retinitis pigmentosa).

Vielen Dank für Hinweise und Anregungen an den selbst stark sehbehinderten Jan Eric Hellbusch, der viele Jahre die AG Sehbehinderte geleitet hat.

Klassische Validatoren für HTML und CSS

Als allererstes solltest du natürlich sicherstellen, dass dein HTML- und CSS-Quelltext richtig ausgezeichnet ist. Das W3C bietet hier einen Validator an, der deinen HTML-Quelltext auf Fehler durchsucht und Warnungen sowie Verbesserungsvorschläge ausgibt. Neben Einhaltung der Syntax gibt es weitere Faktoren, die bei HTML beziehungsweise HTML5 eingehalten werden sollten.

Gerade bei HTML5 spielt die Semantik eine große Rolle. Du solltest also darauf achten, dass deine Website sich an die semantischen Regeln von HTML5 hält. Dazu gehört etwa, dass Überschriften richtig gesetzt werden. So sollte jedes „<article>“-Element immer eine Überschrift beinhalten. Mehrere „<h1>“-Überschriften sollten vermieden werden. Der W3C-Validator macht dich auf diese Dinge aufmerksam.

Auch für CSS gibt es einen entsprechenden Validator, der dich auf Auszeichnungsfehler hinweist. Leider interpretiert dieser Vendor-Prefixe als Fehler, weshalb ein tatsächlich valider CSS-Quelltext praktisch wenig sinnvoll ist.

Barrierefreiheit prüfen

Zunehmend wichtiger wird der Aspekt der Barrierefreiheit bei der Webentwicklung. Dies stellt Webdesigner und -entwickler vor große Herausforderungen. Denn für Menschen mit Sehbehinderungen muss eine Website besondere Merkmale erfüllen, damit diese mit Screenreadern erfasst werden kann. Dazu gehört, dass Inhalte, die mit dem Auge einfach erfasst werden können, so ausgezeichnet sind, dass Screenreader etwa Navigationselemente und Randbereiche einer Website gut interpretieren können.

Der HTML_CodeSniffer hilft dir dabei, kritische Elemente in deinem Quelltext zu finden und gibt dir Hinweise, inwiefern diese nicht barrierefrei sind. Dabei berücksichtigt das Tool mehrere Standards, die ein unterschiedliches Maß an Barrierefreiheit vorsehen.

Sichere Websites bevorzugt

Auch der Sicherheitsaspekt wird in der Webentwicklung immer wichtiger. So bewertet Google bereits Websites, die per SSL verschlüsselt sind, in Suchergebnissen besser. Gerade, wenn persönliche Daten übertragen werden – vor allem bei sozialen Netzwerken und Online-Shops ist das der Fall – solltest du sicherstellen, dass diese verschlüsselt werden.

Mit dem SSL-Report von Qualys SSL Labs bekommst du einen schnellen Überblick, ob deine Website per SSL verschlüsselt ist und welche weiteren Faktoren ein mögliches Sicherheitsrisiko sein können.

Die Website securityheaders.io gibt dir Auskunft darüber, welche sogenannten Security-Headers gesetzt sind. Gerade in Kombination mit HTTPS können hier zusätzliche Sicherheitsschranken gesetzt werden, die zum Beispiel dafür sorgen, dass eine sichere Verbindung zu einer Domain auch beibehalten wird und nicht versehentlich zu einer unsicheren Verbindung gewechselt wird. Securityheaders.io haben wir schon ausführlicher vorgestellt.

Schnelligkeit ebenfalls wichtig

Trotz Breitbandausbau solltest du immer darauf achten, ob deine Website auch schnell geladen wird. Gerade beim mobilen Internet ist es dank geringerer Bandbreiten und gedeckelter Datenvolumina wichtig, die zu übertragenden Daten gering zu halten.

Die Google PageSpeed Insights helfen dir dabei, herauszufinden, wo es Optimierungsmöglichkeiten bezüglich der Ladezeiten bei deiner Website gibt. So weist dich der Dienst etwa darauf hin, ob die Dateigröße von Bildern durch bessere Komprimierung reduziert werden kann und ob deine JavaScript- und CSS-Dateien das Rendering der Seite blockieren.

Eine Alternative zu Googles Dienst ist GTmetrix. Er funktioniert ganz ähnlich und gibt dir als prozentualen Wert an, wie schnell deine Website ist und wie viel Optimierungspotenzial vorhanden ist. Dabei werden über 25 Parameter geprüft, die relevant für die Geschwindigkeit sind und bei Bedarf optimiert werden können.

Mobiltauglichkeit testen

Zu guter Letzt – wo wir schon beim mobilen Internet waren – spielt natürlich auch die Frage eine Rolle, wie gut eine Website auf Mobilgeräten funktioniert. Auch hier hat Google ein spezielles Tool, welches dich darüber informiert, ob deine Website „mobile friendly“ ist. Der Test auf Optimierung für Mobilgeräte gibt kurz und knapp wieder, ob es Optimierungsbedarf gibt.

Ist das Weblayout responsiv? Sind Links und Buttons groß genug und haben sie einen ausreichend großen Abstand zueinander? Ist die Schrift gut lesbar? All diese Faktoren werden bei dem Test berücksichtigt.

Auch die Seite mobiReady testet deine Website auf Mobilfreundlichkeit. Dabei wird diese auf einem Desktop sowie drei Smartphones simuliert. Als Ergebnis erhältst du einen Score, der deine Website mit den 1.000 weltweit größten Websites vergleicht. Außerdem erhältst du auch hier eine Reihe von Hinweisen, woran es hakt und wo du etwas verbessern kannst.

The Accessibility Project – Barrierefreies Design für den Alltagsgebrauch

Erst vor ein paar Tagen stellten wir Ihnen den HTML_CodeSniffer vor, ein Bookmarklet, das Websites auf den Grad der Barrierefreiheit überprüft. Heute lief uns ein brandneues Projekt vor die Flinte, das sich unterstützend mit der Umsetzung von Barrierefreiheit im Webdesign beschäftigt und dabei einen Community-Ansatz verfolgt. Das Accessibility Project, kurz A11y, wächst schnell und ist erfrischend anders.

Accessibility im Webdesign leicht und richtig umgesetzt

Wer sich – wie ich – schon einmal mit dem Thema Barrierefreiheit auseinandergesetzt hat, wird schnell festgestellt haben, dass Barrierefreiheit gern auf einer Ebene diskutiert wird, die man mit Fug und Recht als akademisch bezeichnen kann. Beiträge zu Accessibility sind in der Regel tiefgehend und detailliert, was zwar einerseits sehr fundiert anmutet, andererseits jedoch die Einstiegshürden, teils unnötig, erhöht.

The Accessibility Project hat sich daher verschiedene alternative Ansätze überlegt. Einer davon ist, anstelle langatmiger Tiefenartikel auf kurze, unterhaltsame Beiträge zu setzen. Designer sollen ermutigt werden, sich mit der Materie auseinander zu setzen. Da sich Methoden und Techniken schnell ändern, setzt A11y auf Github als Plattform für das Projekt. Auf diese Weise kann der Inhalt crowdsourced aktuell gehalten werden.

Die Betreiber sind offensichtlich Praktiker. Das Projekt wirkt bereits im jetzigen frühen Stadium sehr durchdacht. Alles ist auf Zugänglichkeit und Standards ausgelegt. Das Design des Projekts selber basiert auf Bootstrap. A11y soll auf so vielen Plattformen wie möglich nutzbar sein.

In der Tat macht das Stöbern auf der Projekt-Seite regelrecht Spaß, was man dem Thema aus leidvoller Erfahrung nicht zugetraut hätte. Auf einer Seite mit weiteren Ressourcen empfehlen die Betreiber weitere Lektüre, stellen nützliche Software zusammen, verweisen auf relevante Blogs und halten die ein oder andere der heute so beliebten Infografiken bereit. Für den Soforteinstieg findet sich eine kleine Checkliste zu verwendender HTML-Elemente. Verschiedende Quick Tipps und ebensolche Quick Tests versprechen praxisnahe Unterstützung ohne übermäßigen theoretischen Overhead.

The Accessibility Project ist zweifellos sinnvoll und auch im jetzigen, sehr frühen Stadium schon nützlich. Alle Kundigen sind eingeladen, zur Erweiterung der Knowhow-Basis beizutragen.

Links zum Beitrag:

• A11y-Repository | Github
• The Accessibility Project | a11yproject.com
• A11y Resources | a11yproject.com

Tear Down This Wall: HTML_CodeSniffer überprüft Websites auf Barrierefreiheit

Barrierefreiheit ist eine große gesellschaftliche Aufgabe, die in den letzten Jahren an Priorität gewonnen hat. Auch für Websites wird ein mindestens barrierearmer Zugang immer wichtiger. Der HTML_CodeSniffer ist ein Tool, welches dabei hilft, eine Website auf das Vorhandensein etwaiger Barrieren zu überprüfen. Das Tool lässt sich bequem per Bookmarklet auf jede Website anwenden und gibt einen Bericht mit Fehlern und Warnungen aus.

Barrierefreiheit gemäß WCAG und Section 508

Die „Web Content Accessibility Guidelines“ (WCAG) beinhalten Richtlinien für barrierefreie Webinhalte und stellen eine Empfehlung der „Web Accessibility Initiative“ (WAI) des W3C dar. Sie sind 2008 in der Version 2.0 verabschiedet worden. Die WCAG-Richtlinien besitzen unterschiedliche Konformitäten (A, AA und AAA), wobei A die niedrigste und AAA den höchsten Grad der Einhaltung der Richtlinien darstellt. Websites, welche die AAA-Konformität besitzen, erfüllen alle Richtlinien und weisen somit ein Höchstmaß an Barrierefreiheit auf.

Ein Beispiel: Bei der Richtlinie für „zeitbasierte Medien“ müssen Alternativen zu Audio- und Videoinhalten bereitgestellt werden. Während es bei Stufe A genügt, Untertitel zu integrieren, ist es für Stufe AA erforderlich, zusätzlich eine Audiodeskription zu hinterlegen. Bei Stufe AAA muss zudem eine Übersetzung in Gebärdensprache zur Verfügung gestellt werden.

Der HTML_CodeSniffer überprüft ein HTML-Dokument anhand der WCAG-Richtlinien. Dabei lässt sich die entsprechende Konformitätsstufe auswählen. Nach der Überprüfung gibt das Tool die Anzahl der Fehler, Warnungen und Hinweise aus. In einem ausführlichen Bericht liest man anschließend für jeden Fehler und jede Warnung nach, was nicht WCAG-konform ist.

Wer den HTML_CodeSniffer mal an einigen Webdokumenten ausprobiert, wird schnell feststellen, dass kaum eine Website alle Richtlinien erfüllt. Selbst die Übereinstimmung mit der kleinesten Stufe A ist eher selten gewährleistet. Wer also ein Maximum an Barrierefreiheit gewährleisten will, muss ordentlich nachbessern, selbst für das Minimum sind teils unfangreiche Nacharbeiten erforderlich.

Neben den WCAG-Richtlinien überprüft der HTML_CodeSniffer Inhalte auch auf der Grundlage der Section 508, einem Abschnitt des US-Behindertengleichstellungsgesetzes. Dieses stellt verbindliche Regeln für US-Bundesbehörden auf.

Überprüfung per Bookmarklet und per Direkteingabe

Der einfachste Weg, den HTML_CodeSniffer einzusetzen, ist die Verwendung als Bookmarklet. So kann jede aufgerufene Website per Klick geprüft werden. Alternativ besteht die Möglichkeit, HTML-Quelltext per Formular einzugeben und überprüfen zu lassen.

Auch bei direkter Eingabe des zu untersuchenden HTML-Codes werden Fehler, Warnungen und Hinweise sowie ein ausführlicher Bericht ausgegeben. Interessant ist die Direkteingabe wohl eher dann, wenn man lediglich bestimmte HTML-Auszeichnungen auf ihre Konformität hin überprüfen möchte; also in der Phase der Entwicklung einer Website.

Fazit: Der HTML_CodeSniffer ist ein sehr gutes Werkzeug, das Webdokumente sehr ausführlich testet und auf fehlende Barrierefreiheit hinweist. Und es zeigt, wie viel Arbeit ein barrierefreier Webauftritt macht. Möglicherweise kann das Tool Überzeugungsarbeit beim Kunden leisten, sind diese doch erfahrungsgemäß eher selten bereit, für Leistungen zu bezahlen, die man „nicht sehen“ kann. Die Verwendung des HTML_CodeSniffer ist übrigens kostenlos.

Barrierefreie Schriftarten – Individuelle Schriften für das Internet, weitgehend barrierefrei

Die Schriftenvielfalt auf Websites war früher sehr übersichtlich. Die Schnittmenge der Schriften, die auf weitestgehend allen Betriebssystemen vorinstalliert sind, ist gering. Wer nicht Gefahr laufen will, dass eine individuelle Hausschrift auf dem Ziel-Browser der Internetnutzer durch eine Standardschrift ersetzt wird und so das ganze, sorgfältig abgestimmte Design ruiniert, musste sich wohl oder übel mit Standardschriften wie Arial (Windows) oder Helvetica (Mac) begnügen.

Gerade die Verdana hat einen derartigen Siegeszug hinter sich, dass die mehrere Jahre als angenehme Abwechselung empfundene und äußerst gern eingesetzte Schrift inzwischen ebenso abgegriffen wirkt wie Arial oder Times New Roman. Das Problem ist bekannt und führte dazu, dass in den Anfängen der gestalteten Websites Überschriften und Navigationselemente gerne als Grafik eingebunden wurden. Im Zeitalter des barrierefreien Internets fällt diese Methode weg. So genannte Webfonts versprechen einen Ausweg aus diesem Dilemma.

In der jüngeren Vergangenheit haben sich verschiedene Möglichkeiten mehr oder weniger etabliert, um beliebige Schriften zumindest in Überschriften einsetzen zu können – und das möglichst barrierefrei. Dieser Beitrag beleuchtet drei der gängigen Ansätze mit ihren jeweiligen Vor- und Nachteilen nebst der rechtlichen Aspekte.

Das können sIFR und Cufon

Mit sIFR und Cufon gibt es zwei Lösungsansätze, um mehr Schriftenvielfalt auf Websites zu bringen. In beiden Fällen wird der Text ganz normal in HTML eingebunden und anschließend durch JavaScript ersetzt. Bei sIFR werden per JavaScript Textabsätze durch Flash-Dateien ersetzt. In diesen Flash-Dateien muss die entsprechende Schriftart eingebunden sein. Die Flash-Dateien geben den Text dann in der entsprechenden Schriftart wieder.

Cufon kommt ohne Flash aus. Die Schriftart, die eingsetzt werden soll, wird in einen sogenannten JavaScript-Font umgewandelt. Einen entsprechenden Generator stellt Cufon bereit. In dem JavaScript-Font werden die Buchstaben der Schrift als SVG-Grafiken gespeichert. Per JavaScript wird der Text dann durch die SVG-Buchstaben ersetzt.

Nachteile
Beide Lösungen haben den Nachteil, dass sie nur mit JavaScript funktionieren. Bei sIFR kommt noch hinzu, dass Flash eingesetzt wird, während bei Cufon die Texte anschließend nicht mehr markierbar sind.

Der Vorteil von Cufon ist, dass der Text auch ohne Flash und JavaScrript lesbar ist – gerade für barrierefreie Websites wichtig.

Vorsicht bei lizenpflichtigen Schriften
Zudem ist in beiden Fällen die Frage des rechtmäßigen Einsatzes von Schriften nicht geklärt. Denn kommerzielle Schriften dürfen schließlich nicht über das Internet verbreitet werden, was in beiden Fällen geschieht – wenn auch nicht als Schriftdatei, sondern im Flash- beziehungsweise SVG-Format.

Neue Möglichkeit mit @font-face

Eine neue Möglichkeit der Einbindung von Schriften ist der Einsatz spezieller Schriftdateien über Stylesheets. Diese Möglichkeit ist eigentlich gar keine neue, existiert sie in der Theorie doch schon eine ganze Weile. Aufgrund verschiedener Formate, mangelnder Browser-Unterstützung und fehlender Lizenzen durch die Schriftenanbieter konnte diese Möglichkeit bisher nicht eingesetzt werden. CSS3 hat die Eigenschaft @font-face wieder aufgegriffen, die inzwischen von fast allen Browsern unterstützt wird. Zudem gibt es mit dem FontShop den ersten Schriftenanbieter, der spezielle Lizenzen und Schriften für den Einsatz auf Websites anbietet.

Tipp: Welche CSS3-Properties von den gängigen Browsern unterstützt werden, können Sie in der Web Design Checklist nachlesen.

Wie funktioniert das?

Mit der neuen Technik lassen sich beliebige Schriften für die Texte einer Website einbinden. Die Schriften müssen nicht auf dem Rechner des Betrachters liegen, beziehungsweise installiert sein. Sie liegen auf dem Server der Website und werden vom Browser aufgerufen und verarbeitet. Wie so oft bei neuen Web-Technologien gibt es keinen einheitlichen Standard. Zwei verschiedene Dateiformate für die Web-Schriften sind momentan im Umlauf.

Da gibt es zum Einen das EOT-Format (»Embedded Open Type«), das der Internet Explorer schon seit Version 4 unterstützt, und das WOFF-Format (»Web Open Font Format«), das der Firefox seit Version 3.6 unterstützt. Erst durch das neue WOFF-Format, das von Mozilla mitentwickelt wurde, ist ein browserübergreifender Einsatz von Web-Schriften möglich geworden.

Der Schriftenanbieter FontShop liefert beide Formate aus, um so alle Browser versorgen zu können. Das für kommerzielle Schriftenanbieter Besondere an den Formaten ist, dass sie lediglich im Browser einsetzbar sind. Diese Schriften lassen sich nicht in anderen Programmen wie Office-Anwendungen verwenden.
Was gibt es Rechtliches zu beachten?

Die Vielfalt hat Ihren Preis – kommerzielle Schriften sind lizenzpflichtig

Um kommerzielle Schriften in den genannten Formaten auf einer Website einzusetzen, sind spezielle Lizenzen zu erwerben. Diese sind pro Schriftschnitt ab etwa 40 Euro erhältlich und enthalten die Schrift in beiden Formaten. Die Lizenz deckt 500.000 Seitenaufrufe pro Monat ab. Für alles, was darüber hinaus geht, gibt es gestaffelte Lizenzen, die entsprechend mehr kosten.

Da die tatsächlichen Seitenaufrufe einer Website nicht protokolliert werden, gibt der Lizenznehmer beim Kauf einer Schrift selbst an, wie hoch sein Traffic ist. Bei einer Website, die neu an den Start geht, wird der Traffic geschätzt.

Die Schrift darf nur vom Lizenznehmer auf einer bestimmten Website eingesetzt werden. Lizenznehmer sind daher verpflichtet, Maßnahmen zu treffen, das Hotlinking der Schriften zu unterbinden. Dies kann man unter anderem durch einen entsprechenden Eintrag in der .htaccess-Datei einrichten. Dafür kommen beide Formate ganz ohne DRM aus, was die meisten Webdesigner freuen wird, da man sich allerhand Probleme, die in der Regel mit DRM auftreten, erspart.

Es ist davon auszugehen, dass andere Schriftenanbieter, wie Linotype, nachziehen und ebenfalls eigene Schriften und Lizenzmodelle für Webschriften anbieten. Auch die Browser-Hersteller werden nachziehen. Und möglicherweise wird auch der nächste Internet Explorer das WOFF-Format unterstützen, sodass es zukünftig nur noch ein Format für alle Browser geben wird.

Wie binde ich die Schriften ein?

Das Einbinden der Web-Schriften erfolgt über CSS. Aufgrund der unterschiedlichen Formate muss die Schrift zweimal eingebunden werden, damit sowohl der Internet Explorer als auch Firefox die Schrift anwenden können:

/* erst für den Internet Explorer */
@font-face {
font-family: MeineSchrift;
src: url("/schriften/MeineSchrift.eot");
}

/* dann für Firefox */
@font-face {
font-family: MeineSchrift;
src: url("/schriften/MeineSchrift.woff") format("woff");
}

Anschließend kann die Schrift wie jede andere Systemschrift verwendet werden:

p {
font-family: MeineSchrift, Arial
}

Für ältere Browser sollte man, wie im Beispiel geschehen, eine alternative Systemschrift angeben. Es lassen sich auch spezielle Schriftsstile definieren, die anschließend verwendet werden können:

@font-face {
font-family: MeineSchrift;
src: url("/schriften/MeineSchriftItalic.woff") format("woff");
font-style: italic;
}

Im dargestellten Beispiel wird ein Kursivschnitt der Schrift unter dem Namen »MeineSchrift« eingebunden. Dieser lässt sich jetzt ebenfalls wie andere Systemschriften anwenden:

em {
font-family: MeineSchrift, Arial
font-style: italic;
}

Die Definiton verschiedener Schriftstile einer Schrift wird nur vom WOFF-Format unterstützt. Beim EOT-Format bleibt nur die Möglichkeit, für jeden Schriftschnitt eine eigene Schriftdefintion anzulegen:

@font-face {
font-family: MeineSchriftItalic;
src: url("/schriften/MeineSchriftItalic.eot");
}

Was gilt es noch zu beachten?

Die Webschriften sind für die Bildschirmdarstellung mit eingeschaltetem ClearType optimiert. ClearType ist erst ab Windows Vista standardmäßig eingeschaltet. Werden andere Schriftenglättungsmethoden eingesetzt, sind die Webschriften nicht optimal lesbar. Wie die verschiedenen Betriebssysteme und Schriftenglättungsmethoden sich auf die Darstellung der Schrift auswirken, verdeutlichen einige Screenshots bei Flickr.

Wer Schriftlizenzen nicht erwerben möchte, kann auch den Service von Typekit verwenden. Hier hat man je nach gewähltem Tarif Zugriff auf hunderte verschiedener Schriften. Allerdings setzt die Nutzung JavaScript voraus, da ein Tracking-Code auf der Website eingebunden werden muss.

Wo werden Webfonts eingesetzt?

Es gibt bisher nur wenige Websites, die sich der neuen Technik bedienen, dazu gehören Intersport, Nike und Jax Vineyards (Screenshot siehe oben). Ob sich die neue Schriftenvielfalt durchsetzen wird, ist aufgrund der neuesten Entwicklung keine Frage mangelnder Unterstützung der Browser und Schriftenhersteller. Entscheidender für die Durchsetzung ist die Frage, ob Betreiber von Websites bereit sind, zusätzliches Geld für Schriften auszugeben, die nur auf der Website einsetzbar sind.

Barrierefreie Navigation

Irgendwie barrierfrei sind sie alle – aber worauf kommt es wirklich an bei der barriefreien Navigation? Wir kümmern uns um die Details und basteln ein nach allen Regeln der Kunst vorschriftsmäßiges Menü mit Aufroll-Effekt – ohne Java-Script.

Das attraktive Rollmenü geht kategorisch vor, Untermenüs rollt es erst bei Bedarf aus. Es ist platzsparend und bestens geeignet für die geordnete, wohlstrukturierte Darbietung. Unsichtbar unter der Oberfläche verborgen, bauen wir die Funktionen ein, mit denen auch Screenreader und Co. den Auftritt nicht verpassen.

Ein Menu, das auch der Screenreader versteht

Live Demo im neuen Fenster: Barrierefreies Rollmenü

Als gültige Richtlinien für Barriefreiheit orientieren wir uns an der WCAG 2.0 (Web Content Accessibility Guidelines) und der BITV (Barrierefreie Informationstechnik-Verordnung).

HTML-Quelltext

<a id="skiplink" href="#inhalt">Navigation
  &uuml;berspringen</a>

<div id="nav"> 
<ul class="liste"> 
<li><a class="hier" href="#">Rubrik eins</a>
 
  <ul class="sub">
 
    <li><a href="nav-1a.html">eins
a</a></li>
 
    <li><a href="nav-1b.html">eins
b</a></li>
 
    <li><a href="nav-1c.html">eins
c</a></li>
 
  </ul> 
</li> 
<li><a href="nav-2.html">Rubrik zwei</a></li> 
<li><a href="nav-3.html">Rubrik drei</a></li> 
<li><a href="nav-4.html">Rubrik vier</a></li> 
</ul> 
</div>

<a name="inhalt"></a>

Wir fügen als erstes einen Link ein, dessen einziges Ziel es ist, die Navigation überspringen zu können, um direkt zum Inhalt zu gelangen. Wer am Screenreader oder an sonstigen Hilfsgeräten sitzt, möchte sich nicht auf jeder Seite wieder durch sämtliche Menüpunkte hangeln müssen. Auf dem Bildschirm machen wir den Skiplink später mit CSS unsichtbar.

Beliebtes Grundgerüst so gut wie jeder modernen Navigation ist eine Ungeordnete Liste <ul>. Untermenüpunkte bauen wir in das <li> der übergeordneten Hauptrubrik ein. Das Geheimnis dynamisch ausgerollter Untermenüs ohne Skript-Unterstützung ist, dass wir die Unterpunkte gar nicht verstecken, sondern mit der Seite verlinken, auf der sie sichtbar sind. Profis erkennen den Trick daran, dass zum Ausrollen immer ein Klick nötig ist – hovern reicht nicht!

Im Quelltext oben bauen wir die Navigation mit ausgerolltem Untermenü für die Rubrik eins zusammen. Die Konstruktion der anderen Ebenen erfolgt analog. Die Haupt-<ul> erhält class=“liste“, der Unter-<ul> geben wir class=“sub“. Der Link zum Menüpunkt der aktuellen Seite erhält class=“hier“, und für den Fall, dass die aktuelle Seite ein Untermenüpunkt ist, halten wir class=“hier2″ für den übergeordneten Hauptmenüpunkt bereit.

CSS-Code

html, body, ul { margin: 0; padding: 0; } 

#nav { width: 8em; margin: 2px ; } 

#nav a { width: 100%; display: block; } 

ul { list-style-type: none; } 

ul.liste li { margin: 1px 0; } 

ul.sub li { margin-right: 12px; } 

Wir bereiten das Spielfeld vor, setzen Standardwerte auf Null und bestimmen die Breite der Navigation. Eine Bedingung für Barrierefreiheit sind frei skalierbare Schiften. Mit der Größenangabe in em (width= 8em) setzten wir die Breite in Beziehung zur im Browser eingestellten Schriftgröße. Das ist sehr praktisch, die Navigationsleiste wächst mit.

Dank #nav a { width: 100%; display: block; } können wir die Links schön übereinanderstapeln, gleichzeitig machen wir sie auf ganzer Breite klickempfindlich. Die Standard-Aufzählungszeichen von <ul> schalten wir ab (list-style-type: none). Die Menüpunkte rücken wir mit einem Pixel padding oben und unten etwas auseinander (margin: 1px 0;). Die Erklärung für mysteriöse 12px margin ( margin-right: 12px;) findet sich weiter unten.

 ul.liste a { 
  padding: 10px 0 10px 16px;
 
  background-color: #009FFF;
 
  border-left: 6px solid #000080;
 
  color: #fff;
 
  font-family: Arial, Helvetica, sans-serif;
 
  text-decoration: none; } 

ul.sub a { 
  padding-left: 28px;
 
  background-color: #fff;
 
  border-left: 6px solid #AADFFF;
 
  color: #000;
 
  font-style: italic; } 

ul.liste a:hover { 
  background-color: #AADFFF;
 
  text-decoration: underline; } 

ul.sub a:hover { background-color: #fff; } 

10px padding oben und unten sorgen für die richtige Höhe, mit 16px padding links schieben wir den Linktext etwas vom Rand weg. Bleiben noch Hintergrundfarbe (#009FFF), Rahmenbalken links in #000080, Schriftart (Arial, Helvetica oder Sans-Serif), Schriftfarbe (#FFF) und das Abschalten der Standard-Link-Unterstreichungen mit text-decoration: none.

Die Links im Untermenü rücken wir einen Tick weiter ein (padding-left: 28px), verändern die Farben und setzen die Schrift auf italic. Aus der Differenz zwischen dem padding (28px) und dem Abstand, um den wir die Links vom Rand weggerückt haben (16px), ergeben sich die 28px-16px=12px margin, um die wir oben die <li> im Untermenü gekürzt haben. Die Einträge würden sonst 12px an der Seite überstehen.

Gleiches Spiel mit dem :hover-Zustand, neue Hintergrundfarben – getrennt für Hauptrubrik (#AADFFF) und Untermenü (#FFF) – und stilsichere Wiederbelebung der Linkunterstreichung beim hovern im Untermenü.

ul.liste a.hier { 
  background-color: #AADFFF;
 
  border-left: 6px solid #ff0000;
 
  color: #ff0000; } 

ul.sub a.hier { background-color: #fff; } 

ul.liste a:hover.hier { text-decoration: none; } 

ul.liste a.hier2 { 
  background-color: #AADFFF;
 
  border-left: 6px solid #000080;
 
  color: #000; } 

a#skiplink { 
  position: absolute;
 
  left: 0px; top: -500px;
 
  width: 1px; height: 1px;
 
  overflow: hidden; }

Abschließend noch das Finetuning der Anzeige der aktuellen Seite im Menü. Wir haben einen ausgewählten Hauptmenüpunkt (ul.liste a.hier), einen ausgewählten Unterpunkt (ul.sub a.hier) mit dazugehöriger Rubrik (ul.liste a.hier2) und den aktuellen Hauptmenüpunkt beim hovern (ul.liste a:hover.hier), die wir alle getrennt mit Farben, Rahmen und Textdekoration ausstatten.

Die sicherste Möglichkeit den Skiplink so zu formatieren, dass er von Hilfsgeräten erkannt, nicht aber auf dem Bildschirm angezeigt wird, ist es, ihn oben aus dem dargestellten Bereich hinauszuschieben (position: absolute; left: 0px; top: -500px;), auf die Größe von einem Pixel zu reduzieren (width: 1px; height: 1px;) und überlaufenden Inhalt zu verstecken (overflow: hidden;).

Lesegeräte müssen wissen, in welcher Sprache ein Dokument vorgelesen werden soll. Die Angabe dazu gehört in die HTML-Deklaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="de">

Bei der Auswahl der Faben ist auf ausreichenden Kontrast zu achten. Spezielle Farbkombination, die Farbblinde nicht gut unterschieden können, beispielsweise rot und grün sollte man meiden. Die im Beispiel gewählten Farben sind akzeptabel, wer hier ganz auf Nummer sicher gehen will, sollte den Kontrast zwischen Hintergrund- und Texfarbe der Hauptmenüpunkte noch erhöhen.

Wichtig ist, dass die Navigation auch ohne optische Kennzeichnungen verständlich ist. Wenn die Linkbeschriftung alleine nicht ausreicht, um zu beschreiben, worum es geht, sollte der title-Tag zusätzliche Angaben enthalten.

Je nach Einbauart des Menüs sollte auf der Seite noch ein Link zurück zur Startseite angebracht oder ein entsprechender Menüpunkt eingerichtet werden.

Beispiele zum Download

Getestete Browser: IE 6.0, 7 Beta 3, Firefox, Mozilla, Opera ab 7.1, Netscape ab 7.2.

<pcss-menue-8.php]]} –> <paugenerkrankungen.shtml]]} –>

Frames – Ein altes Übel

Die BITV – die Barrierefreie Informationstechnik Verordnung – für das barrierefreie Internet gibt Richtlinien, die größtenteils vom „guten Webdesigner“ seit eh und je beachtet werden.  Auf Feinheiten gilt es trotzdem zu achten.

Leider haben die Sprachausgabeprogramme große Probleme mit der Wiedergabe von Webseiten mit Frames. Je nach System werden die Inhalte gar nicht oder nur teilweise wiedergegeben. Das <noframes>–Element steht jedem zur Verfügung, aber dort nochmals die gesamte Website ohne Frames zu hinterlegen ist sehr aufwändig. Kein Kunde wird das bezahlen wollen. Man muss aber bedenken, dass die für den sehenden Besucher problemlose Orientierung beim Blinden nicht gegeben ist.

Frames werden oft ohne Sinn benannt. Häufig nur mit „frame_links“ und „frame_rechts“ betitelt geben sie keine Auskunft über den wahren Inhalt. Die Benennung der Frames sollte also den Sinn und Zweck der einzelnen Frames wiedergeben. Wer nicht auf Frames verzichten will oder kann, sollte das beherzigen und einen Frame zum Beispiel „Navigation“, den anderen „Inhalt“ nennen. Besser ist der komplette Verzicht auf diese Technik.

Usability oder die Gebrauchstauglichkeit

Zum Thema Usability sagt die Verordnung: „Navigationsmechanismen sind übersichtlich und schlüssig zu gestalten“ und „Das Ziel jedes Hyperlinks muss auf eindeutige Weise identifizierbar sein“. Das bedeutet, dass jeder Link auch ohne Zusammenhang eine eindeutige Aussage zum Ziel haben muss. Manche Brower fassen auf Wunsch die Links einer Seite zusammen. Diese Orientierungshilfe ist dahin, wenn ein Link nicht eindeutig benannt wurde. Mit dem title–Attribut können weitere Informationen zum Ziel übermittelt werden.

Weiterhin sagt die Verordnung, dass, wenn inhaltlich zusammenhängende Dokumente getrennt angeboten werden, Zusammenstellungen dieser Dokumente bereitzustellen sind. Wenn eine HTML-Seite also eine Folge aus einer Serie ist (etwa Seite 2 von 4), sollte die Hierarchie dieser Serie mit Link Relations abgebildet werden. Die Tags dazu sind <link rel=“start“>, <link rel=“previous“>, <link rel=“next“> und <link rel=“last“>. Diese Daten können aber auch Verweise auf ein Glossar, ein Inhaltsverzeichnis, eine Suchfunktion oder auch eine Hilfe–Seite sein.

Die Bestimmung aus der Verordnung:, „Es sind Informationen zur allgemeinen Anordnung und Konzeption eines Internetangebots, z.B. mittels eines Inhaltsverzeichnisses oder einer Sitemap, bereitzustellen“ ist klar. Ein Inhaltsverzeichnis oder eine Sitemap sollte bei größeren Projekten eh zum Standard gehören. Genauso eine Suchfunktion mit simpler Volltextsuche und zusätzlich einer Komfortsuche sowie „schlüssig und nachvollziehbare Navigationselemente“.

Kompatibilität zum Screenreader

In der BITV steht dazu: „Das Erscheinenlassen von Pop-Ups oder anderen Fenstern ist zu vermeiden. Die Nutzerin, der Nutzer ist über Wechsel der aktuellen Ansicht zu informieren“. Das unerwünschte Öffnen von Pop–Up–Fenstern ist beim Internetsurfer nicht sonderlich beliebt. Auch Links, die Inhalte im neuen Browserfenster öffnen, sollten vermieden werden. Bei sich automatisch öffnenden Fenstern kommt es zu dem Problem, dass die Ansicht sich unaufgefordert ändert. So wird der Clickstream unterbrochen. Die History des Browsers ist wertlos und es gibt kein „zurück“.

Die folgende Regel ist leicht zu verstehen: Man soll „bei allen Formular-Kontrollelementen mit zugeordneten Beschriftungen Sorge tragen, dass die Beschriftungen korrekt positioniert sind und „genau ihren Kontrollelementen zugeordnet werden können“.

„Nebeneinanderliegende Hyperlinks sind durch von Leerzeichen umgebene, druckbare Zeichen zu trennen“. Screenreader haben die unangenehme Eigenschaft, bei langen Wortfolgen ohne Punkt und Komma in der Satzmelodie abzufallen, was nicht gerade zum Hörgenuss führt. Druckbar heißt, dass Zeichen aus dem verwendeten Zeichensatz genutzt werden müssen, also keine Leerzeichen wie „nbsp;“ oder gar Spacer-GIFs. Hier hat sich das Pipe–Zeichen ( | ), umgeben von jeweils einem Leerzeichen durchgesetzt.

Orientierung

Das Frames eindeutig zu benennen sind, wurde weiter oben schon erwähnt. Weiterhin verlangt die Verordnung, dass inhaltlich verwandte oder zusammenhängende Hyperlinks zu gruppieren sind. Die Gruppen sind eindeutig zu benennen und müssen einen Mechanismus enthalten, der das Umgehen der Gruppe ermöglicht“. So sollen alternative Ausgabemedien die Möglichkeit bekommen, den Surfer bei der Navigation in nicht–grafischen Umgebungen zu unterstützen.

Bei der Sprachausgabe fehlt der visuelle Kontext, was bedeutet, dass eben nicht so einfach von Textblock zu Textblock gesprungen werden kann. Nicht jeder will alles lesen müssen, deshalb ist es sinnvoll, Blöcke mit einem Verweis innerhalb der Seite überspringbar zu machen. Dies geschieht über lokale Anker wie <a href=“#inhalt>, die auf eine Stelle der gleichen Seite mit einer ID (etwa <div id=“zweitespalte“>) verweist. Dies sind genau die ID’s, die man auch zum Wiedererkennen von Blöcken einsetzt, um per CSS Stile zuweisen zu können. Zwei Fliegen mit einer Klappe, sozusagen.

Auch wenn die Verordnung die Gleichstellung von Behinderten zum Ziel hat: Sie bringt Vorteile – für jeden Menschen.

Fazit: Alles paletti!

Wer alles richtig machen will, hat bei der Gestaltung und Umsetzung viel Arbeit vor sich. Alle Tests zu bestehen, dürfte schwierig bis unmöglich sein – gerade bei gestalterisch aufwändigen und inhaltlich komplexen Websites. Aber die hier vorgestellten Dienste sind ein guter Anhaltspunkt, um Schwachstellen festzustellen und zumindest grobe Fehler auszumerzen, beziehungsweise zu vermeiden.