WAI-ARIA: Top 6 Mistakes to Avoid

Bevor wir uns mit den häufigen Fehlern bei ARIA befassen, wollen wir noch einmal zusammenfassen, was ARIA leistet. ARIA steht für „Accessible Rich Internet Applications“ und trägt dazu bei, Webinhalte oder Webanwendungen für Menschen mit Behinderungen besser zugänglich zu machen. Es ist insbesondere bei dynamischen Inhalten und komplexen Bedienelementen der Benutzeroberfläche hilfreich, die mit Ajax, HTML, JavaScript und verwandten Technologien entwickelt wurden. Mit WAI-ARIA können Entwickler komplexe Webanwendungen für Menschen mit Behinderungen zugänglich und nutzbar machen.

Es ist nichts Falsches daran, ARIA zur Behebung von Barrierefreiheitsproblemen einzusetzen, solange die Autoren genau wissen, wie und wann ARIA zu verwenden ist. Es ist wichtig zu beachten, dass der falsche Einsatz von ARIA zu einer noch schlechteren Barrierefreiheit führt als der Verzicht auf ARIA. Ein gängiges Sprichwort in der Barrierefreiheits-Community lautet: „Kein ARIA ist besser als schlechtes ARIA.“ Im Folgenden werde ich einige der häufigsten Fehler aufzeigen, die bei der Behebung von Barrierefreiheitsproblemen mit ARIA auftreten können.

Die folgenden häufigen Fehler stammen aus Erfahrungen aus erster Hand, die mein Team und ich im Bereich der Barrierefreiheitsoptimierung gesammelt haben. Bei Deque nutzen wir für unsere Bewertungsprojekte ein Qualitätssicherungstool namens WorldSpace Assure. In den letzten zwei Jahren haben wir mit diesem Tool mehr als 7.000 ARIA-bezogene Probleme erfasst. Im Folgenden sind die sechs häufigsten WAI-ARIA-Fehler aus diesem Datensatz aufgeführt.

WAI-ARIA-Fehler Nr. 1: Falsche WAI-ARIA-Syntax

Die meisten Technologien erfordern eine bestimmte Syntax; ebenso gilt dies auch für WAI-ARIA. Wird die korrekte Syntax nicht eingehalten, kann dies zu unerwarteten Ergebnissen führen. Lassen Sie uns einige der häufigsten Syntaxfehler besprechen, die Autoren oft in ihrem Code machen und die zu einer nicht barrierefreien Nutzung führen.

Bei Rollenwerten wird davon ausgegangen, dass die Groß-/Kleinschreibung keine Rolle spielt: Rollenwerte definieren den Zweck von Objekten auf der Seite. Autoren versäumen es häufig, diese Werte gemäß der in der WAI-ARIA-Spezifikation festgelegten Konvention der Kleinschreibung zu implementieren. Beispielsweise kann „role=“LINK““ mit dem Wert „types“ in Großbuchstaben angegeben werden, was dazu führt, dass assistive Technologien das Objekt nicht als Link erkennen können. Autoren müssen beachten, dass bei Rollenwerten die Groß-/Kleinschreibung beachtet werden muss und diese in Kleinbuchstaben eingegeben werden müssen.
Falsche Schreibweise von Attributen oder Werten: Attribute werden häufig falsch geschrieben. So wird beispielsweise „aria-label“ manchmal als „aria-lable“ geschrieben. Infolgedessen können Screenreader den barrierefreien Namen des Steuerelements nicht ansagen. Autoren müssen darauf achten, dass Attribute korrekt geschrieben sind.
Falsche oder ungültige Rollendeklarationen: Autoren deklarieren Rollen häufig falsch. So wird beispielsweise „role=“alert““ möglicherweise als „aria-role=“alert““ deklariert. Infolgedessen können Screenreader die Live-Meldung nicht ansagen. Autoren sollten solche Fehler vermeiden und die Rollen korrekt mit „role=““ statt mit „aria-role=““ deklarieren.
Die Rolle existiert nicht oder ist ungültig: Autoren geben manchmal eine Rolle an, die gemäß der WAI-ARIA-Spezifikation nicht existiert. Beispielsweise könnten Autoren für eine Fehlermeldung „role=“error““ angeben, um die Fehlersemantik zu vermitteln, doch in der Spezifikation gibt es keine solche Rolle „role=“error““. Autoren sollten sich gründlich mit den korrekten Rollenwerten vertraut machen, um solche Probleme zu vermeiden.

WAI-ARIA-Fehler Nr. 2: Untergeordnete Rollen ohne übergeordnete Rollen

Autoren definieren häufig Kinderrollen für Objekte, ohne zuvor deren übergeordnete Rolle zu definieren. Wie Sie vielleicht wissen, können bestimmte Rollen nicht ohne die zugehörigen übergeordneten Rollen bzw. Kontextrollen verwendet werden. So könnte beispielsweise eine Registerkartenrolle ohne die übergeordnete Rolle „tablist“ definiert werden.

Infolgedessen funktionieren Bildschirmleseprogramme möglicherweise nicht wie erwartet. Bei einigen Kombinationen aus Bildschirmleseprogramm und Browser werden die Informationen zwar wie erwartet bereitgestellt, bei anderen jedoch nicht, was diese Lösung sehr unzuverlässig macht. Autoren müssen sicherstellen, dass untergeordnete Rollen zusammen mit ihren kontextbezogenen oder zugehörigen übergeordneten Rollen angegeben werden.

WAI-ARIA-Fehler Nr. 3: übergeordnete Rollen ohne untergeordnete Rollen

Häufig definieren Autoren eine übergeordnete Rolle, ohne zuvor die erwarteten zugehörigen untergeordneten Rollen festzulegen. Bestimmte Rollen können nicht definiert werden, ohne gleichzeitig ihre zugehörigen untergeordneten Rollen zu definieren. Wenn beispielsweise Menü- oder Menüleisten-Rollen definiert werden, ohne dass die erwarteten untergeordneten Menüpunkt-Rollen für zugehörige Objekte festgelegt sind, können Screenreader die Beziehung möglicherweise nicht wie erwartet vermitteln. Auch hier gilt: Einige Kombinationen aus Bildschirmleseprogramm und Browser stellen die Informationen zwar wie erwartet bereit, andere jedoch nicht, was diese Vorgehensweise zu einer unzuverlässigen Lösung macht. Autoren müssen sicherstellen, dass übergeordnete Rollen zusammen mit ihren kontextbezogenen oder zugehörigen untergeordneten Rollen bereitgestellt werden.

WAI-ARIA-Fehler Nr. 4: Ungültige ID-Wert-Verweise

Häufig stellen wir fest, dass Autoren für bestimmte Attribute falsche oder ungenaue ID-Referenzwerte angeben. Es gibt Attribute, die ausschließlich ID-Referenzen als Werte akzeptieren, beispielsweise die Attribute „aria-labelledby“, „aria-describedby“ und „aria-errormessage“.

Wenn Autoren einen falschen ID-Wert angeben oder eine ID zuweisen, die im Dokument nicht vorhanden ist, können Bildschirmleseprogramme den Verweis nicht erstellen und die Informationen nicht wie erwartet ansagen (z. B. die Beschriftung des Elements, die zugehörigen Anweisungen, die Fehlermeldung usw.). Um solche Situationen zu vermeiden, müssen Autoren sicherstellen, dass die für WAI-ARIA-Attribute definierten ID-Werte gültig sind.

WAI-ARIA-Fehler Nr. 5: Zulässige WAI-ARIA-Attribute fehlen

Häufig beobachten wir, dass Autoren WAI-ARIA-Attribute entgegen den Vorgaben der Spezifikation verwenden, in der Hoffnung, die Barrierefreiheit zu verbessern. Bestimmte Rollen lassen jedoch nur bestimmte Attribute zu. So weisen Autoren beispielsweise dem Anker-/Link-Element möglicherweise das Attribut „aria-selected=“true““ zu, in der irrtümlichen Annahme, dass Screenreader den ausgewählten Status des Ankers/Links ansagen würden.

Da „aria-selected“ gemäß der WAI-ARIA-Spezifikation jedoch bei Link-Elementen nicht zulässig ist, werden Screenreader den ausgewählten Zustand eines solchen Elements NICHT ansagen. Werden „aria-selected“-Attribute hingegen in Verbindung mit bestimmten Rollen wie „treeitem“, „tab“, „gridcell“ usw. verwendet, ist die Benutzererfahrung barrierefrei. Autoren sollten sorgfältig prüfen, ob die Attribute, die sie bestimmten Rollen zuweisen, für diese Rollen zulässig sind.

WAI-ARIA-Fehler Nr. 6: Erforderliche WAI-ARIA-Attribute fehlen

Manchmal stellen wir fest, dass Autoren WAI-ARIA-Rollen definieren, ohne die erwarteten Pflichtattribute anzugeben. Auch hier gilt: Bestimmte WAI-ARIA-Rollen können nicht definiert werden, ohne gleichzeitig die erwarteten Pflichtattribute anzugeben. Wenn beispielsweise die Rolle „slider“ für ein Objekt definiert wird, müssen auch bestimmte Attribute wie „aria-valuemin“, „aria-valuemax“ und „aria-valuenow“ angegeben werden. Andernfalls geben Screenreader die Informationen nicht wie erwartet wieder. Daher müssen Autoren sicherstellen, dass sie alle erwarteten erforderlichen Rollen und Attribute angeben, wenn eine bestimmte WAI-ARIA-Rolle verwendet wird.