Web Content Accessibility Guidelines umsetzen
Kommentare

Die Techniken – ein Quell von Missverständnissen
Für Entwickler ist oft vor allem das Technikendokument interessant, denn es enthält konkrete Umsetzungsbeispiele sowie typische Fehler. Techniken, die

Die Techniken – ein Quell von Missverständnissen

Für Entwickler ist oft vor allem das Technikendokument interessant, denn es enthält konkrete Umsetzungsbeispiele sowie typische Fehler. Techniken, die als ausreichend (sufficient) deklariert sind, zeigen wie die Erfolgskriterien sicher erfüllt werden können. Dabei liegt die Betonung auf „können“, denn diese Techniken sind optional. Theoretisch muss keine der gelisteten Techniken verwendet werden und die Webseite kann trotzdem WCAG-2.0-konform sein. Als Entwickler oder als Redakteur (beispielsweise, wenn es um Textverständlichkeit geht) können Sie eigene Techniken verwenden, neue entwickeln oder (noch) nicht dokumentierte Techniken einsetzen. Letztlich kommt es darauf an, ob die entsprechenden Erfolgskriterien erfüllt sind oder nicht. Vor allem bei eigenen und neuen Techniken ist selbstverständlich unerlässlich, diese mit typischen Hilfsmitteln und „echten“ Nutzern zu prüfen.

Natürlich kann man sich fragen, wie denn sonst als über das H-Element Überschriften in HTML ausgezeichnet werden sollten. Dies macht jedoch umgekehrt die Techniken nicht zum Pflichtprogramm. Sie können also durchaus (noch) nicht dokumentierte HTML5-Techniken, CSS3-Techniken oder JavaScript-Techniken verwenden – sofern diese mit assistiven Technologien und Techniken und damit für Menschen mit Behinderungen funktionieren. Auch PDF-Techniken des PDF/UA-Standards können verwendet werden, ohne damit im Widerspruch zu den WCAG 2.0 zu stehen – selbst dann, wenn diese im Widerspruch stehen würden.

Es sind solche optionalen Wege die WCAG 2.0 zu erfüllen, die der WCAG 2.0 Working Group bekannt sind. Würden umgekehrt ausreichende Techniken als quasi-normativ oder gar normativ angesehen, dann würde man in Konsequenz nicht nur die Arbeit von Entwicklern, sondern generell Innovation behindern. Das würde natürlich auch bedeuten, dass derzeit keine HTML5-Techniken oder sprachenspezifische Techniken für verständliche Texte eingesetzt werden dürften.
Dennoch: Das Technikendokument bietet Anhaltspunkte und Lösungen und enthält neben Klassikern, wie dem korrekten Einsatz von HTML-Strukturelementen, CSS- und JavaScript-Techniken sowie PDF- und ARIA-Techniken. Wie so oft führen manchmal mehrere Wege zum Ziel und welche Techniken am sinnvollsten sind, kann vom spezifischen Webprojekt oder der spezifischen Webseite abhängen. Manchmal kommt man mit Kombinationen am besten zum Ziel, manchmal reicht eine.

Ein einfaches Beispiel

Stellen Sie sich vor, Sie müssten sich bei umfangreichen Websites für das Lesen eines Artikels jedes Mal durch die Haupt- und Subnavigation tabben. Nicht nur, dass sich der Spaß in argen Grenzen hält: Es ist eine Barriere für jeden Tastaturbenutzer. Deswegen gibt es das Erfolgskriterium „Blöcke umgehen“ (EK 2.4.1), womit z. B. solche Navigationsbereiche gemeint sind. Optionale Techniken sind u. a.:

  • das Einsetzen von mindestens einem Sprunglink zum Inhalt
  • das Auszeichnen von Hauptinhaltsbereichen für Screenreader-Nutzer durch versteckte Überschriften
  • der Einsatz von ARIA-Landmarks
  • mehrere Sprunglinks zu den Hauptbereichen

Betrachten wir die Sprunglinktechnik näher, denn bei falschem Einsatz hat man sozusagen die Möglichkeit, gegen mehrere Erfolgskriterien zu verstoßen und umgekehrt natürlich diese zu erfüllen. Dass Sprunglink-Batterien zu allem und jedem noch so kleinen Seitenbereich wenig sinnvoll sind, leuchtet sofort ein und das verbietet schon die Usability. Ein Batterie von, sagen wir, 8 oder 10 Sprunglinks würde zudem selber zu einem Block werden, den der Nutzer umgehen können muss. Die Sprunglinktechnik korrespondiert nicht nur mit besagtem Erfolgskriterium, sondern auch mit dem sichtbaren Fokus. Sind es mehrere Sprunglinks, dann wird ein Listenelement nötig, das Information und Beziehungen verdeutlicht (EK 1.3.1). Sprunglinks können versteckt sein, müssen aber zumindest beim Antabben sichtbar sein und wie andere Inhalte auch, einen Mindestkontrast von 4,5:1 zum Hintergrund haben – zumindest bei der hier typischen normalen Schriftgröße. Ist dies nicht der Fall, dann sind Sprunglinks zwar vorhanden und die Blöcke können übersprungen werden, aber für Konformitätsstufe AA wäre das nicht ausreichend. Beziehen sich die Linktexte der Sprunglinks auf die sichtbare Position, z. B. ein Link mit dem Text „zum rechten Seiteninhalt“, dann wäre bereits Konformitätsstufe A nicht erfüllt (EK 1.3.3). Sprunglinks sind übrigens auch für Nutzer mobiler Endgeräte wichtig, z. B. wenn ein Smartphone-Nutzer auf die Seite zugreift. In diesem Fall wäre es natürlich positiv, wenn sie direkt sichtbar wären.

Sollen Sprunglinks oder auch andere Inhalte zwar von Screenreadern und damit von blinden Nutzern erfasst werden können, aber vor Sehenden versteckt werden, stehen mehrere Techniken zur Verfügung. Die schlechteste und ein immer noch häufiger Fehler ist die Verwendung von display:none oder visibility:hidden. Diese Angaben eignen sich nur, wenn Inhalte explizit auch vor Screenreadern versteckt werden sollen. Screenreader können zwar nicht viel CSS, verhalten sich aber hier standardkonform. Als Techniken eignen sich das Schieben der Inhalte aus dem Viewport oder die Clip-Technik. Beide sind beispielsweise in HTML5 Boilerplate enthalten und können wahlweise verwendet werden. Angesichts der Updatefreudigkeit mancher Browser sollte anhand von Testcases regelmäßig geprüft werden, ob sie noch funktionieren.

Verstehen, was man tut

Wichtiger als das Abarbeiten oder gar Abhaken von Techniken und Erfolgskriterien ist das Verstehen der Barrierefreiheit. Angesichts oft geringer Zeitspannen ist es mehr als verständlich, wenn auf bewährte und dokumentierte Techniken gesetzt wird. Wird aber nur auf das „Was?“ (Erfolgskriterium) und das „Wie?“ (Techniken) geschaut, versäumt man das „Warum?“ (Verstehen). Und: Nur, wenn das „Warum“ verstanden wurde, können vorhandene Techniken adäquat, erfolgreich und auch in anderen als den dokumentierten Kontexten eingesetzt werden.

Als Beispiel sei die Informationsvermittlung über mehrere Kanäle genannt: So greifen redaktionelle Angaben wie „Weitere Inhalte finden Sie rechts“ ebenso zu kurz wie „Aktualisierungen sind in Rot gekennzeichnet“. Screenreader werten Seiten linear aus, weswegen Informationen, die über Richtungsangaben gegeben werden, problematisch für blinde Nutzer sind. Aktualisierungshinweise, die nur über Farbe gegeben werden, sind für mehrere Gruppen problematisch:

  • Menschen mit Schwächen in der Farbwahrnehmung
  • Menschen, die im Web mit benutzerdefinierten Farbeinstellungen unterwegs sind
  • Blinde Nutzer

Erfolgskriterien müssen also verschiedene Bedingungen erfüllen. Jedes einzelne wird daher von einem Teildokument „Erfolgskriterium X verstehen“ begleitet, das sich im Gesamtdokument „WCAG 2.0 verstehen. Ein Leitfaden zum Verständnis und zur Implementierung der Richtlinien für barrierefreie Webinhalte 2.0“ befindet. Zudem enthalten diese Dokumente wichtige Informationen über Assistive Technologien und Arbeitsweisen von Menschen mit Behinderung im Web. Wird das „Warum?“ berücksichtigt, dann können außerdem eigene Techniken erfolgreicher entwickelt werden – angesichts der rasanten Webentwicklung und dem zwingenden „Hinterhinken“ von WCAG-2.0-Updates ein wichtiges Thema.


Themen der letzten Seite

  • Die Senioren werden’s richten
  • Ausschreibungen und Verträge
  • Unterschiede zwischen WCAG 2.0 und BITV 2.0
  • Was ist mit PDF?
  • Ausblick
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -