Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Schnelltest zur Barrierefreiheit

Schnelltest zur Barrierefreiheit

Tests auf Barrierefreiheit sind umfangreiche Unterfangen. Nicht immer ist so viel Zeit und je nach Situation geht es erstmal nur um eine grobe Einschätzung. Kerstin Probiesch stellt einen Schnelltest vor, der weitgehend mit Bordmitteln durchgeführt werden kann.

Nicht immer und nicht immer sofort wollen Anbieter oder Projektleiter einen ausführlichen Test der Barrierefreiheit beauftragen, geschweige denn selber durchführen. Manche wollen »erstmal sehen«, wo ihr Webangebot steht, ob sich ein ausführlicher Test auf Konformität mit den Web Content Accessibility Guidelines 2.0 (WCAG 2.0) »überhaupt lohnt« oder der beste nächste Schritt ist. Dabei geht es vor allem um die Frage nach dem ersten Eindruck. Gestellt wird sie in den unterschiedlichsten Situationen: am Telefon, auf Tagungen oder bei einem Erstgespräch. In diesen Situationen steht dem Ideal einer ausführlichen Analyse die mangelnde Zeit gegenüber. Und: Nicht immer ist es der Barrierefreiheitsprofi, der sich oder dem Fragesteller einen ersten Eindruck verschafft. Projektleiter, Anbieter und Entscheider benötigen einfache Werkzeuge und schnelle Tests, z.B. um mit dem Ergebnis der beauftragten Webagentur auf die Finger zu klopfen oder ein Projekt in die richtige barrierefreie Richtung zu lenken.

Nur: was sind sie, die wesentlichen Barrieren? Wie »schnell« ist schnell und welche Barrieren können unter den oben skizzierten Rahmenbedingungen in kurzer Zeit und hauptsächlich mit Bordmitteln festgestellt werden?

Überlegungen

Eine Antwort auf die Frage nach »wesentlichen Barrieren« zu finden, hört sich zunächst leicht an. Tatsächlich hängt die Ermittlung »wesentlicher Barrieren« von unterschiedlichen Perspektiven ab. Während blinde Surfer fehlende Alternativtexte als wesentlich bezeichnen würden, sind diese für sehende Tastaturbenutzer weder eine wesentliche, noch überhaupt eine Barriere. Für beide Nutzergruppen gilt jedoch, dass eine fehlende Tastaturbedienbarkeit eine wesentliche Barriere ist; für unseren geplanten Schnelltest gilt: sie kann mit Bordmitteln geprüft werden. Damit hätten wir den ersten Prüfschritt identifiziert, dem wir aus rein pragmatischen und zudem leicht testbaren Erwägungen heraus noch den sichtbaren Fokus beifügen.

Natürlich ließe sich die Frage nach den »wesentlichen Barrieren« auch auf der Basis von Richtlinien und Verordnungen beantworten. So könnten auf Basis der WCAG 2.0 alle Erfolgskriterien der Konformitätsstufe A herangezogen und daraus ein Schnelltest gestrickt werden. Bereits beim ersten Erfolgskriterium ergäben sich jedoch erste Probleme: Alternativtexte können meist weder gerade »mal eben« getestet, noch in einem direkten kurzen Gespräch schnell erklärt werden. Ihre Bewertung ist zudem abhängig von reichlich Know-how und Testpraxis. Eines jedoch geht schnell: Browser und Betriebssystem in den Kontrastmodus schicken und testen, ob Grafiken über CSS eingebunden sind. Solcherart eingebundene Grafiken verschwinden bei benutzerdefinierten Bildschirmeinstellungen. Handelt es sich um reine Layoutgrafiken ist das natürlich unproblematisch; bei informativen Grafiken dagegen entstehen für mehrere Nutzergruppen Probleme: Zwar können blinde Nutzer bei einem vorhandenen Text im title-Attribut den Sinn und Zweck der Grafik erfahren. Ist jemand jedoch mit eigenen Bildschirmeinstellungen im Web unterwegs, wird das Auffinden solcher Grafiken zur Glückssache und sehenden Tastaturbenutzern ist der Inhalt des title-Attributs ohne JavaScript nicht zugänglich. Damit hätten wir einen weiteren Prüfschritt identifiziert, der jedoch eine zumindest kurze Sichtung der Seite voraussetzt. Er eignet sich also nicht als zweiter Prüfschritt.

Soweit einige Überlegungen, die für diesen Schnelltest eine Rolle spielten. Weitere waren: Der Test sollte zumindest nach kurzer Übungsphase nicht länger als eine halbe Stunde dauern und die Bordmittel von Browser und Betriebssystem sollten, abgesehen von maximal einem kostenlosen und leicht installierbaren Prüftool, genügen. Natürlich stellte sich die Frage nach der Anzahl der Testschritte ebenso wie die Frage, ob und welche Kriterien verschiedener Konformitätsstufen zusammengelegt werden können?

Herausgekommen ist ein Test mit fünf plus einem optionalen Prüfschritten, der unter Windows mit Firefox und Internet Explorer, der Erweiterung HeadingsMap für Firefox und in ca. 30 Minuten durchgeführt werden kann. Natürlich sollen weder Ergebnis noch Test den Eindruck erwecken, dass schon alles getan sei. Der Schwerpunkt liegt zudem nicht auf das Abarbeiten einer Checkliste, wenngleich sich natürlich eine solche erstellen ließe.

Schnelltest V. 0.1

Sind die Browser geöffnet und die HeadingsMap installiert, dann öffnet die Startseite des zu testenden Webangebots sowohl im Internet Explorer als auch im Firefox. Zwischen beiden Browsern könnt ihr bequem mit der Tastenkombination Alt+Tab wechseln. Nach Aktivierung der HeadingsMap wechselt zunächst in den Internet Explorer. Dies mag ungewöhnlich sein, dient – so die Überlegung – jedoch dazu, dass bereits hier ein erster Eindruck gewonnen werden kann, denn die HeadingsMap zeigt sofort die Überschriftenstruktur der Seite an.

Schritt 1: Tastaturbedienbarkeit

Navigiert mit der Tabulatortaste durch die Seite. Entspricht die Tabreihenfolge der sichtbaren Anordnung der Inhalte? Wisst ihr beim Durchtabben durch einen Farbwechsel oder andere sichtbare Merkmale immer, wo ihr euch befindet? Falls Videos vorhanden sind: Könnt ihr diese mit der Tastatur ansteuern, bedienen (z.B. Starten und Stoppen) und verlassen? Wechselt in den Firefox und wiederholt diesen Schritt. Achtet dabei sowohl auf Links zur Kontaktseite sowie zur Suche bzw. erweiterten Suche und auf grafische Links. Diese werden in weiteren Schritten geprüft.

Schritt 2: label-Elemente korrekt verwendet

Bleibt im Firefox und ruft – sofern vorhanden – die erweiterte Suche und/oder und ein Kontaktformular auf. Klickt auf die Beschriftungen von Eingabefeldern, Radiobuttons und Checkboxen. Springt der Fokus in das zugehörige Eingabefeld, werden Radiobuttons oder Checkboxen aktiviert? In diesem Fall sind die Beschriftungen korrekt mit den Formularelementen verknüpft und können von Screenreadern ausgewertet werden.

Schritt 3: Aussagekräftige Seitentitel

Bleibt im Firefox und schaut euch die/den Seitentitel der Formularseite/n an. Sind Angaben zum Webangebot sowie zur aufgerufenen Webseite enthalten? Ruft eine weitere Seite aus der Hauptnavigation heraus auf und vergleicht Seiteninhalt mit Seitentitel. Wisst ihr anhand des Seitentitels, worum es auf der Webseite geht?

Schritt 4: Überschriften

Schaut euch nun die Einträge in der HeadingsMap an. Sie enthält alle Überschriften, die mit dem H-Element ausgezeichnet sind. Sie können von Screenreadern ausgewertet und von blinden Nutzern über die H-Taste direkt angesprungen werden. Gleicht die Einträge in der HeadingsMap mit eurem visuellen Eindruck von der Webseite ab. Enthält die HeadingsMap alle Überschriften und Zwischenüberschriften und sind sie für sich gelesen aussagekräftig?

Wenn ihr an das Inhaltsverzeichnis eines Buches denkt: Ist die Gliederung des Dokuments logisch oder werden Ebenen übersprungen? Ist euch bereits bei den ersten drei Prüfschritten aufgefallen, dass Einträge rot hinterlegt sind? Diese Hinterlegungen kennzeichnen ausgelassene Ebenen, die zusätzlich an den Nummern der Einträge erkennbar sind.

Ruft die bisher besuchten Seiten auf, bis ihr euch wieder auf der Startseite befindet und gleicht jeweils die Seiteninhalte mit den Einträgen in der HeadingsMap ab.

Schritt 5: Informative Grafiken sichtbar

Durch die ersten vier Prüfschritte haben wir nun einen recht guten Eindruck von den bisher getesteten Seiten. Im ersten Schritt haben wir zudem bereits etwaige grafische Links identifiziert. Diese sind Thema des letzten Schrittes unseres Schnelltests. Dabei gilt: grafische Links sind immer informativ und benötigen ein alt-Attribut. Ist dieses vorhanden, dann ist die Grafik auch im Kontrastmodus immer sichtbar. Bevor ihr den Kontrastmodus mit linkeALT+linkeUMSCHALT+DRUCK aktiviert, wechselt in den Internet Explorer.

Sind grafische Links und andere informative Grafiken noch sichtbar (z.B. Logos, verlinkte Teaserbilder, als Schriftgrafiken ausgeführte Navigationseinträge)? Ist auch das Eingabefeld einer vorhandenen Suche sichtbar? Wechselt zu einer der im zweiten Schritt ausgewählten Formularseiten. Sind die Eingabefelder, Radiobuttons und Checkboxen sichtbar oder begegnet euch nur eine schwarze Fläche? Deaktiviert den Kontrastmodus mit der oben genannten Tastenkombination wieder.

Je nach Rahmenbedingung kann diesem Prüfschritt ein sechster folgen, der ebenfalls mit Bordmitteln getestet werden kann. Dieser eignet sich auch, wenn weder die Installation der HeadingsMap, noch die Installation eines Bookmarklets möglich ist. Selbstverständlich spricht nichts dagegen, im Anschluss Alternativtexte zu testen; die ersten Informationen wurden bereits im fünften Prüfschritt gewonnen. Seid ihr jedoch kein Barrierefreiheitsprofi und habt wenig Erfahrung mit der Bewertung von Alternativtexten, dann ist der folgende Schritt eine sinnvolle Ergänzung.

Optionaler Schritt 6: Bei Zoom auf 200% lesbar

Vergrößert die aufgerufene Seite mit dem Page Zoom auf 200%, indem ihr vier Mal die Tastenkombination Strg und + drückt oder die Zoomfunktion (unten rechts) verwendet.

Sind noch alle Texte leserlich oder werden einzelne Texte von anderen Inhalten überlagert? Schreibt einen kurzen Text in ein Eingabefeld. Könnt ihr diesen problemlos lesen oder wird er oben oder unten abgeschnitten? Achtet auch auf die Einträge in Haupt- und Unternavigationen. Ruft anschließend die Startseite auf und prüft, ob ihr auch hier alle Texte problemlos lesen könnt.

Dokumentation und Grenzen

Auf einer Tagung oder am Telefon wird die Vermittlung der Ergebnisse sicherlich während des Schnelltests, zumindest aber mündlich, erfolgen. Projektleiter sollten Probleme schriftlich dokumentieren, wobei je nach Übung und Qualität der Webseiten eine halbe Stunde möglicherweise nicht ausreicht. Eine Dokumentation sollte dabei so genau wie formuliert werden und in die Projektdokumentation integriert werden.

Nicht geeignet ist der Schnelltest für das Bezeugen einer Konformität nach WCAG 2.0 oder anderen Richtlinien bzw. Verordnungen. Das gilt sowohl für den Fall, dass keine Probleme gefunden werden als auch für den Fall, dass die mit diesem Schnelltest gefundenen Barrieren behoben werden.

Hinweis: Der vorgestellte Schnelltest kann frei verwendet und nach eigenen Bedürfnissen abgewandelt, jedoch nicht für kommerzielle Zwecke als Produkt oder spezielle Dienstleistung angeboten werden.

Kommentare

Peter
am 15.12.2011 - 11:11

Bei mir hat sich die Web Developer Toolbar für den FF im mobilen Einsatz beim Kunden oder Interessenten vor Ort bewährt. Sie läßt sich auch beim FF-portable installieren und steht somit kundenunabhängig von USB-Stick oder ext. HDD zur Verfügung

Die Toolbar bringt viele nützliche Testmöglichkeiten mit, um grundlegende Schwachstellen aufzuzeigen, ohne gleich in tiefschürfende Analysen abdriften zu müssen.

Permanenter Link

Grischa
am 15.12.2011 - 20:43

Interessant, dass ein Artikel zur Barrierefreiheit auf dem mobilen Android Browser unmöglich zu lesen ist..
.. vielleicht war das ja mit Barrierefreiheit nicht gemeint. Ich weiß es nicht, konnte es ja nicht lesen. ;)

Permanenter Link

peter
am 16.12.2011 - 10:49

@Grischa
Mit meinem Ace von Samsung (2.3.5 Gingerbread) gibts keine Probleme. Auch mit dem Formular nicht...

(send by smartphone)//

Permanenter Link

Kerstin Probiesch
am 16.12.2011 - 11:43

Hallo Peter,

danke für den Kommentar. Natürlich gilt; mehr geht immer und es hängt sehr von der Situation ab, was dieses "mehr" ist. Ich stimme Dir natürlich zu: bei Terminen vor Ort (meist wird da mehr Zeit sein) und wenn der Prüfer erfahren ist, dann kann und sollte mehr geprüft werden. Bei solchen Terminen hat man meist schon im Vorfeld die Möglichkeit, sich eine Website kurz anzuschauen.

Permanenter Link

André Olejko
am 20.12.2011 - 18:38

Kleine Korrektur: die "title"-Attribute sind auch ohne Javascript zugänglich.

Permanenter Link

suit
am 21.12.2011 - 19:20

"Bevor ihr den Kontrastmodus mit linkeALT+linkeUMSCHALT+DRUCK aktiviert, wechselt in den Internet Explorer."

Gibt es auf einem Standard 101-Tasten-Keyboard eine "rechteALT" auch?

Und warum in den Internet Explorer wechseln - der Kontrast wird Betriebssystemweit verstellt und haut einem das aktuelle Design über den haufen. Sehr schlau.

Warum nicht einfach ein Hochkontrast-Stylesheet verwenden, welches dasselbe bezeckt?

Derlei Tests sind mit Opera übrigens auch recht zügig durchführbar, ohne extra lästige Add-Ons installieren zu müssen oder seine GUI-Konfiguration unter Windows zu schrotten.

Permanenter Link

Peter
am 22.12.2011 - 08:16

Stimmt - funktioniert natürlich auch mit dem Firefox.

Ergänzung: Beim Test der Links sollten nicht nur die grafischen Links Beachtung finden, sondern auch die Text-Links.

#00e auf #000, oder #551a8b auf #000 erfüllen die Kontrastforderung nicht ;-)

Permanenter Link

Die Kommentare sind geschlossen.