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.
JavaScript und Barrierefreiheit
In den Web Content Accessibility Guidelines (WCAG) 1.0 aus dem Jahr 1999 gab es tatsächlich die Anforderung, dass Webseiten auch ohne JavaScript funktionieren sollten. Damals funktionierten die beiden gängigen Browser Internet Explorer und Netscape aber auch unterschiedlich. Scripts für den einen Browser funktionierten nicht unbedingt für den anderen; außerdem waren Browser ohne JavaScript-Funktionalität durchaus im Umlauf. Es war die Idee des „Graceful degradation“, die die Zugänglichkeit bei abgeschaltetem JavaScript vorgab.
JavaScript und Barrierefreiheit werden bis heute als ambivalente Beziehung gesehen. Immer wieder wurde behauptet, dass Screenreader mit JavaScript nicht umgehen konnten und tatsächlich gab es schon vereinzelte Probleme auf dynamischen Webseiten. Grundsätzlich ist es aber so, dass Screenreader sich an den DOM des Browsers orientieren. JavaScript ist seitdem ich mich mit barrierefreiem Webdesign beschäftige (immerhin sind es inzwischen über 15 Jahre) nicht ein Problem für die Zugänglichkeit durch Screenreader.
Was ein Problem darstellen kann, ist die dynamische Veränderung von Webseiten. Sowohl bei Screenreadernutzern und bei Nutzern von Vergrößerungssystemen können Veränderungen des DOM unbemerkt bleiben, weil der Fokus (im Screenreader) oder der Vergrößerungsausschnitt (in einem Vergrößerungssystem) an einer anderen Stelle der Seite sind als die veränderten Inhalte. Es ist deshalb sinnvoll, Änderungen des Inhalts erst durch eine Aktion des Nutzers zu initiieren.
In den 0er Jahren wurde zunehmend die Idee „Progressive Enhancement“ postuliert, was „Graceful degradation“ immer mehr verdrängte. Mit den Web Content Accessibility Guidelines (WCAG) 2.0 aus dem Jahr 2008 verschwand auch die Anforderung, dass Webseiten ohne JavaScript funktionieren müssen, um barrierefrei zu sein.
Das Problem mit jQuery
JavaScript selbst ist nicht das Problem. Wie auch bei HTML kann mit JavaScript sinnvoller oder fehlerhafter Code geschrieben werden. Wer JavaScript-Code schreibt muss selbstverständlich auch das kleine 1×1 von HTML beherrschen, um nutzbare Webseiten zu produzieren. Wie sehr das Unwissen unter Entwicklern ist, hat Jens Grochtdreis vor zwei Monaten in einem Blogbeitrag moniert.
Und genauso können JavaScript-Bibliotheken genutzt werden. Die Qualität des Ergebnisses ist nicht von jQuery abhängig, sondern was die Entwickler von Plug-Ins oder Anwendungen daraus machen.
jQuery ist wahrscheinlich die am Häufigsten eingesetzte JavaScript-Bibliothek nicht zuletzt wegen der umfangreichen Dokumentation. Der Einstieg ist leicht und inzwischen ist die Zahl an Plug-Ins vielfältig. Gerade bei den Plug-Ins stellt sich aber immer wieder die gleiche Frage: Sind sie barrierefrei? Leider ist die Antwort viel zu oft „Nein“ – was im Übrigen auch für zahlreiche „accessible“ Plug-Ins gilt.
Bevor Plug-Ins für jQuery eingesetzt werden muss die Qualität des Codes überprüft werden. Für die Barrierefreiheit spielt die Semantik eine Rolle, aber auch andere Aspekte sollten überprüft werden wie etwa Umfang des HTML- oder CSS-Codes. Für die Barrierefreiheit muss insbesondere geprüft werden:
- Sind aktive Elemente vollständig per Tastatur bedienbar? Diese Überprüfung kann in einem gängigen Browser erfolgen und sollte vollständig für alle Prozesse überprüft werden.
- Wird die Semantik der erzeugten Inhalte korrekt angegeben? Hier stehen wir gleich vor zwei Problemen:
- Zum einen wird die Semantik oft nicht mit nativem HTML, sondern mit ARIA-Attributen bestimmt; leider werden in vielen Fällen die ARIA-Attribute nicht dosiert, sondern eimerweise in den Code gekippt.
- Zum anderen können Elemente und Attribute im DOM überprüft werden, aber eigentlich – was oft auch mit dem ersten Problem zusammenhängt – muss die Semantik im Accessibility-Tree des Betriebssystems oder besser mit einem Screenreader überprüft werden.
Die Lösung ist HTML, nicht ARIA
Auch wenn ich mich jetzt ein wenig aus dem Fenster lehne, die meisten eingesetzten ARIA-Attribute sind überflüssig oder falsch eingesetzt. In zahlreichen Projekten, in denen ich die Barrierefreiheit von Anwendungen überprüfe, verbringe ich die meiste Zeit damit, die Entwickler dazu zu bringen, die ARIA-Attribute aus dem Code rauszuschmeißen und vernünftiges HTML einzusetzen. Nur dort, wo HTML nicht die erforderliche Semantik bietet, kommt ARIA überhaupt in Frage.