Webstandards
Kommentare 5

Die Evaluierung von Webseitenzugänglichkeit: Teil 3, Das Nachhaken

Dieser Artikel ist eine Übersetzung des Artikels “Evaluating Website Accessibility Part 3, Digging Deeper” von Roger Johansson. Alle Rechte am Artikel bleiben beim Autoren. Für weitere Informationen und Artikel zum Thema Webstandards besuchen Sie seine Seite 456 Berea Street.
Im Artikel “Die Evaluierung von Webseitenzugänglichkeit Teil 1, Hintergrund und Vorbereitung” (deutsche Übersetzung) habe ich Hintergrundinformationen gegeben und einige nützliche Tools für die Evaluierung von Zugänglichkeit bereitgestellt. Im zweiten Teil der Serie, “Die Evaluierung von Webseitenzugänglichekti Teil 2, Grundlegende Prüfschritte” (deutsche Übersetzung) habe ich Aspekte betrachtet, die sowohl mit automatischen Tools als auch in manuellen Überprüfungen getestet werden können.

Im abschießenden Teil dieser Serie werde ich Gesichtspunkte von Webseitenzugänglichkeit betrachten, die nur schwer mit automatischen Programmen getestet werden können und mehr Zeit und/oder Erfahrung benötigen, um manuell getestet zu werden. Einige dieser Prüfschritte setzen voraus, dass Sie die ersten Artikel gelesen haben. Falls Sie dies nicht getan haben, lese Sie die Artikel ehe Sie mit diesem Artikel fortfahren.

Dieser Artikel enthält folgende Prüfschritte:

  1. Farbkontrast
  2. Dokumenttitel
  3. Linktext
  4. Non-HTML-Formate
  5. Plattformausgrenzung
  6. Navigation mit der Tastatur
  7. Datentabellen
  8. Bedienelemente und Kennzeichnung von Formularen
  9. Benutzen Sie einen Screenreader

1. Farbkontrast

Ein einfacher Weg, zu testen, ob der Unterschied von Farbton und Helligkeit zwischen Vorder- und Hintergrund groß genug ist, ist Jonathan Snooks exzellenter Color Contrast Checker. Entweder geben Sie den Hexidezimalwert für Vorder- und Hintergrundfarbe ein oder schieben die Regler, um eine direkte Rückmeldung über Kontrast und Farbdifferenz zu bekommen.

Gez Lemons Colour Contrast Analyser ist ähnliches Tools, das außerdem als Firefox-Erweiterung erhältlich ist.

Beide Hilfsmittel benutzen einen Algorithmus, der vom W3C bereitgestellt wurde, um die Sichtbarkeit von Farben zu berechnen.

Sie können auch Ihren Monitor auf Graustufen oder monochrom umstellen, um sicherzustellen, dass der Text immer lesbar ist. Wenn Sie Mac OS X benutzen, können Sie die Einstellungen unter “Universal Access” ändern. So können Sie Farben umkehren, den Bildschirm auf Graustufen oder monochrom stellen und den Kontrast verändern. Falls Sie ähnliche Tools für andere Betriebssysteme kennen, können Sie einen Kommentar hinterlassen.

Warum? Wenn der Unterschied von Farbton und Helligkeit zwischen Vorder- und Hintergrundfarben nicht groß genug ist, können viele Besucher den Text nur schwer lesen. Dies kann an Farbfehlsichtigkeit oder einem Monochrom- oder Graustufenbildschirm liegen. Oder sie haben, wie ich, ein perfektes Sehvermögen, einen wirklich guten Monitor, der 24-bit Farben darstellt, und trotzdem Probleme, da die Seite einen hellgrauen Text auf weißem Hintergrund benutzt.

Aus demselben Grund ist es wichtig, nicht allein auf Farbe als Informationsträger zu vertrauen. Links, zum Beispiel, sollten sich vom umgebenden Text nicht nur in der Farbe unterscheiden, sie könnten beispielsweise fett unterstrichen sein.

2. Dokumenttitel

Prüfen Sie, dass jedes Dokument einen eindeutigen und beschreibenden Titel hat, der keine übermäßige Zeichensetzung beinhaltet.

Es gibt keine klar definierten Regeln, welche Zeichen als Trennzeichen in Titels verwendet werden sollten. Trotzdem sollten Dokumenttitel auf keinen Fall Zeichen beinhalten, die dekorativen Zwecken dienen, zum Beispiel “:: Titel ::” oder “…== Titel ==…”. Jedes Interpunktionszeichen könnte vom Screenreader laut vorgelesen werden, was das Lesen der Titel sehr nervtötend macht. Wie einige Zeichen in JAWS klingen, besuchen Sie The Sound of the Accessible Title Tag Separator.

Ein anderer Screenreader, Apples VoiceOver, liest “»” als nach rechts zeigendes doppelwinkliges Anführungszeichen. Das schließt das Zeichen für Dokumenttitel aus, aber ebenso für Links, wo es leider recht beliebt ist.

Eine Diskussion über verschiedene Titeltrennzeichen finden Sie unter Dokumenttitel und Titeltrennzeichen.

Warum? Dokumenttitel sind aus verschiedenen Gründen wichtig: Oftmals werden sie von Hilfsmitteln als Erstes beim Laden einer Seite wiedergegeben, sie werden in der Browsertitelleiste angezeigt, in Favoriten und beim Druck eines Dokumentes. Beschreibende Dokumenttitel sind hilfreich für jeden. Sie sind ebenso für Suchmaschinenlistings wichtig.

Links sollten sinnvoll sein, wenn sie ohne Kontext gelesen werden. “Klicken Sie hier” oder “hier” eignen sich nicht als gute Linktexte, da sie keinerlei Informationen über das Linkziel geben. Linktexte, die aus einem ganzen Absatz bestehen, wie man es oft auf Zeitungswebseiten sieht, enthalten zu viel Information und sollten vermieden werden.

Allgemein sollte der gleiche Linktext nicht für Links benutzt werden, die zu unterschiedlichen Zielen führen. Idealerweise sollte jeder Link auch ohne Kontext sinnvoll sein und für sich selbst stehen. Einige automatische Zugänglichkeitstools warnen Sie vor solchen Fehlern.

Es gibt Ausnahmen. Linktexte wie “Lesen Sie mehr” oder “Lesen Sie weiter” können in Nachrichtenauflistungen oder ähnlichem in Ordnung sein, solange das Titelattribut benutzt wird, um Links zu unterscheiden. Joe Clark erklärt dies in einem Interview seiner Web Standards Group vom Mai 2005.

Für einen Überblick über alle Links in einem Dokument können Sie entweder Opera benutzen oder die Funktion “Links list” in der Firefox-Erweiterung Fangs nutzen.

Warum? Links sind nützlicher, wenn sie beschreibend sind. Die meisten sehenden Menschen scannen Webseiten, um einen schnellen Überblick zu erhalten, und Links sind oft ein wichtiger Bestandteil dieses Inhaltes. Klare Links machen das Scannen schneller. Blinde und sehbehinderte Menschen können eine Seite nicht so scannen, sie müssen stattdessen von Link zu Link springen oder eine Liste aller Links erzeugen lassen, daher hilft beschreibender Linktext. Beschreibende Links sind weiterhin wichtig für Suchmaschinen, so dass dieser Aspekt von Zugänglichkeit zu guter SEO gehört.

4. Non-HTML-Formate

Falls die Seite wichtige Informationen in PDF, Microsoft Word, Microsoft Excel oder anderen proprietären Formaten anbietet, sollten immer Alternativen in HTML existieren. Beachten Sie, dass es nicht falsch ist, Informationen in non-HTML-Formaten bereitzustellen solange es ebenso in HTML zur Verfügung steht.

Warum? Obwohl es möglich ist, PDF-Dateien für Personen mit der nötigen Software zugänglich zu machen, ist HTML trotzdem das am weitesten unterstützte Format und sollte immer bevorzugt werden. Zusätzlich haben nur die wenigsten Microsoft Word oder Excel um solche Dokumente zu öffnen. Falls Informationen nur in einem proprietären Microsoftformat vorhanden ist (was oft der Fall ist), sind viele Menschen effektiv ausgeschlossen.

5. Plattformausgrenzung

Mit Plattformausgrenzung meine ich teilweises oder volles Ausperren von Benutzern, die wenig verbreitete Betriebssysteme oder Webbrowser verwenden. Für diesen Prüfschritt sollten Sie idealerweise verschiedene Betriebssysteme mit mehreren Browsern benutzen können. Da das sicherlich nicht bei vielen der Fall ist, müssen sie darauf zurückgreifen, die Useragentangabe im Browser für den Test zu fälschen.

Da Sie Firefox benutzen (was ich Ihnen im ersten Teil empfahl), können Sie die Erweiterung User Agent Switcher installieren, eine Liste aller Useragents herunterladen und Sie sind bereit.

Prüfen Sie, ob die Seite außer dem Internet Explorer Windows auch andere Useragents akzeptiert. Hier prüfen wir lediglich, ob die Seite Arten des Browser-Sniffing einsetzt, die die Useragentangabe überprüft. Wenn die Ausgrenzung auf Einstellungen beruht, die nur auf speziellen Plattformen verfügbar sind, hilft das Fälschen der Useragentangabe hier nicht.

Plattformausgrenzung mag unbeabsichtigt sein, aber all zu oft ist es beabsichtigt. Es ist extrem schwer eine Seite zu finden, die Benutzer des Internet Explorers für Windows ausgrenzt. Viele Mac- und Linuxbenutzer andererseits haben vermutlich erfahren, von verschiedenen Seiten ausgeschlossen zu werden, da ihr Betriebssystem oder Browser “nicht unterstützt” wurden. Das ist absolut inakzeptabel

Ich argumentiere oft, dass Webzugänglichkeit ein viel breiteres Spektrum umfasst als behinderte Menschen zu bedienen. Plattformausgrenzung ist ein hervorragendes Beispiel dafür und der einzige wichtige Faktor für mich, wie wichtig es ist, überhaupt zugänglich zu sein. Nur wenige Dinge sind so störend wie die Tatsache, Informationen nicht zu erhalten, nur weil ich einen Mac benutze.

Warum? Weil eine der fundamentalen Eigenschaften des Webs die Unabhängigkeit von benutzter Hard- und Software sein sollte. Ein Web für alle, überall, über alles.

6. Navigation mit der Tastatur

Legen Sie Ihre Maus für eine Weile beiseite und versuchen Sie, die Seite nur mit der Tastatur zu bedienen, zwischen Links und zwischen Formularfelder zu springen. Bedenken Sie, dass Sie eventuell die Einstellungen Ihres Browsers anpassen müssen. Weder Firefox noch Safari ermöglichen das standardmäßig. Funktioniert es? Falls Dropdown- oder Flyout-Menüs vorhanden sind, prüfen Sie, ob Sie sie ohne Maus benutzen können.

Warum? Screenreaderbenutzer navigieren nicht mit der Maus durchs Internet, daher ist es wichtig für sie. Es gibt viele Menschen, die lieber die Tastatur benutzen, weil sie es schneller und effizienter finden als die Maus.

Abhängig vom Reihenfolge im Quelltext und der Größe des Dokuments kann es für Tastaturbenutzer sehr nützlich sein, Informationen zu überspringen. Wenn das Dokument große Mengen an Links vor dem Hauptinhalt enthält, kann ein solcher Skiplink sehr hilfreich sein, da er Keyboardbenutzer ohne viel Tastendrücken direkt zum Inhalt führt.

Eine zugängliche Seite muss geräteunabhängig sein und darf nicht darauf vertrauen, dass Besucher ein bestimmtes Gerät, in diesem Falle die Maus, benutzen.

7. Datentabellen

Jetzt ist der Moment, um den Gebrauch oder Missbrauch von Tabellen zu kontrollieren. De Web Developer Erweiterung wird jetzt erneut nützlich. Benutzen Sie Outline - Outline Table Cells und Outline - Outline Tables, um alle Tabellen hervorzuheben. Falls die betrachtete Seite keine Tabellen beinhaltet, sollten Sie nichts sehen. Falls Teile der Seite, die keine tabellarischen Daten enthält, hervorgehoben wird, werden Tabellen für das Layout benutzt und die Seite besteht diesen Test nicht.

Falls die Seite tatsächlich tabellarische Daten enthält, prüfen Sie, ob es als Tabelle ausgezeichnet ist und korrektes und zugängliches Markup verwendet. Für weitere Informationen zur richtigen Verwendung von HTML empfehle ich Ihnen meine Artikel Bring on the tables.

Warum? Tabellen sollten nicht für Layoutzwecke verwendet werden und tabellarische Daten sollten richtig mit Tabellen ausgezeichnet werden, die verfügbare Elemente und Attribute zur Erhöhung der Zugänglichkeit benutzen.

8. Bedienelemente und Kennzeichnung von Formularen

Für diesen Kontrollschritt sollten Sie eine Seite finden, die mindestens ein Formular enthält. Wenn Sie das tun, überprüfen Sie jedes einzelne Formularfeld auf das dazugehörige Label. Prüfen Sie, ob die Labels richtig mit Labelelementen ausgezeichnet sind und die Elemente in der richtigen Reihenfolge aufgeführt sind (erst das Label, dann das Formularfeld, ausgenommen Radio-Buttons und Checkboxen, bei denen zuerst das Feld dann das Label erscheinen sollte).

Falls das Formular Checkboxen zur Navigation verwendet, prüfen Sie, ob das Formular automatisch (mit JavaScript) gesendet wird, wenn eine Option ausgewählt wird. In Fällen, in denen JavaScript nicht verfügbar ist, stellen Sie sicher, dass das Formular abgeschickt werden kann und jegliche clientseitig eingegebene Information vom Server verarbeitet wird.

Automatisierte Zugänglichkeitswerkzeuge informieren Sie normalerweise, wenn Formularfelder kein Label besitzen. Sie können außerdem die Web Developer Erweiterung benutzen: Forms - View Form Information. Stellen Sie fest, ob alle sichtbaren Felder eine zugehöriges Label besitzen.

Warum? Richtige Labels helfen jedem, da sie den anwählbare Bereich vergrößern. Jedes sichtbare Formularfeld sollte deutlich mit einem Lebelelement verknüpft sein.

Tatstaturbenutzer haben große Probleme, wenn Formulare automatisch versandt werden, wenn eine Option in einer Select-Box ausgewählt wird. JavaScript vorauszusetzen, macht es dem Nutzer unmöglich, das Formular ohne JavaScript abzuschicken. Wenn Sie sich auf JavaScript verlassen, kann es zu unvorhersehbaren Werten im Formular und in der Datenbank kommen.

9. Benutzen Sie einen Screenreader

Zu allererst möchte ich betonen, dass sich Zugänglichkeit nicht nur um Screenreader dreht. Weit entfernt. Zugänglichkeit mit der Behauptung “Funktioniert mit Screenreader X” gleichzusetzen, ist ein verbreiteter Fehler, und Zugänglichkeit ist weit mehr als das.

Jetzt zu Screenreadern. Falls sie nicht blind sind, ist es schwer, sich vorzustellen, wie man das Web mit ohne Sehvermögen erleben kann. Sie können es versuchen, aber es ist schwer nicht zu schummeln. Sie sollten es trotzdem versuchen und dazu benötigen Sie einen Screenreader.

Falls Sie einen Mac benutzen, ist ein Screenreader vielleicht schon installiert – Mac OS X 10.4 und neuer enthalten VoiceOver, Apples Screenreader-Software. Es ist nicht so umfangreich wie andere Screenreader aber gut genug, um Ihnen eine Vorstellung zu geben, wie eine Website klingt. Ich habe einen Artikel geschrieben, der die Grundlagen von VoiceOver erklärt: VoiceOver and Safari: Screen reading on the Mac.

Falls Sie keinen Mac mit Mac OS X 10.4 oder neuer besitzen, müssen Sie einen Screenreader installieren. Die meisten Screenreader sind sehr teuer, deshalb müssen Sie wahrscheinlich eine Demoversion benutzen. Hier ist eine Auswahl an Screenreadern, die man als Demoversion nutzen kann:

Warum? Alle anderen Punkte in diesem Artikel werden sie in Bezug auf Zugänglichkeit sehr weit bringen. trotzdem ist es wichtig, das Web so zu erleben wie jemand, der nicht sehen kann, da Sie so die Wichtigkeit vieler genannter Probleme verstehen.

Vergessen Sie nicht den Inhalt

Falls Ihre Seite alle Prüfschritte überstanden hat, könnte man sagen, die Seite sei technisch gesehen zugänglich. Das bedeutet nicht automatisch, dass die Seite verständlich ist.

Schreiben oder auch das Erzeugen und Präsentieren von Inhalten, die wirklich zugänglich sind, kann sehr schwer sein und die Bewertung dieses Aspektes von Zugänglichkeit sprengt den Rahmen dieses Artikels. Denken Sie also immer, dass schlecht oder zusammenhanglos geschriebener Inhalt sogar für intelligente Menschen schwer zu verstehen ist.

Verständlich also, dass das Verstehen von Inhalten für Menschen mit Wahrnehmungsschwierigkeiten oder Lernproblemen noch schwerer ist. Ein empfehlenswerter Artikel zu diesem Thema ist Developing sites for users with Cognitive disabilities and learning difficulties. In diesem Artikel diskutieren Roger Hudson, Russ Weakley und Peter Firminger problematische Bereiche und bieten Hilfen zur Erhöhung der Zugänglichkeit.

Weitere Informationen

Ich empfehle ebenso die Web Content Accessibility Guidelines 1.0 und die dazugehörigen Techniques for Web Content Accessibility Guidelines 1.0. Das sind umfangreiche Dokumente, die ein wenig unzugänglich sein können, aber sie enthalten viele Informationen.

Sie sollten ebenso den Entwürfe des WCAG 2.0 und das dazugehörige Dokument Techniques for WCAG 2.0 lesen. Die WCAG 2.0 Dokumente sind nur Entwürfe und können sich vor dem Inkrafttreten noch ändern.

Zu guter letzt, Zugänglichkeit ist kein Fall von “alles oder nichts”. Etwas tun, um Zugänglichkeit zu verbessern ist viel besser als nichts zu tun und zu hoffen, niemand merkt es.

Dieser Artikel ist eine Übersetzung des Artikels “Evaluating Website Accessibility Part 3, Digging Deeper” von Roger Johansson. Alle Rechte am Artikel bleiben beim Autoren. Für weitere Informationen und Artikel zum Thema Webstandards besuchen Sie seine Seite 456 Berea Street.
Original “Evaluating Website Accessibility Part 3, Digging Deeper” von Roger Johansson.

Kategorie: Webstandards

von

Hallo, ich bin Nadja und arbeite als freie Webdesignerin in Berlin. Seit den 2000er-Jahren ist das Internet mein berufliches Zuhause, hier im cne _LOG schreibe ich erst seit Anfang 2006 zu den Themen Webdesign, Webstandards und vor allem auch Wordpress.

5 Kommentare

  1. Pingback: Cyberoog, die Insel im Web (Blog)

  2. Pingback: » Die Evaluierung von Webseitenzugänglichkeit Teil 1, Hintergrund und Vorbereitung — cne _LOG Archiv

  3. Vielen vielen Dank für die Übersetzung. Ich hatte mich schon durch den englischen Artikel durchgekämpft, aber dabei vieles nicht verstanden.

  4. Hallo,

    vielen Dank für Deinen Artikel. Accesibility wird ja allgemein unterschätzt, sehr schön fand ich einen Gedanken von Steve Krug aus “Don´t make me think! Web Usability”, wo er schreibt, dass die Welt von Webmastern und -desigern zum größten Teil aus leistungsfähigen Endzwanzigern besteht und es ihnen (uns;-)) schwerfällt, sich vorzustellen, dass ein großer Prozentsatz der Bevölkerung beim Benutzen des Internets Hilfe braucht.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>