Web Accessibility Initiative \u2013 Accessible Rich Internet Applications<\/h2>\n\n\n\n
WAI-ARIA ist eine vom World Wide Web Consortium (W3C) ver\u00f6ffentlichte technische Spezifikation. Diese legt fest, wie die Zug\u00e4nglichkeit von (dynamisch-interaktiven) Webseiten, die mit Ajax, HTML, JavaScript und verwandten Technologien entwickelt wurden, verbessert werden kann, um sie f\u00fcr Menschen mit Behinderungen besser zug\u00e4nglich zu machen, insbesondere f\u00fcr blinde Anwender, die Screen-Reader<\/a> verwenden.<\/p>\n\n\n\n Die WAI hat hierzu schon sehr fr\u00fch (Mai 1999) ihre erste Empfehlung als WCAG 1.0<\/a> (Web Content Accessibility Guidelines; englisch f\u00fcr \u00abRichtlinien f\u00fcr barrierefreie Webinhalte\u00bb) formuliert, welche aber erst 2008 final verabschiedet wurde. Aktuell wird an der Version 2.2 gearbeitet.<\/p>\n\n\n\n ARIA ist eine rein semantische Erweiterung f\u00fcr HTML, die das Layout einer Webseite nicht ver\u00e4ndert. Dazu werden in dynamischen Webanwendungen Informationen zu Rollen, Eigenschaften und Zust\u00e4nden per JS\/AJAX hinzugef\u00fcgt. Statt sich darauf zu verlassen, dass man die richtigen HTML-Tags f\u00fcr den richtigen Zweck verwendet, hat ARIA eine Reihe neuer HTML-Attribute definiert, welche HTML-Tags \u2013 egal welchen \u2013 zugewiesen werden k\u00f6nnen:<\/p>\n\n\n\n Leider kam und kommt es auch hier zu ungl\u00fccklichen \u00dcberschneidungen bez\u00fcglich Deutungshoheiten zwischen ARIA und semantischem HTML. Mit allen Konsequenzen von \u00abDoppeldeutigkeiten\u00bb oder \u00abBad Practices\u00bb, so dass unn\u00f6tige ARIA-Anweisung in Tags landen, wo sie nicht hingeh\u00f6ren, wie z.B. <nav role=“navigation“> oder <aside role=“complementary“>. Die Internet-Foren\/Blog sind voll von Beitr\u00e4gen zum Thema: „No ARIA is better than bad ARIA. This is one of the core rules of WAI ARIA.“<\/p>\n\n\n\n Mit ECMAScript 2015<\/a> oder ES6 (6th Edition) wurde ein JavaScript-Standard eingef\u00fchrt, welcher von allen modernen Browsern gleich von Anfang an unterst\u00fctzt wurde. Damit wurde ein Boom von JS-basierten Frameworks f\u00fcr die Frontend-Entwicklung ausgel\u00f6st, aus denen u.a. Angular, React und VUE hervorgegangen sind. Diese pr\u00e4gen heute zu weiten Teilen das Look & Feel heutiger Webapplikationen und die komponenten-basierte Software-Entwicklung, nicht zuletzt durch die sog. UI Kits<\/a>, die spezifisch f\u00fcr diese Frameworks entwickelt wurden und werden.<\/p>\n\n\n\n Grob vereinfacht muss man heute jedoch feststellen, dass je mehr Funktionalit\u00e4t, Konfigurierbarkeit und Bedienkomfort in eine Komponente gepackt wird, desto wahrscheinlicher ist es, dass dabei die Barrierefreiheit vernachl\u00e4ssigt 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\u00fcllen die Mindestanforderungen der Barrierefreiheit.<\/p>\n\n\n\n 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 \u00abADG\/Zugang f\u00fcr alle<\/a>\u00bb) beschlossen, einen barrierefreien Multiselect selbst zu entwickeln. Der erste Prototyp soll Mitte M\u00e4rz 2022 vorgestellt werden.<\/p>\n\n\n\n Wer heute moderne Frontend-Applikationen entwickeln will, kann aus einer Vielzahl von JS\/UI Frameworks und Libraries<\/a> ausw\u00e4hlen. 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\u00e4ndlich, oder die Dokumentation orientiert sich an ganz einfachen Beispielen. Oder die Barrierefreiheit ist reines Wunschdenken.<\/p>\n\n\n\n Wer sich also auf ein JS\/UI-Framework einl\u00e4sst, muss sich nicht nur mit der impliziten Designphilosophie und der damit zusammenh\u00e4ngenden Code-Base auseinandersetzen, er\/sie muss auch sicherstellen, ob und wie sich Komponenten anpassen lassen, wenn Kunden oder User Design- oder Funktionsanpassungen w\u00fcnschen. Insbesondere wenn diese Differenzierung (sich von anderen unterscheiden) und Individualisierung (Anpassung auf die eigenen Prozesse) einfordern.<\/p>\n\n\n\n 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\u00fcrich in ihrem Programm \u00abHindernisfreiheit an der ETH Z\u00fcrich<\/a>\u00bb formuliert, welches 2020\/21 gestartet wurde.<\/p>\n\n\n\n Wir von der ID Applications haben nun vier Jahre Zeit f\u00fcr dieses Ziel.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Ein H\u00fcrdenlauf mit allen Schwierigkeiten, die sich bei der Aufgabe immer wieder stellen.<\/p>\n","protected":false},"author":838,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1179,25,1181,1177,898],"tags":[296623,296607,296632,296631,296633],"class_list":["post-13607","post","type-post","status-publish","format-standard","hentry","category-mail-web","category-news","category-passwort-applikationen","category-software-arbeitsplatze","category-support","tag-hindernisfreiheit-an-der-eth-zuerich","tag-barrierefreiheit","tag-css3","tag-html5","tag-web-accessibility-initiative"],"_links":{"self":[{"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/posts\/13607","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/users\/838"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/comments?post=13607"}],"version-history":[{"count":0,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/posts\/13607\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/media?parent=13607"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/categories?post=13607"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/tags?post=13607"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}ECMAScript 2015<\/h2>\n\n\n\n
Stand heute<\/h2>\n\n\n\n
Kontakt<\/h2>\n\n\n\n
![\"Manu](\"https:\/\/blogs.ethz.ch\/id\/files\/2022\/03\/nl_id_img_272_460-1.jpg\")
<\/a>