Die Rolle „application“ wird viel zu oft auf Webseiten eingesetzt. Eigentlich gibt es kaum Fälle, in denen die Rolle berechtigt ist – bestimmte komplexe Anwendungen wie ein Editor oder Widgets, die nicht mit einem der zahlreichen widget roles aus Accessible Rich Internet Applications (ARIA) abgebildet werden können, kommen in Frage. Die Rolle „application“ schränkt in den meisten Fällen die Barrierefreiheit einer Anwendung sehr stark ein.
Nicht alle Inhalte müssen (bis 2018) nach der EU-Richtlinie 2102 barrierefrei werden
Mit der Europäischen Richtlinie 2102 wird ab Dezember 2018 die Anwendung der EN 301 549 respektive der Web Content Accessibility Guidelines (WCAG) 2.0 für alle öffentliche Stellen innerhalb der Europäischen Union verpflichtend sein. Die WCAG 2.0 sind grundsätzlich auf alle Inhaltsformen, Formate und Prozesse auf Webseiten und in mobilen Anwendungen anwendbar, auch wenn es vereinzelte Ausnahmen gibt. In der Europäischen Richtlinie werden weitere Inhaltsformen ausgenommen und für andere Inhalte gibt es längere Umsetzungsfristen.
zum Beitrag »
wer zur Einhaltung der technischen Standards nach der EU-Richtlinie 2102 verpflichtet werden soll
Die Europäische Richtlinie 2102 legt die Anforderungen an die Barrierefreiheit von Webseiten, Dokumenten, mobilen Apps und Intranets fest. Die Mitgliedsstaaten der Europäischen Union werden angehalten, entsprechende Vorschriften für öffentliche Stellen zu erlassen.
Mit Inkrafttreten der Europäischen Richtlinie 2102 stellt sich die Frage, ob sich die Anforderungen der Barrierefreiheit im Web oder in mobilen Apps ändert. Als Mindestanforderung für die öffentlichen Stellen in Europa wird ab Dezember 2018 die Europäische Norm EN 301 549 benannt.
Im letzten Dezember trat die EU-Richtlinie 2016/2102 des Europäischen Parlaments und des Rates über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen in Kraft. Innerhalb von 21 Monaten sollen die Mitgliedsstaaten harmonisierte Standards der Barrierefreiheit in nationales Recht umsetzen.
Die Frage, ob jQuery barrierefrei ist, wird immer wieder gestellt. Dabei ist jQuery nicht das Entscheidende für die Barrierefreiheit, sondern es kommt auf das HTML an. jQuery ist eine JavaScript-Bibliothek, die Entwicklern vereinfachte Funktionen bietet, um den DOM des Browsers zu manipulieren. Barrierefreiheit (im Code einer Webseite) hängt aber von den Elementen und Attributen im DOM des Browsers ab.
Ansätze zum barrierefreien Webdesign gibt es viele. Zuletzt habe ich eine Anwendung untersucht, die ein Interface für Autoren bereitstellt, um Weboberflächen nachträglich barrierefrei zu gestalten. Dabei konnten neben einem Kontrastschema auch weitere Profile für die Tastaturbedienung oder zum Ausschalten von blinkendem Inhalt gewählt werden; Das Profil legte sich einfach als „Accessibility-Overlay“ über die bestehende Webseite. Die Idee ist einfach, aber Nutzer müssen die Erweiterungen per Style-Switcher aktivieren. Außerdem stellt sich die Frage, ob solche Accessibility-Overlays Konformität zu den Web Content Accessibility Guidelines (WCAG) 2.0 bzw. zur Barrierefreien Informationstechnik-Verordnung – BITV 2.0 herstellen können.
Seit über einer Woche bin ich wieder aus dem Urlaub zurück. Jetlag und Termine haben aber dazu geführt, dass ich nur langsam wieder in den Trott gekommen bin. Letzte Woche war insofern öffentlichkeitswirksam, als eine dpa-Meldung über Barrierefreiheit in verschiedenen Medien erschienen ist und eine Veranstaltung in Düsseldorf unerwartet viele Besucher anlockte.
Über acht Jahre nach Veröffentlichung der Web Content Accessibility Guidelines (WCAG) 2.0 in 2008 ist der erste öffentliche Entwurf (first public working draft) der WCAG 2.1 zur Kommentierung veröffentlicht worden. Der Entwurf enthält knapp 30 neue Erfolgskriterien.
Webseiten berücksichtigen heute zunehmend Accessible Rich Internet Applications (ARIA). Eine Beobachtung der letzten Jahre ist aber der überflüssige Einsatz von ARIA-Attributen. Es beginnt bei redundanten Auszeichnungen wie <button role=“button“>, was im Prinzip harmlos ist, und endet bei <body role=“application“>, was in vielen Situationen dazu führt, dass eine Webseite von Screenreadern nicht mehr gelesen werden kann. Eine weitere Problematik, die in nachfolgenden Beitrag diskutiert wird, ist dass ARIA-Attribute zur Bezeichnung von Elementen vergleichbaren HTML-Techniken überlegen sind.