accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

12 Dez 2008

In der Vergangenheit gab es viele Kontroversen um die Weiterentwicklung der Web Content Accessibility Guidelines zur Version WCAG 2.0 (an denen wir auch nicht ganz unschuldig waren), aber fast alle Teilnehmer an der Diskussion hatten immer nur ein Ziel: einen besseren Standard zum Wohle der Nutzer und der Web-Entwickler. Und genau das ist seit gestern, dem 11. Dezember 2008, erreicht – wenn das mal kein Grund zum Feiern ist!

Viele Kontroversen drehten sich um die Komplexität der Dokumente, und sicher sind die Richtlinien komplex, wenn man sie von vorne bis hinten liest (was wir mehrfach gemacht haben). Aber, wie Shadi Abou-Zahra von der WAI sagte: »Lieber zu viel Dokumentation als zu wenig«. Die Richtlinien sind ja nicht ganz ohne Grund so umfangreich ausgefallen, und dafür gibt es zwei einfache Gründe: Robustheit und Testbarkeit. Die WCAG 2.0 ist so Technik-neutral und robust, dass damit sämtliche aktuellen und vor allem auch zukünftige Web-Techniken, die wir noch gar nicht kennen, abgedeckt sein dürften.

Weiterlesen …

Und: sie sind zu 100% testbar! (im Gegensatz zum Vorgänger) Neben den maschinell testbaren Kriterien gibt es eine Reihe nicht-maschinell testbarer Kriterien, die aber alle so formuliert sind, dass zwei verschiedene menschliche Tester unabhängig voneinander zum gleichen Ergebnis kommen müssten. Dies erleichtert die Arbeit mit den Richtlinien doch ungemein.

Und: sie sind zu 100% umsetzbar! Eine wichtige Voraussetzung für die Verabschiedung der Richtlinien war, dass die Umsetzbarkeit für jeden einzelnen Punkt detailliert nachgewiesen werden konnte. Ohne diesen Nachweis keine Richtlinie (übrigens waren auch einige sehenswerte Beispiel-Implementierungen aus dem deutschsprachigen Raum dabei).

Falls Sie nicht die gesamten Dokumente durchlesen wollen – dafür haben wir vollstes Verständnis. Zumindest die grundlegenden Prinzipien und Richtlinien sollte aber jeder professionelle Web-Entwickler kennen. Diese sind wirklich kurz und bündig – so kurz und so einleuchtend dass wir sie hier in Gänze abdrucken:

  1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
    • 1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
    • 1.2 Provide alternatives for time-based media.
    • 1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
    • 1.4 Make it easier for users to see and hear content including separating foreground from background.
  2. Operable – User interface components and navigation must be operable.
    • 2.1 Make all functionality available from a keyboard.
    • 2.2 Provide users enough time to read and use content.
    • 2.3 Do not design content in a way that is known to cause seizures.
    • 2.4 Provide ways to help users navigate, find content, and determine where they are.
  3. Understandable – Information and the operation of user interface must be understandable.
    • 3.1 Make text content readable and understandable.
    • 3.2 Make Web pages appear and operate in predictable ways.
    • 3.3 Help users avoid and correct mistakes.
  4. Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
    • 4.1 Maximize compatibility with current and future user agents, including assistive technologies.

Das elegante am Aufbau der Richtlinien ist, dass die Fülle der Informationen immer größer und die Erklärungen immer präziser werden, je weiter man sich in die Tiefe vorarbeitet. Entwickler müssen also in der Regel nicht alles von vorne nach hinten lesen, sondern können z.B. anhand der anpassbaren Schnellreferenz genau die Techniken auswählen, die für sie von Interesse sind.

Die nächsten Schritte?

Nun ist der Gesetzgeber gefragt, aus dieser Steilvorlage so schnell es geht eine runderneuerte BITV in der Version 2.0 abzuleiten. Dabei wäre es aus Sicht der Betroffenen (und das sind hier nicht nur Menschen mit Behinderungen, sondern auch die Web-Entwickler, die das alles umsetzen müssen, die Hersteller von Testwerkzeugen, Redaktionssystemen und anderen Autorenwerkzeugen, die Software-Industrie etc. pp.) wünschenswert, wenn die neue Verordnung zu 100% kompatibel zum international geltenden Standard wäre.

Kommentare zu dieser Meldung: 1

Permalink Heribert Wettels meinte am 29.01.2009:

Besonders Punkt 1.4.8 der WCAG 2.0 lässt mich stutzen. Dort heißt es: "For the visual presentation of blocks of text [...] Width is no more than 80 characters". Textblöcke sollen also maximal 80 Zeichen breit sein.

Keine Frage: Schmal laufende Texte lassen sich einfacher lesen als sehr breit laufende. Aber 80 Zeichen pro Zeile lässt sich ja eigentlich nur mit einem Layout umsetzen, bei dem das Verhältnis von Spaltenbreite zu Textgröße genau festgelegt ist.

Bisher hatte ich den Ansatz favorisiert, dem Hauptinhalt der Seite den gesamten zur Verfügung stehenden Raum zu geben - liquid eben. Damit kann der Nutzer die Länge der Textzeilen über die Größe des Browserfensters leicht selbst steuern. Also mehr Freiheit für den Nutzer und ein wenig mehr Ungewissheit für den Gestalter. Und wer hat bei den immer häufiger verwendeten großen Widescreens den Browser noch ständig auf volle Bildschrimgröße geöffnet?

Mich würde interessieren, welche Erfahrungen Ihr gemacht habt, und wie Ihr zu diesem Punkt steht.

Zur Veranschaulichung hier mal exakt 80 Zeichen in einer Zeile:
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789