Barrierefreiheit umsetzen – die Hürden und Herausforderungen
Die W3C-Empfehlung zur Barrierefreiheit (Web Content Accessibility Guidelines, WCAG 1.0) gibt es schon seit 2008. Assistive Technology (Screen Readers etc.) noch länger. Aber 99 % aller Entwicklerinnen und Entwickler von Widgets, PlugIns und Komponenten – insbesondere von beliebten JS/CSS-Frameworks wie z.B. Bootstrap, jQuery (und deren UI Kits) oder WebApps, die auf Angular, React oder Vue basieren – tun so, als gäbe es dieses Thema nicht. Damit werden ca. 20 % der User teils oder ganz ausschlossen, welche Apps oder Websites benutzten, die auf diesen Technologien basieren. Das ist leider traurige Wahrheit.
Ein Blick zurück.
HTML5/CSS3
Mit HTML5 (W3C: 1. Entwurf 2008, Empfehlung 2014) wurde u.a. auch strukturierende HTML-Tags wie <header>, <main>, <footer>, <aside>, <nav>, <article> und <section> eingeführt. Erklärtes Ziel war, dass HTML-Code von Haus aus semantischer werden sollte, so dass Webseiten im Allgemeinen besser von Maschinen gelesen und interpretiert werden können.
Als die meisten Browser ab 2010/11 anfingen diese neuen HTML-Tags (und CSS-Attribute) zu unterstützen, wurde das in der Web-Community dankend angenommen. Tabellen-Layouts waren inzwischen von komplexen DIV-basierten Layouts abgelöst worden. Aber die Verschachtelungsebenen waren aus Code-Sicht inzwischen so unlesbar geworden („DIV soup“), dass diese neuen Tags helfen sollten, mehr Ordnung und Klarheit in den Code zu bringen.
Allerdings fand die Verwendung eher zögerlich statt, insbesondere weil IE (damals immer noch ein weit verbreiteter Browser) diese neuen Tags nur mangelhaft unterstützte. Was letztlich dazu führte, dass für diese Browser JavaScript eingesetzt werden musste, um die volle HTML5-Unterstützung gewährleisten zu können. Was wiederum jQuery zu seiner grossen Popularität verhalf, weil nur jQuery imstande war, die diversen Inkompatibilitäten der Browser mit den neuesten JS-Versionen überbrücken zu helfen. Auch die nicht so klaren Anwendungsregeln der strukturieren HTML-Tags führten oft dazu, dass bis heute noch immer nicht klar ist, wie z.B. <section>, <article> und <aside> im Layouting zu verwenden sind.
Aus UX-Sicht war hingegen die Einführung von CSS3 ein Segen, da Zustandsänderungen von Buttons, Widgets, Form Controls oder ganzen Layout-Sektionen – dank den neuen CSS-Attributen wie „transition“ und „animation“ – nun viel einfacher mit CSS statt mit JS dargestellt werden konnten. Diese befähigten „Web-Designer“ (statt „Programmierer“) sich stärker mit diesem Thema auseinanderzusetzen… oder sich auseinandersetzen zu müssen. Damit wurde nebst der Gestaltung der Benutzeroberflächen (UI / User Interface Design) auch die Benutzererfahrung (UX / User Experience Design) ein zentraler Punkt in der Frontend-Entwicklung von WebApps.
Web Accessibility Initiative – Accessible Rich Internet Applications
WAI-ARIA ist eine vom World Wide Web Consortium (W3C) veröffentlichte technische Spezifikation. Diese legt fest, wie die Zugänglichkeit von (dynamisch-interaktiven) Webseiten, die mit Ajax, HTML, JavaScript und verwandten Technologien entwickelt wurden, verbessert werden kann, um sie für Menschen mit Behinderungen besser zugänglich zu machen, insbesondere für blinde Anwender, die Screen-Reader verwenden.
Die WAI hat hierzu schon sehr früh (Mai 1999) ihre erste Empfehlung als WCAG 1.0 (Web Content Accessibility Guidelines; englisch für «Richtlinien für barrierefreie Webinhalte») formuliert, welche aber erst 2008 final verabschiedet wurde. Aktuell wird an der Version 2.2 gearbeitet.
ARIA ist eine rein semantische Erweiterung für HTML, die das Layout einer Webseite nicht verändert. Dazu werden in dynamischen Webanwendungen Informationen zu Rollen, Eigenschaften und Zuständen per JS/AJAX hinzugefügt. Statt sich darauf zu verlassen, dass man die richtigen HTML-Tags für den richtigen Zweck verwendet, hat ARIA eine Reihe neuer HTML-Attribute definiert, welche HTML-Tags – egal welchen – zugewiesen werden können:
- Rollen (z.B. role=“navigation“, role=“tablist“)
- Bedeutungen (z.B. aria-label, aria-required, aria-invalid)
- Zustände/Eigenschaften (z.B. aria-current, aria-selected)
Leider kam und kommt es auch hier zu unglücklichen Überschneidungen bezüglich Deutungshoheiten zwischen ARIA und semantischem HTML. Mit allen Konsequenzen von «Doppeldeutigkeiten» oder «Bad Practices», so dass unnötige ARIA-Anweisung in Tags landen, wo sie nicht hingehören, wie z.B. <nav role=“navigation“> oder <aside role=“complementary“>. Die Internet-Foren/Blog sind voll von Beiträgen zum Thema: „No ARIA is better than bad ARIA. This is one of the core rules of WAI ARIA.“
ECMAScript 2015
Mit ECMAScript 2015 oder ES6 (6th Edition) wurde ein JavaScript-Standard eingeführt, welcher von allen modernen Browsern gleich von Anfang an unterstützt wurde. Damit wurde ein Boom von JS-basierten Frameworks für die Frontend-Entwicklung ausgelöst, aus denen u.a. Angular, React und VUE hervorgegangen sind. Diese prägen heute zu weiten Teilen das Look & Feel heutiger Webapplikationen und die komponenten-basierte Software-Entwicklung, nicht zuletzt durch die sog. UI Kits, die spezifisch für diese Frameworks entwickelt wurden und werden.
Grob vereinfacht muss man heute jedoch feststellen, dass je mehr Funktionalität, Konfigurierbarkeit und Bedienkomfort in eine Komponente gepackt wird, desto wahrscheinlicher ist es, dass dabei die Barrierefreiheit vernachlässigt wird. Form Controls wie z.B. die praktischen DatePickers oder Multiselects gibt es zu hunderten, aber nur wenige sind einwandfrei mit der Tastatur bedienbar und nur die allerwenigsten erfüllen die Mindestanforderungen der Barrierefreiheit.
Stand heute
Diese Erfahrung haben wir von der ID Applications (ID APPS) erst grad letzthin gemacht, als wir eine JS-basierte Applikation upgraden und dabei auch die Barrierefreiheit sicherstellen wollten. Von 30 getesteten DatePickern war genau einer barrierefrei. Bei Multiselect gab es keinen, der aus Sicht der Barrierefreiheit brauchbar war. Infolgedessen haben wir (ID Applications und Partner von «ADG/Zugang für alle») beschlossen, einen barrierefreien Multiselect selbst zu entwickeln. Der erste Prototyp soll Mitte März 2022 vorgestellt werden.
Wer heute moderne Frontend-Applikationen entwickeln will, kann aus einer Vielzahl von JS/UI Frameworks und Libraries auswählen. Bei vielen kann man interessanterweise nachlesen, dass diese „… compatible with the WAI-ARIA guidelines for web accessibility“ sind. Nimmt man diese dann etwas genauer unter die Lupe, z.B. einen ihrer Komponenten wie den DatePicker, das Multiselect oder modale Fenster, dann ist schnell das Ende der Fahnenstange erreicht. Oftmals ist das Customizing sehr umständlich, oder die Dokumentation orientiert sich an ganz einfachen Beispielen. Oder die Barrierefreiheit ist reines Wunschdenken.
Wer sich also auf ein JS/UI-Framework einlässt, muss sich nicht nur mit der impliziten Designphilosophie und der damit zusammenhängenden Code-Base auseinandersetzen, er/sie muss auch sicherstellen, ob und wie sich Komponenten anpassen lassen, wenn Kunden oder User Design- oder Funktionsanpassungen wünschen. Insbesondere wenn diese Differenzierung (sich von anderen unterscheiden) und Individualisierung (Anpassung auf die eigenen Prozesse) einfordern.
And last but noch least: Die Barrierefreiheit muss sichergestellt sein, egal welche Technologie bei den Lern- und Informationsplattformen eingesetzt wird. Dies hat die ETH Zürich in ihrem Programm «Hindernisfreiheit an der ETH Zürich» formuliert, welches 2020/21 gestartet wurde.
Wir von der ID Applications haben nun vier Jahre Zeit für dieses Ziel.
Kontakt
- Luis Argüello WCMS and Mobile Applications, ID APPS (Autor des Beitrages)
- Christian Schär, Gruppenleiter WCMS and Mobile Applications, (ID APPS)
- Manu Heim, Projektleiterin Barrierefreie Kommunikation (HK)
Posted on
in Mail, Web, News, Passwort, Applikationen, Software, Arbeitsplätze, Support
