Barrierefreiheit nach Framework

Kein JavaScript-Framework macht eine Anwendung barrierefrei, und keines verhindert es. Was sie unterscheiden, sind die Fehler, die sie nahelegen: React die verlorene Fokusverwaltung beim Rendern, Vue die versteckte Semantik in Direktiven, Angular die generierten Wrapper-Elemente, Tailwind den entfernten Fokusring. Vier Probleme sind in allen vier Werkzeugen dieselben – und genau die verursachen den größten Teil der Befunde.

Diese Übersicht ist der Einstieg in vier Einzelseiten. Sie beantwortet zuerst die Frage, die vor der Werkzeugwahl steht: Welche Barrieren entstehen unabhängig vom Framework, und wo lohnt der Blick in die framework-spezifische Anleitung?

Das Wichtigste in Kürze

• Kein Framework ist „barrierefreier“ als ein anderes. Alle rendern am Ende HTML – entscheidend ist, welches.
• Die vier häufigsten Befunde sind überall gleich: fehlende Fokusverwaltung nach Navigation, div statt button, nicht angesagte dynamische Änderungen und Formularfelder ohne verknüpftes Label.
• Client-seitiges Routing bricht die eingebaute Fokusverwaltung des Browsers. Das ist der Befund, den kein Framework von sich aus löst.
• Linting hilft messbar: eslint-plugin-jsx-a11y für React, vue-a11y, das Angular-Template-Linting.
• Komponentenbibliotheken sind der größte Hebel – und die größte Fehlerquelle, wenn sie ungeprüft übernommen werden.
• Tailwind ist kein Framework in diesem Sinne, sondern CSS – erzeugt aber eigene, wiederkehrende Barrieren.
• Stand August 2026.

Die vier Probleme, die überall gleich sind

1. Der Fokus nach einem Seitenwechsel. Bei einem normalen Seitenaufruf setzt der Browser den Fokus zurück an den Dokumentanfang und der Screenreader liest den neuen Titel. Bei client-seitigem Routing passiert nichts von beidem: Die URL ändert sich, der Inhalt wird ausgetauscht, und der Fokus bleibt auf dem Link, den jemand gerade geklickt hat. Wer mit dem Screenreader arbeitet, merkt vom Wechsel nichts.

Die Lösung ist in allen vier Werkzeugen dieselbe: Nach dem Routenwechsel den Titel setzen und den Fokus programmatisch auf die Überschrift der neuen Ansicht legen (oder auf einen Container mit tabindex="-1"). Betroffene Kriterien: 2.4.2 Seitentitel und 2.4.3 Fokus-Reihenfolge.

2. Das nachgebaute Bedienelement. Ein <div onClick={…}> ist in jedem Framework schneller geschrieben als ein <button> – und in jedem Framework gleich kaputt: kein Fokus, keine Tastatur, keine Rolle. Warum das so hartnäckig ist und wie die Entscheidung läuft, steht unter Buttons vs. Links und Die erste Regel von ARIA.

3. Die stille Änderung. Frameworks sind gut darin, Teile der Seite auszutauschen – Filterergebnisse, Ladezustände, Fehlermeldungen. Für Screenreader passiert dabei nichts, solange die Änderung nicht angesagt wird. Zuständig ist 4.1.3 Statusmeldungen, die Umsetzung steht unter Live-Regionen.

4. Das Formularfeld ohne Label. In komponentisierten Formularen wandert das Label gern in eine eigene Komponente und verliert dabei die Verknüpfung – oder die id wird generiert und kollidiert, wenn dieselbe Komponente zweimal auf einer Seite steht. Details unter Labels & Beschriftungen.

Diese vier decken erfahrungsgemäß den größten Teil der Befunde in einer Framework-Anwendung ab. Alles Weitere ist werkzeugspezifisch.

Die vier Einzelseiten

• Barrierefreiheit in React – Fragmente statt Wrapper, htmlFor und useId, Fokusverwaltung mit Refs, eslint-plugin-jsx-a11y, Router-Ankündigungen.
• Barrierefreiheit in Vue – v-show gegen v-if, Attribut-Vererbung, <Teleport> für Dialoge, Router-Guards.
• Barrierefreiheit in Angular – Host-Elemente und generierte Wrapper, das Angular CDK a11y-Paket, LiveAnnouncer, Template-Linting.
• Barrierefreiheit mit Tailwind CSS – der entfernte Fokusring, sr-only, Kontraste aus der Standardpalette, motion-safe/motion-reduce.

Was bei der Werkzeugwahl tatsächlich zählt

Wer die Wahl noch hat, sollte nicht nach dem Framework entscheiden, sondern nach drei anderen Fragen:

Welche Komponentenbibliothek kommt mit? Das ist der mit Abstand größte Hebel. Eine Bibliothek, die Dialoge, Tabs, Comboboxen und Menüs nach dem ARIA Authoring Practices Guide umsetzt, erspart die schwierigsten Eigenbauten. Eine, die es nicht tut, kostet sie doppelt – weil sie erst eingebaut und dann ersetzt werden muss.

Wird serverseitig gerendert? Für Barrierefreiheit ist das weniger entscheidend als oft behauptet, weil Hilfsmittel den fertigen DOM lesen. Für Robustheit schon: Eine Anwendung, die ohne JavaScript eine leere Seite zeigt, ist bei jedem Skriptfehler vollständig unbenutzbar – und wird von Suchmaschinen unzuverlässig erfasst, siehe Semantik & SEO.

Gibt es ein Linting-Setup? Ein Linter fängt einen erheblichen Teil der mechanischen Fehler ab, bevor sie in ein Review kommen – fehlendes alt, onClick ohne Tastaturbedienung, falsche ARIA-Attribute. Was er nicht kann, steht unter Prüfwerkzeuge im Vergleich.

Die vier Werkzeuge im Vergleich

Das Muster in der Tabelle ist aufschlussreich: Angular bringt als einziges Werkzeug fertige Bausteine für die schwierigen Fälle mit, hat dafür aber als einziges ein strukturelles Problem im gerenderten DOM. React und Vue lösen dieselben Aufgaben mit denselben Mitteln – Refs, nextTick/useEffect, native Elemente. Und Tailwind steht quer dazu: Es beeinflusst kein Markup, sondern nur, wie leicht sich zwei bestimmte Fehler machen lassen.

So prüfst du eine Framework-Anwendung

Der Ablauf ist in allen vier Werkzeugen derselbe und dauert etwa eine halbe Stunde:

1. Linter einschalten und die Meldungen abarbeiten – das ist der billigste Schritt und erledigt die mechanischen Fehler, bevor jemand sie im Review sieht.
2. Eine Route wechseln und zuhören. Wird der neue Titel angesagt? Landet der Fokus in der neuen Ansicht? Der Test dauert zehn Sekunden und findet den häufigsten strukturellen Befund.
3. Die Anwendung nur mit der Tastatur bedienen. Jeder Dialog, jedes Menü, jede Combobox – erreichbar, schließbar, Fokus danach an der richtigen Stelle? Details unter Tastaturbedienung & sichtbarer Fokus.
4. Einen Filter oder eine Suche auslösen. Wird das Ergebnis angesagt, oder ändert sich still die Liste? Zuständig ist 4.1.3 Statusmeldungen.
5. Den gerenderten DOM ansehen, nicht das Template. Wrapper-Elemente, Host-Elemente und doppelte IDs sieht man nur dort – der Struktur-Check macht es sichtbar.
6. Ein Formular fehlerhaft absenden und mit einem Screenreader gegenprüfen, was passiert.

Häufiger Fehler in der Praxis

Die Bibliothek als geprüft annehmen. „Accessible by default“ steht in vielen Readme-Dateien. Prüfe eine Komponente selbst, bevor du dreißig davon einbaust – zehn Minuten mit NVDA genügen für die Antwort.

ARIA nachrüsten statt Elemente tauschen. In Komponenten-Code ist der Tausch von div auf button meist eine Zeile. Der ARIA-Nachbau sind zwanzig.

Nur die Komponente testen, nicht die Seite. Storybook-Tests finden Befunde in Isolation. Fokusreihenfolge, Landmarken und doppelte IDs entstehen erst im Zusammenspiel.

Das Framework für den Befund verantwortlich machen. In den allermeisten Fällen ist das gerenderte HTML das Problem, nicht das Werkzeug, das es gerendert hat.

Häufige Fragen

Ist eine Single-Page-Anwendung grundsätzlich weniger barrierefrei?

Nein, aber sie verlangt Arbeit, die eine klassische Website geschenkt bekommt: Titel setzen, Fokus verwalten, Änderungen ansagen. Wer diese drei Dinge löst, hat den strukturellen Nachteil ausgeglichen.

Brauche ich für Barrierefreiheit serverseitiges Rendering?

Für Hilfsmittel nicht – sie lesen den fertigen DOM. Für Robustheit und Auffindbarkeit ist es trotzdem die bessere Wahl.

Welche Komponentenbibliothek ist die beste Wahl?

Die, deren Dokumentation je Komponente das Tastaturmodell nennt und sich auf den ARIA Authoring Practices Guide bezieht. Das ist ein besseres Auswahlkriterium als jede Selbstauskunft – und es lässt sich in fünf Minuten prüfen.

Gilt das alles auch für Svelte, Solid oder Astro?

Weitgehend ja. Die vier Grundprobleme hängen am client-seitigen Rendern, nicht an der Syntax. Die Einzelseiten hier decken die vier verbreitetsten Werkzeuge ab; die Muster lassen sich übertragen.

Verwandte Themen

• Barrierefreiheit nach Plattform – dasselbe für CMS und Shopsysteme
• Die erste Regel von ARIA – das Prinzip hinter allen vier Einzelseiten
• „div-soup“ vermeiden – wie Komponentenbäume Semantik verlieren
• Barrierefreiheit selbst testen – der Prüfablauf um die Entwicklung herum

Quellen

• ARIA Authoring Practices Guide – die Referenzmuster, an denen sich Bibliotheken messen lassen (W3C)
• Using ARIA – die fünf Regeln, u. a. „no ARIA is better than bad ARIA“ (W3C)
• The WebAIM Million – die Fehlerzahlen im Vergleich mit und ohne ARIA