Barrierefreie Apps: die häufigsten WCAG-Fehler in 50 geprüften Apps

Wir haben die Barrierefreiheits-Audits von 50 iOS- und Android-Apps aus dem letzten Jahr ausgewertet, um zu sehen, was barrierefreien Apps noch fehlt.

Die meisten digitalen Barrieren, die wir gefunden haben, gehen auf wenige wiederkehrende Fehler zurück. Fast alle liegen auf der grundlegendsten Stufe der Web Content Accessibility Guidelines (WCAG).

In diesem Artikel lesen Sie, was nicht funktioniert, wie oft es vorkommt und welche Korrekturen die meisten Probleme lösen.

Was sind die häufigsten Barrierefreiheitsfehler in Apps?

Alle vier Fehler fallen auf, sobald man einen Screenreader nutzt.

Welche WCAG-Kriterien verletzen Apps am häufigsten?

Drei Kriterien stehen für sechs von zehn Problemen: 4.1.2 Name, Rolle, Wert; 1.3.1 Info und Beziehungen; 2.4.3 Fokus-Reihenfolge. Alle drei gehören zu Stufe A. Alle drei entscheiden, ob ein Screenreader einen Bildschirm sinnvoll wiedergeben kann.

Im gesamten Datensatz verletzen 84 % der Probleme Kriterien der Stufe A und 16 % Kriterien der Stufe AA. Auch die Schwere ist hoch: Jede App hatte mindestens ein als kritisch eingestuftes Problem.

4.1.2 Name, Rolle, Wert verlangt, dass jedes interaktive Element mitteilt, was es ist (die Rolle), wie es heißt (der Name) und in welchem Zustand es sich befindet. Ist das Kriterium verletzt, hören Screenreader-Nutzer:innen „Taste“ ohne Beschriftung oder eine Beschriftung ohne Hinweis, dass sich das Element antippen lässt. Die vollständige Anforderung finden Sie auf der Seite Understanding 4.1.2 des W3C (auf Englisch).

1.3.1 Info und Beziehungen ist verletzt, wenn die sichtbare Struktur nicht bei den assistiven Technologien ankommt: Texte, die wie Überschriften aussehen, aber nicht als solche ausgezeichnet sind, oder Beschriftungen, die nicht mit ihren Feldern verknüpft sind. 2.4.3 Fokus-Reihenfolge ist verletzt, wenn der Screenreader in einer Reihenfolge über den Bildschirm springt, die nicht zum sichtbaren Aufbau passt.

Welche WCAG-Kriterien sollten Sie in Apps zuerst beheben?

Beginnen Sie mit 4.1.2, 1.3.1 und 2.4.3, die fast jede App betreffen. Danach folgen diese Kriterien:

• 1.1.1 Nicht-Text-Inhalt: Bilder und Symbole mit Bedeutung brauchen eine Textalternative.

• 2.1.1 Tastatur: Alles muss auch mit einer Tastatur oder einem anderen externen Eingabegerät funktionieren, nicht nur per Touch.

• 1.4.3 Kontrast (Minimum): Text muss sich deutlich vom Hintergrund abheben.

• 1.4.4 Textgröße ändern: Beim Vergrößern der Schrift darf nichts abgeschnitten werden.

• 1.3.4 Ausrichtung: Die App muss im Hoch- und im Querformat funktionieren.

Sie müssen nicht alles auf einmal beheben. Eine solide semantische Struktur mit Namen, Rollen, Zuständen und einer logischen Fokus-Reihenfolge macht Ihre App mit Tastatur, Joystick, Sprachsteuerung und Screenreader bedienbar.

Wie beheben Sie die häufigsten Barrierefreiheitsfehler in Apps?

Die Korrekturen aus den Audits passen zu den häufigsten Fehlern. So beheben Sie jeden davon.

1. Jedem Bedienelement die richtige Rolle geben

   Behebt Bedienelemente ohne Rolle oder mit falscher Rolle. Legen Sie Rollen über die Barrierefreiheits-API der jeweiligen Plattform fest: accessibilityTraits unter iOS, AccessibilityNodeInfoCompat.setClassName() unter Android, accessibilityRole in React Native und Semantics in Flutter.

2. Jedem Bedienelement einen klaren zugänglichen Namen geben

   Behebt Bedienelemente ohne zugänglichen Namen. Setzen Sie ein aussagekräftiges accessibilityLabel unter iOS und eine contentDescription unter Android, vor allem bei Buttons, die nur aus einem Symbol bestehen.

3. Die Mindestwerte für Kontrast einhalten

   Verwenden Sie ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text sowie für Symbole, Rahmen und Zustandsanzeigen, die Informationen tragen. Prüfen Sie den hellen und den dunklen Modus.

4. Den Fokus auf den neuen Inhalt setzen

   Behebt die Navigationsleiste am unteren Rand, die Menschen mit Screenreader auf der Leiste festhält. Unter iOS legen Sie accessibilityElements in der richtigen Reihenfolge fest. Unter Android bestimmen Sie die Fokus-Reihenfolge mit nextFocusDown/Up/Left/Right im XML oder mit focusProperties in Compose. In React Native verschieben Sie den Fokus mit AccessibilityInfo.setAccessibilityFocus.

5. Zusammengehörige Elemente zu einer Komponente gruppieren

   Behebt Karten, die mehrere Wischgesten zum Vorlesen brauchen. Eine Produktkarte aus Bild, Titel und Preis sollte ein einziger Fokuspunkt sein, nicht vier. Unter iOS setzen Sie isAccessibilityElement auf dem übergeordneten Element und geben der Gruppe eine Beschriftung. Unter Android nutzen Sie android:screenReaderFocusable auf dem Container.

Native Komponenten übernehmen davon schon vieles. Wer eigene Bedienelemente baut, muss Rolle, Name und Zustand selbst festlegen.

Was das für die Konformität mit dem EAA bedeutet

Apps für Verbraucher:innen in der Europäischen Union unterliegen denselben Regeln wie Websites. Seit dem 28. Juni 2025 verlangt der European Accessibility Act (EAA) barrierefreie Apps für Dienste in seinem Anwendungsbereich, etwa Banking, E-Commerce und Personenverkehr. In Deutschland setzt das Barrierefreiheitsstärkungsgesetz (BFSG) den EAA um, in Österreich das Barrierefreiheitsgesetz (BaFG). Die technischen Anforderungen bauen auf den WCAG auf. Wann eine App konkret darunter fällt, erklärt unser Leitfaden zur App-Barrierefreiheit.

Gemessen an den WCAG erreichen die meisten geprüften Apps noch nicht die Grundlage, auf der jeder weitere Standard aufbaut. Automatisierte Tools finden einen Teil davon, zum Beispiel zu geringen Kontrast. Ob eine Beschriftung Sinn ergibt oder ob der Fokus nach dem Antippen an der richtigen Stelle landet, können sie nicht beurteilen. Deshalb empfehlen wir in unserem Vergleich von manuellen und automatisierten Tests, beides zu kombinieren.

Methodik: woher stammen die Daten?

Die Auswertung basiert auf den Barrierefreiheits-Audits von 50 Apps. Das App-Team von Accessiway hat sie im letzten Jahr für Organisationen in ganz Europa durchgeführt. Insgesamt haben die Audits 6.652 Probleme erfasst.

Barrierefreiheit von Apps bedeutet, dass die Bildschirme einer App für alle Menschen wahrnehmbar, bedienbar, verständlich und robust sind. Das gilt auch für Menschen, die Screenreader, externe Tastaturen, Schaltersteuerung oder vergrößerten Systemtext nutzen, und für alle, die ihr Gerät nicht drehen können.

Unsere Auditor:innen prüfen jede App nach WCAG 2.2 Stufe AA und stufen jedes Problem als kritisch, hoch, mittel oder niedrig ein.

So haben wir gezählt:

• Bei den WCAG-Kriterien zählt jede App einmal, egal wie viele Probleme sie hat.

• Die häufigsten Fehler stammen aus der Auswertung der Audit-Berichte durch das App-Team, das Probleme mit ähnlicher Beschreibung zusammenfasst. Die Prozentwerte sind Mindestwerte: Jeder Fehler kam mindestens im angegebenen Anteil der Apps vor.

• Die Zahl der Probleme hängt davon ab, wie viele Bildschirme und Abläufe ein Audit abgedeckt hat. Deshalb ordnen wir nach der Zahl der betroffenen Apps, nicht nach der Gesamtmenge.

• Die Spalte „Anteil an allen Problemen“ zählt einzelne Vorkommen. Ein verbreiteter Fehler, der pro App nur einmal auftritt, fällt in dieser Spalte kaum ins Gewicht.

• Wir nennen keine der Apps.

Häufige Fragen zu Barrierefreiheitsfehlern in Apps

Gelten die WCAG auch für Apps?

Ja. Die WCAG wurden für das Web geschrieben, aber die EN 301 549, die europäische Norm für barrierefreie IKT, wendet ihre Erfolgskriterien auch auf mobile Software an. Manche Kriterien müssen außerhalb des Browsers ausgelegt werden. Das erklärt das W3C in seinem Leitfaden zur Anwendung der WCAG auf Software außerhalb des Webs (auf Englisch).

Was ist der häufigste Barrierefreiheitsfehler in Apps?

Fehler rund um WCAG 4.1.2 Name, Rolle, Wert: Bedienelemente ohne zugänglichen Namen oder mit fehlender oder falscher Rolle. Mindestens 92 % der geprüften Apps hatten einen dieser Fehler.

Welche WCAG-Stufe verletzen Apps am häufigsten?

Stufe A, die grundlegendste Stufe der WCAG. Ihre Kriterien legen fest, ob Menschen jedes Element erkennen, erreichen und bedienen können.

Wo fangen Sie an?

Die Korrekturen sind bekannt und auf beiden Plattformen wiederholbar.

1. Buchen Sie ein Barrierefreiheits-Audit für Ihre App, das jedes Problem den WCAG 2.2 zuordnet und Tests mit Menschen mit Behinderungen umfasst.

2. Beheben Sie zuerst die Probleme der Stufe A in Ihren meistgenutzten Abläufen.

3. Verankern Sie Rollen, Namen und Zustände in den gemeinsamen Komponenten Ihres Designsystems, damit neue Bildschirme sie übernehmen.

4. Prüfen Sie jede neue Version mit dem Screenreader, bevor sie erscheint. So bringen Updates keine behobenen Barrieren zurück.

Weiterführende Ressourcen

• Lesen Sie, wie Lavazza seine iOS- und Android-Apps barrierefrei gemacht hat

• Erfahren Sie, welche Barrieren 3.500 Menschen in Deutschland und Österreich am Smartphone erleben

• Testen Sie Ihre App mit Menschen, die assistive Technologien nutzen

Sie möchten wissen, wo Ihre digitalen Produkte stehen? Sprechen Sie mit unserem Team über eine Compliance-Plattform für Barrierefreiheit, die Ihnen laufend Transparenz und Werkzeuge für die Barrierefreiheit gibt.

Inhalt, der mit Unterstützung künstlicher Intelligenz erstellt und einer menschlichen Überwachung und Überprüfung unterzogen wurde