Neulich erschrak ich ein wenig. In einem Seminar über das Testen der Barrierefreiheit von Webseiten fragte mich einer der Teilnehmenden, wie mit der Kontrastmessung bei aktiviertem ClearType auf Windows-Systemen umzugehen sei. Er erwischte mich auf dem falschen Fuß. Das war Grund genug, der Sache auf den Grund zu gehen.
Gelegentlich schreibe ich Artikel für Fachzeitschriften. In der gerade erschienenen Screenguide sind gleich zwei Beiträge von mir enthalten. Der eine geht auf den werdenden Webstandard IndieUI ein und der andere beschreibt ein komplexes Widget, dass trotz technischer Zugänglichkeit nicht barrierefrei bedienbar ist.
Gestern ist die Website Accessibility Conformance Evaluation Methodology (WCAG-EM) in einer finalen Version vom W3C veröffentlicht worden. Das Dokument beschreibt eine Vorgehensweise, wie Webseiten einschließlich Apps und Webseiten für mobile Geräte auf Konformität zur WCAG 2.0 geprüft werden können. Sie ist vor allem an diejenigen gerichtet, die Webseiten professionell auf ihre Barrierefreiheit prüfen und bewerten.
Studie zur Wirkung von barrierefreien Webseiten auf ihre Nutzer
Das Psychologische Departement der Universität Fribourg in der Schweiz sucht blinde und hochgradig sehbehinderte Teilnehmende für eine Studie zur Barrierefreiheit von Webseiten.
Die Web Content Accessibility Guidelines (WCAG) 2.0 beschreiben mit den Erfolgskriterien, wie einzelne Webseiten auf Barrierefreiheit geprüft werden können. Was in der WCAG 2.0 nicht enthalten ist, sind Rahmenbedingungen für die Prüfung eines gesamten Webauftritts. Wie ein solches Testverfahren aussehen kann, wird in der Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 beschrieben, die seit dem 30. Januar 2014 als Working Draft des W3C vorliegt.
Das Finanzamt Dortmund-Ost hat mir vor wenigen Wochen meinen Steuerbescheid für 2012 zugeschickt. Auf dem ersten Blick war nichts Überraschendes zu erkennen außer dass es eine geringere Nachzahlung gab als mein Steuerberater angekündigt hatte. Ein paar Tage später wies mich der Steuerberater aber darauf hin, dass auf Seite 3 in den Erläuterungen ein Passus stünde, der mich zukünftig zum Gewerbetreibenden machen sollte.
Am 20. März 2014 hat das W3C einen wichtigen Schritt unternommen, um Inhalte und Anwendungen im Web barrierefrei aufbereiten zu können. Mit der Veröffentlichung von Accessible Rich Internet Applications (ARIA) 1.0 als Webstandard wird der Beleg geliefert, dass die Unterstützung von WAI-ARIA durch Browser und Screenreader einen akzeptablen Stand erreicht hat. Jetzt muss die Webentwicklung die Möglichkeiten nutzen.
HTML5 wird zunehmend von Browsern unterstützt, aber die Barrierefreiheit ist größtenteils noch in der Entwicklung. Mit WAI-ARIA gibt es eine Zwischenlösung. WAI-ARIA ist ein Satz zusätzlicher Attribute für HTML und anderen Sprachen, die insbesondere für Screenreader-Nutzer von Vorteil sein können. Dieser Beitrag zeigt die Einsatzmöglichkeiten von WAI-ARIA im Zusammenhang mit HTML5 auf und weist auf typische Fehler hin, die dabei gemacht werden können.
Dieser Beitrag ist die Verschriftlichung meines Vortrags auf dem Webkongress Erlangen 2014. Er ist recht lang. Wer lieber nur die Folien durchblättern möchte, kann die Präsentation als PDF gerne herunterladen, die Präsentation bei Slideshare anschauen oder in die Video- und Audio-Aufnahmen hineinsehen bzw. -hören.
Über die Gestaltung barrierefreier Webseiten gibt es wenige Bücher in deutscher Sprache. Eine gelungene Einführung in das Thema hat Ende 2013 Domingos de Oliveira veröffentlicht.
Seit 2008 unterfüttert die Web Accessibility Initiative (WAI) des W3C die Webstandards zur Barrierefreiheit mit ausführlichen Erläuterungen und Beispielen. Die Dokumentation wird ungefähr einmal alle 1-2 Jahre aktualisiert und erweitert. Gestern war es dann wieder so weit: Die erläuternden Dokumente und die Best-Practice-Beispiele für die Web Content Accessibility Guidelines (WCAG) 2.0 wurden auf einen neuen Stand gebracht.