ARIA – ihm schmeckt´s nicht

ARIA – ihm schmeckt´s nicht

An dieser Stelle möchte als erstes dem Autor Jan Weiler für seine Romantitel danken. Sein Buch „Maria – ihm schmeckt´s nicht“ hat zwar rein gar nichts mit dem Thema ARIA oder Barrierefreiheit zu tun, aber die phonetische Verwandtschaft und die ironische Note passen einfach zu gut zum meinem Artikel über WAI ARIA – vor allem für einen etwas tendenziösen Beitrag.

WAI ARIA ist eine tolle Sache

Vorneweg, ich möchte an dieser Stelle absolut nichts gegen ARIA sagen – ganz im Gegenteil. Ich möchte hier auch nicht ausführlich erklären, was ARIA ist (https://www.w3.org/WAI/standards-guidelines/aria/). Denn jeder Webentwickler, der sich eingehender mit Barrierefreiheit beschäftigt, wird in dem einen oder anderen Quelltext schon mal über Aria-Attribute gestolpert sein. Aber ganz kurz möchte WAI ARIA trotzdem erläutern? WAI ist die Abkürzung für Web Accessibility Initiative. Die Web Accessibility Initiative ist Teil des W3C und entwickelt Strategien, Standards, Richtlinien und Arbeitsmaterialien, um das Internet für Menschen mit Behinderungen zugänglicher zu machen. Eine der bekanntesten Richtlinien der WAI sind die WCAG (Web Content Accessibility Guidelines), also die Mutter der BITV. Aus dem gleichen Haus WAI kommen aber eben auch die ARIA-Standards.

ARIA – Accessible Rich Internet Applications

ARIA steht für Accessible Rich Internet Applications und enthält einen ganzen Werkzeugkoffer voller Instrumente, um vor allem komplexere Webanwendungen für Menschen mit Behinderungen zugänglicher zu machen. Wobei man das konkretisieren muss. Die WAI ARIA adressieren nicht Menschen mit Behinderung allgemein, sondern zu 98 % blinde oder stark sehbehinderte Menschen, die auf Sprachausgabe und Tastatursteuerung angewiesen sind. Insbesondere dynamische Inhalte und komplexe Funktionselemente moderner User Interfaces, die mithilfe von HTML, CSS und JavaScript umgesetzt werden, fehlt es heutzutage oft an nativen „Zusatzinformationen“ über ihren Sinn und Zweck – vor allem wenn diese Funktionselemente verschiedene Zustände haben oder andere Seitenelemente steuern.

Nutzer von Sprachausgabe, erhalten mit Standard-HTML-Elementen und Standard-HTML-Attributen oft nicht die notwendigen Informationen, um komplexere User Interface Komponenten verstehen und bedienen zu können. Ein Button öffnet ein Layer? Wie erfährt der blinde Nutzer davon? Ein Formularfeld ist ein Pflichtfeld? Woher weiß der blinde Nutzer das? Irgendwo auf der Seite erscheint ein Warnhinweis, wie bekommt ein Screenreader-Nutzer das mit?

In den WCAG-Richtlinien gibt es für diese Problematik einen eigenen Prüfpunkt. Die Richtlinie 4.1.2 Name, Rolle, Wert adressiert genau diesen Aspekt. Ein einfaches Beispiel für Name, Rolle, Wert für einen Button wäre: Name „Kostenpflichtig bestellen“. Rolle wäre Button (also ein Schalter, der eine Funktion auslöst). Und der Wert (also die Eigenschaft) könnte sein „nicht klickbar“ (aria-disabled=“true“). Das ist ein ziemlich simples Beispiel, aber nichts Ungewöhnliches. In dieser Form ist ARIA wirklich eine tolle Sache, um Name, Rolle und Wert maschinenlesbar zu machen. Und manche ARIA-Attribute sind auch unumgänglich, will man komplexere User Interface Komponenten den WCAG Richtlinien entsprechend korrekt umsetzen.

Die erste ARIA-Regel ist die Wichtigste

Trotzdem: ARIA ist nicht der Heilige Gral. ARIA füllt nur eine Lücke, die natives HTML alleine (zum Teil noch) nicht schließen kann. ARIA ergänzt natives HTML hervorragend. ARIA ist aber kein Ersatz für semantisches HTML. Ich meine explizit nicht valides HTML, sondern semantisches HTML. Leider beachtet scheinbar niemand die erste und wichtigste ARIA-Regel: Nutzen Sie natives HTML. Im Original lautet die erste Regel: „If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.“ Es gibt drei Ausnahmen zu dieser Regel, aber aus der Praxis kann ich sagen, dass diese zumeist nicht relevant sind. Also die erste ARIA-Regel lautet: Nutzen Sie kein ARIA, es sei denn es geht nicht anders! Oder anders ausgedrückt, kein ARIA ist besser als schlecht eingesetztes ARIA: https://www.w3.org/TR/wai-aria-practices-1.1/#no_aria_better_bad_aria.

Viele Webentwickler scheinen diesen Zusammenhang nicht zu sehen oder zu kennen. Vor allem in Zeiten populärer JavaScript-Frameworks, wie Angular oder React, versuchen sie bedeutungslosen, aber prima beherrschbaren <DIV>- und <SPAN>-Brei mit ARIA-Attributen in semantisches HTML zurückzubiegen. Natürlich sind diese Frameworks alleine nicht Schuld an dem Dilemma: https://reactjs.org/docs/accessibility.html. Und auch wenn man sich andere JavaScript Plugins anschaut, stößt man auf das gleiche Problem – schon seit Jahren. Trotzdem, wie sagte Paul Watzlawick treffend: „Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.“ Und so kommt es nicht von ungefähr, dass DIV-Höllen in den letzten Jahren eher zugenommen haben.

Marco Zehe, selbst blind und langjähriger Accessibility-Consultant sieht das ähnlich frustriert:

„Ich mache diesen Web-Accessibility-Kram jetzt schon so lange und habe doch das Gefühl, nie wirklich was zu erreichen. Bei jedem neuen Klienten (…) fange ich (…) mit denselben Basics an: Semantisches HTML, Alt-Texte auf Grafiken, richtig beschriftete Formularfelder, richtige Überschriftenhierarchie, richtige Tastaturnavigation. (…) Da ist noch nichts von WAI-ARIA oder gar irgendwelchen JavaScript-Bibliotheken des neuesten Hypes dabei, die bis auf wenige Ausnahmen heute eine schlimmere Div-Soße produzieren als es Framesets und Layouttabellen jemals konnten. Klar gibt es für die auch inzwischen immer wieder Nachbesserungen, aber es ist eben genau das, man programmiert den unachtsamen Entwicklern hinterher, und dann muss man noch dafür sorgen, dass auch ja die zugänglichen Versionen irgendwie auch eingesetzt werden und nicht irgendwelche älteren Versionen im NPM-Stack liegen.“

Die zweite ARIA-Regel ist auch wichtig

Aber auch wenn die erste ARIA-Regel beachtet wurde, muss natives und vor allem semantisches HTML gerade in komplexen Anwendungen doch oft noch zusätzlich durch ARIA-Attribute sinnvoll angereichert werden. Das bringt uns aber zu der zweiten, wichtigen ARIA-Regel: „ändern Sie niemals die native Semantik von HTML-Elementen, es sei denn es geht nicht anders.“

Für Entwickler heißt das: schreiben Sie zum Beispiel nicht <h2 role=tab>heading tab</h2> sondern <div role=tab><h2>heading tab</h2></div> (siehe: https://www.w3.org/TR/using-aria/#second). Leider finden sich auch unter den Beispielen der WAI Lösungen, die sich offensichtlich nicht um die erste und zweite ARIA-Regel kümmern. Beispielsweise die Lösung für ein Akkordeon: https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/examples/accordion/accordion.html

Aus meiner Sicht macht das HTML-Konstrukt mit Definitionslisten, die dann über role=“presentation“ wieder aufgehoben werden, die aber auf den DTs trotzdem role=“heading“ aria-level=“3″ haben, überhaupt keinen Sinn. Letztendlich ist das HTML-Semantik, die über aria wieder gelöscht, bzw. umgebogen wird, plus weitere Aria-Attribute, zu denen es aber mit Screenreader kein Feedback gibt (zumindest nicht NVDA mit Standardeinstellungen).

Ohne semantisches HTML kein ARIA

Ich lehne mich an dieser Stelle mal weit aus dem Fenster und behaupte, ohne fundierte Kenntnisse der Semantik (und Funktionalität) nativer HTML-Elemente nutzt auch ARIA wenig. Denn ein <div role=“button“> erhält zwar durch die ARIA-Rolle die Button-Semantik, aber eben noch nicht die native Button-Funktionalität, die für die Tastaturbedienung wichtig ist. An dieser Stelle möchte ich die W3C zitieren: „Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.“ In einer DIV-SPAN-Suppe helfen auch keine ARIA-Attribute, es sei denn, man weiß, was man tut. Dann allerdings greifen wieder die ersten beiden ARIA-Regeln. Und natürlich die dritte ARIA-Regel: „alle interaktiven ARIA Bedienelemente (siehe oben) müssen auch mit der Tastatur bedienbar sein. Das bedeutet, wer ARIA einsetzt, muss sich nicht nur mit Semantik auskennen – ob nachträglich ergänzt oder nativ – sondern auch mit Tastatursteuerung – also wie man eine Webanwendung oder Internetseite ohne Computermaus vollständig bedienen kann. Wer das nicht weiß, kann auch kein ARIA zuverlässig einsetzen, weil er Regel 3 nicht sicherstellen kann.

Vierte und Fünfte Aria-Regel

Die vierte Regel lautet der Vollständigkeit halber „Do not use role=“presentation“ or aria-hidden=“true“ on a focusable element“. Die fünfte Regel lautet „All interactive elements must have an accessible name“. Die fünfte Regel ist insbesondere bei grafischen Funktionselementen ohne sichtbare Beschriftung – Stichwort Richtlinie 4.1.2 Name, Rolle, Wert – wichtig (https://www.w3.org/TR/using-aria/#fifth). ARIA in den falschen Händen kann viel Schaden anrichten – bis hin zur Verschlechterung der Zugänglichkeit. Vor allem die ARIA-Attribute role=“presentation“ und aria-hidden=“true“ sind dafür bestens geeignet. Das gilt übrigens auch für role=“application“, eine Rolle, die jede Website oder Webanwendung in den sogenannten Software-Modus versetzt und so ausschließlich fokussierbare Elemente mit Tastatur erreichbar macht – mit einer beschränkten Anzahl an Tastaturbefehlen. Gängige Tasten, mit denen sich blinde Nutzer normalerweise ebenfalls Inhalte erschließen können, werden durch role=“application“ komplett unterdrückt. Das bedeutet, dass zum Beispiel Überschriften, Listen oder auch Tabellen mit den entsprechenden Tasten nicht mehr direkt angesprungen werden können. Eine Katastrophe für Screenreader-Nutzer.

Ohne Screenreader-Tests kein ARIA

Aus eigener Erfahrung kann ich sagen, dass viele ARIA-Lösungen nur noch mit Screenreader zuverlässig getestet werden können. Sicherlich gibt es sehr einfache Standardlösungen, die schon beim Blick in den Quellcode als korrekt identifiziert werden können. Aber bei komplizieren Widgets, mit vielen Abhängigkeiten, ist das nicht mehr der Fall. Und wenn ARIA auch noch nach dem Prinzip „viel hilft viel“ in den Quellcode geschüttet wurde, dann geht ohne Screenreader-Test gar nichts mehr.

Fazit und Nachtrag

Falls es bis hierher nicht klar geworden ist, ARIA ist in modernen Webanwendungen unverzichtbar – auch zur Erfüllung von BITV- bzw. WCAG-Richtlinien. Allerdings nur, wenn man die ersten fünf ARIA-Regeln beherzigt und sich auch nicht scheut, seine Lösungen selbst mit Screenreader zu testen. Ansonsten kann man mit Aria sehr viel kaputt machen. Der Einsatz von Aria alleine ist überhaupt noch kein Indiz für Barrierefreiheit.