Barrierefreiheit mobiler Apps: WCAG-2.2-Anforderungen für iOS und Android

Über 72% der Erwachsenen mit Behinderungen besitzen ein Smartphone, und laut einer Umfrage verlassen sich rund 86% der Screenreader-Nutzer auf ein mobiles Gerät – ein höherer Anteil als bei Desktop- oder Laptop-Nutzern. Dennoch haben dieselben Organisationen, die ihre Websites gewissenhaft prüfen lassen, häufig mobile Apps, die noch nie gegen ein einziges Barrierefreiheitskriterium getestet wurden. Diese Lücke schließt sich schnell, getrieben durch sich weiterentwickelnde Regulierung, zunehmende Klagen und – am wichtigsten – die explizite W3C-Leitlinie, die WCAG 2.2 direkt auf native iOS- und Android-Anwendungen abbildet.

Warum WCAG 2.2 für Ihre Mobile App gilt

Es hält sich hartnäckig der Mythos, dass WCAG ein reiner Web-Standard sei. Das ist er nicht. Das W3C hat keine separaten Richtlinien für mobile Barrierefreiheit – stattdessen wird mobile Barrierefreiheit im bestehenden WCAG-Rahmen behandelt, und die Mobile Accessibility Task Force (MATF) des W3C hat eine eigene Leitlinie mit dem Titel Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) erstellt, die jedes Erfolgskriterium der Stufen A und AA auf native Mobile Apps, mobile Web-Apps und hybride Apps abbildet.

Die praktische Auswirkung ist erheblich. Wenn Sie ein WCAG-Erfolgskriterium lesen, das sich auf eine „Webseite“ bezieht, ersetzt das WCAG2Mobile-Dokument diese Formulierung durch „Screen“ oder „View“. Wenn ein Kriterium einen „User Agent“ erwähnt, ist damit das mobile Betriebssystem gemeint. Die vier POUR-Prinzipien – Perceivable, Operable, Understandable, Robust – übertragen sich direkt darauf, wie ein Nutzer mit einer SwiftUI-View in iOS oder einem Jetpack-Compose-Layout auf Android interagiert.

Aus rechtlicher Sicht ist der Druck nicht mehr theoretisch. Nach Title II des ADA verlangen die im April 2024 aktualisierten DOJ-Vorschriften ausdrücklich, dass staatliche und kommunale Behörden ihre mobilen Anwendungen auf WCAG 2.1 AA-Niveau barrierefrei machen. Gesundheitsorganisationen, die Medicare oder Medicaid akzeptieren, unterliegen ähnlichen Anforderungen nach den HHS-Regeln, die im Mai 2024 finalisiert wurden. Und obwohl Klagen gegen mobile Apps im privaten Sektor noch seltener sind als gegen Websites, hat mindestens ein Kläger mit hohem Klagevolumen gezielt mobile Anwendungen wegen mangelndem gleichberechtigtem Zugang nach dem ADA ins Visier genommen; es wird erwartet, dass sich dieser Trend beschleunigt, wenn die Title-II-Compliance-Fristen 2026 in Kraft treten.

Der European Accessibility Act (EAA), der am 28. Juni 2025 in Kraft trat und EN 301 549 als vermuteten technischen Standard heranzieht, verlangt ebenfalls Konformität mit WCAG 2.2 für digitale Produkte und Dienstleistungen, einschließlich mobiler Apps, die in EU-Märkten verkauft oder angeboten werden. Für jede Organisation mit globaler Nutzerbasis ist WCAG 2.2 auf Mobilgeräten keine zukünftige Zielsetzung – es ist eine aktuelle Verpflichtung.

Was sich in WCAG 2.2 geändert hat und für Mobile am wichtigsten ist

WCAG 2.2, im Oktober 2023 als W3C-Empfehlung veröffentlicht, fügt neun neue Erfolgskriterien hinzu und entfernt das inzwischen veraltete 4.1.1 Parsing. Es ist vollständig abwärtskompatibel: Konformität mit 2.2 impliziert Konformität mit 2.1 und 2.0. Mehrere der neuen Kriterien wurden ausdrücklich mit Blick auf mobile Interaktionsmuster formuliert, und selbst jene, die auf Tastaturnutzung ausgerichtet sind, haben direkte Entsprechungen in unterstützender Technologie für iOS und Android.

Es lohnt sich, die Entwicklungslinie zu verstehen. Nach 2018 stellte die Mobile Accessibility Task Force sicher, dass mobile Aspekte sowohl WCAG 2.1 als auch 2.2 prägten. Kriterien wie 1.3.4 Orientation (AA), 1.4.10 Reflow (AA), 2.5.1 Pointer Gestures (A), 2.5.4 Motion Actuation (A) und die neuen 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA) und 3.3.7 Redundant Entry (A) spiegeln alle spezifische mobile Usability-Muster wider, die durch Tests in realen Szenarien mit Nutzerinnen und Nutzern mit Behinderungen auf Smartphones und Tablets identifiziert wurden.

Die neun neuen Erfolgskriterien in WCAG 2.2 zielen auf konkrete Barrieren, denen reale Nutzer begegnen: Login-Flows, die Menschen mit Gedächtnisproblemen benachteiligen, Oberflächen, die ruhige Hände für präzise Taps verlangen, Hilfefunktionen, die auf jedem Screen an anderer Stelle versteckt sind, und Fokusindikatoren, die hinter fixierten Navigationsleisten verschwinden. Jedes Kriterium schließt eine konkrete Lücke – und fast alle haben eine direkte mobile Anwendung.

Die neuen WCAG-2.2-Kriterien und wie sie auf iOS und Android angewendet werden

2.5.8 Target Size Minimum (Level AA)

Dies ist vermutlich das wirkungsvollste neue Kriterium für Mobile-Teams. Es verlangt, dass interaktive Ziele – Buttons, Links, Formularfelder, Checkboxen, Schalter – eine Mindestgröße von 24 × 24 CSS-Pixeln haben oder dass ein Abstandsoffset von 24 Pixeln zwischen benachbarten Zielen besteht, wenn das Ziel selbst kleiner ist. Die Begründung ist einfach: Nutzer mit Handzittern, Parkinson oder eingeschränkter Feinmotorik können einen 16-Pixel-Icon-Button faktisch nicht zuverlässig treffen, und selbst Nutzer ohne Behinderungen machen bei kleinen Zielen deutlich mehr Fehler.

Für native Mobile-Entwicklung ist das 24 × 24-Minimum von WCAG 2.2 tatsächlich eine Untergrenze, kein Deckel. Apples Human Interface Guidelines empfehlen ein minimales Touch-Ziel von 44 × 44 Punkten auf iOS und iPadOS. Googles Material Design empfiehlt 48 × 48 density-independent pixels (dp) auf Android. Wenn Ihre App die Plattformempfehlungen von Apple oder Google erfüllt, übertrifft sie bereits das WCAG-2.2-Minimum – aber viele Apps tun das nicht. Diese winzigen Schließen-Buttons auf Modals, die haarfeinen Checkboxen in Einstellungs-Screens und die reinen Icon-Toolbar-Aktionen mit 20 × 20 dp sind alles Compliance-Verstöße, die nur darauf warten, in einem Audit aufgedeckt zu werden.

Ein praktischer Hinweis: Die WCAG-Anforderung bezieht sich auf die interaktive Trefferfläche, nicht auf die visuelle Größe des Icons. Ein 16-Punkt-Icon, das auf jeder Seite von 14 Punkten Padding umgeben ist, hat ein effektives Tap-Ziel von 44 × 44 Punkten. Das bedeutet, dass Entwickler das Kriterium erfüllen können, ohne Elemente visuell zu vergrößern – sie müssen dieses Padding aber bewusst setzen und dürfen sich nicht darauf verlassen, dass das System dies automatisch übernimmt.

2.5.7 Dragging Movements (Level AA)

Dieses Kriterium verlangt, dass jede Funktionalität, die über eine Drag-Geste implementiert ist – Slider, Drag-and-Drop-Sortierung, Pull-to-Refresh, Scrubbing in Carousels – auch über eine Ein-Pointer-Aktion ohne Dragging erreichbar sein muss. Auf iOS und Android behandeln die plattformeigenen unterstützenden Technologien bestimmte Gesten unterschiedlich, aber die App selbst muss nicht-drag-basierte Alternativen für jede benutzerdefinierte Drag-Funktion bereitstellen, die sie implementiert.

In der Praxis bedeutet dies, dass eine Drag-to-Reorder-Liste eine Alternative wie etwa „Hoch/Runter“-Stepper-Buttons anbieten muss. Ein benutzerdefinierter Bereichsslider, der nur auf Drag-Gesten reagiert, muss auch auf Taps an bestimmten Punkten reagieren oder Inkrement-/Dekrement-Buttons bereitstellen. Das Kriterium gilt nicht, wenn das zugrunde liegende Betriebssystem oder die unterstützende Technologie die Alternative automatisch bereitstellt, aber Entwickler sollten dies explizit testen, statt anzunehmen, dass dies immer für sie erledigt wird.

2.4.11 Focus Not Obscured – Minimum (Level AA) und 2.4.12 (Enhanced, Level AAA)

Diese Kriterien adressieren ein Muster, das sowohl in Web- als auch in nativen Mobile-Apps äußerst verbreitet ist: Das fokussierte Element wird teilweise oder vollständig von „sticky“ UI verdeckt – einer persistenten unteren Navigationsleiste, einem Floating Action Button, einer oberen Toolbar, die den Scrollbereich überlappt. Das Mindestkriterium (Level AA) verlangt, dass beim Erhalt des Fokus zumindest ein Teil der Komponente sichtbar bleibt. Die erweiterte Version (Level AAA) verlangt, dass die gesamte fokussierte Komponente sichtbar ist.

Für native Mobile-Umgebungen wird „Tastaturfokus“ weit ausgelegt und umfasst den Fokusring, der von Switch Control oder Switch Access, Full Keyboard Access (iOS 15+) und Voice Control/Access verwendet wird. Eine App, in der das fokussierte Element während eines Switch-Control-Durchlaufs unter eine untere Navigationsleiste rutscht, verstößt gegen dieses Kriterium, auch wenn keine physische Tastatur im Spiel ist. App-UIs sollten vermeiden, fokussierte Steuerelemente mit selbst erstellten Overlays, fixierten Leisten oder transienten Oberflächen zu überdecken.

2.4.13 Focus Appearance (Level AA)

Dieses Kriterium legt Mindestanforderungen an die visuellen Eigenschaften des Fokusindikators fest: Er muss eine Mindestfläche haben, die dem Umfang der Komponente × 2 CSS-Pixel entspricht, und ein Kontrastverhältnis von mindestens 3:1 zu angrenzenden Farben aufweisen. Auf nativen Mobilplattformen wird der Fokusring für VoiceOver und TalkBack vom Betriebssystem gesteuert, und Entwickler können sein Aussehen nicht verändern – was bedeutet, dass Entwickler für dieses spezifische Kriterium im Allgemeinen eine Ausnahme erhalten. Allerdings darf das App-Styling die Sichtbarkeit des Fokus nicht aktiv verringern, etwa indem ein halbtransparenter Scrim über fokussierte Steuerelemente gelegt wird.

3.3.8 Accessible Authentication – Minimum (Level A)

Dieses Kriterium stellt einen großen Schritt für kognitive Barrierefreiheit dar. Es verlangt, dass Authentifizierungsprozesse sich nicht ausschließlich auf einen Test kognitiver Fähigkeiten stützen – das heißt, der Nutzer darf nicht gezwungen sein, sich ein Passwort zu merken, ein Rätsel zu lösen oder ein CAPTCHA abzutippen –, es sei denn, die App bietet eine barrierefreie Alternative. Auf iOS bedeutet dies die Unterstützung von Apples Keychain und „Sign in with Apple“, damit Nutzer sich authentifizieren können, ohne sich Zugangsdaten merken zu müssen. Auf Android bedeutet es die Unterstützung des Google-Autofill-Frameworks, biometrischer Authentifizierung und die Nicht-Blockierung von Drittanbieter-Passwortmanagern.

Konkreter: Wenn Ihre App das Einfügen in Passwortfeldern blockiert, ist sie wahrscheinlich nicht konform mit 3.3.8. Wenn Ihr Zwei-Faktor-Authentifizierungs-Flow verlangt, dass der Nutzer einen OTP-Code aus einer Benachrichtigung manuell eintippt, ohne eine Copy-and-Paste-Möglichkeit zu bieten, erzeugt dies eine unnötige kognitive Belastung. Die Android-App „Messages“ bietet aus genau diesem Grund bereits einen „Code kopieren“-Button in OTP-Benachrichtigungen – und stimmt damit das Plattformverhalten mit der Intention des Kriteriums ab.

Wichtige Erkenntnis: Die Unterstützung biometrischer Authentifizierung (Face ID, Touch ID, Android Biometric API) ist nicht nur eine UX-Verbesserung – sie ist ein WCAG-2.2-Compliance-Mechanismus für Nutzer mit kognitiven Beeinträchtigungen, die sich Passwörter nicht zuverlässig merken können.

3.3.7 Redundant Entry (Level A)

Wenn ein mehrstufiger Flow in Ihrer App – Checkout, Onboarding, ein Aufnahmeformular im Gesundheitsbereich – den Nutzer auffordert, dieselben Informationen mehr als einmal einzugeben, müssen Sie entweder den zuvor eingegebenen Wert automatisch ausfüllen oder eine Möglichkeit bieten, ihn aus früheren Eingaben auszuwählen. Dieses Kriterium ist direkt auf native Mobile-Apps anwendbar. Der klassische Fehlerfall ist ein Versandadressenformular, das später nach einer Rechnungsadresse fragt, ohne eine Option „gleich wie Versandadresse“ anzubieten, wodurch Nutzer mit motorischen oder kognitiven Beeinträchtigungen gezwungen werden, denselben Text mehrfach neu zu tippen.

3.2.6 Consistent Help (Level A)

Wenn Ihre App einen Hilfe-Mechanismus bereitstellt – einen Support-Chat-Button, ein Hilfe-Icon, einen „Kontakt“-Link –, muss dieser an einer konsistenten Stelle auf allen Screens innerhalb der App erscheinen. Nutzer mit kognitiven Beeinträchtigungen sind auf die vorhersehbare Platzierung von Navigation und Support-Mechanismen angewiesen. Den Hilfe-Button auf manchen Screens im Header und auf anderen in der Tab-Bar zu platzieren oder ihn in bestimmten Flows in einem Einstellungsmenü zu verstecken, verstößt gegen dieses Kriterium.

WCAG-2.1-Kriterien, die für Mobile weiterhin entscheidend sind

Die neuen WCAG-2.2-Kriterien erhalten die meiste Aufmerksamkeit, aber mehrere WCAG-2.1-Anforderungen, die speziell mit Blick auf Mobile eingeführt wurden, werden in nativen Apps weiterhin regelmäßig verfehlt, und Compliance-Verantwortliche sollten sie bei Audits nicht übersehen.

1.3.4 Orientation (AA) verbietet es, eine App auf Hoch- oder Querformat zu sperren, sofern diese Ausrichtung nicht für die Funktion des Inhalts wesentlich ist. Viele Apps sperren während Onboarding-Flows oder in In-App-Videoplayern auf Hochformat, ohne dass dies gerechtfertigt wäre. Dies betrifft überproportional Nutzer mit rollstuhlbefestigten Geräten, die nicht gedreht werden können. 1.4.10 Reflow (AA) verlangt, dass Inhalte ohne horizontales Scrollen dargestellt werden können, wenn sie mit 320 CSS-Pixeln Breite (entspricht 400% Zoom) angezeigt werden, was im Mobile-Kontext bedeutet, Dynamic Type und systemweite Textgrößenanpassung zu unterstützen, ohne Layouts zu zerstören oder Inhalte abzuschneiden.

2.5.1 Pointer Gestures (A) verlangt, dass jede Funktionalität, die Mehrpunkt- oder pfadbasierte Gesten nutzt – Pinch-to-Zoom, Zwei-Finger-Swipe – auch eine Ein-Pointer-Alternative hat. 2.5.4 Motion Actuation (A) verlangt, dass Funktionalität, die durch Schütteln oder Neigen des Geräts ausgelöst wird, auch über Standard-UI-Steuerelemente bedient werden kann und dass Nutzer bewegungsbasierte Auslöser deaktivieren können, um unbeabsichtigte Aktivierungen zu vermeiden.

Für die visuelle Darstellung verlangt 1.4.3 Contrast Minimum (AA) ein Verhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text. Viele Apps scheitern hier weiterhin, weil Platzhaltertext in Eingabefeldern, Beschriftungen deaktivierter Buttons und Text auf fotografischen Hintergründen unter dem Minimum liegen. Entwickler sollten sicherstellen, dass alle Texte, Steuerelemente und Inhalte mit Dynamic Type, Fettschrift, Dark Mode und systemweiten Kontrastoptionen auf iOS und Android funktionieren.

Plattformspezifische Implementierungsleitlinien

iOS und SwiftUI / UIKit

Apple bietet umfangreiche native Barrierefreiheitsunterstützung über die UIAccessibility-API und in SwiftUI über Accessibility-Modifier. Für VoiceOver-Unterstützung muss jedes interaktive Element ein aussagekräftiges Accessibility-Label, einen Hinweis (Hint) und einen Wert haben. Benutzerdefinierte Steuerelemente, die nicht von Standard-UIKit-Komponenten erben, müssen explizit ein geeignetes Accessibility-Trait übernehmen – .isButton, .isHeader, .isLink –, damit VoiceOver sie korrekt ankündigt. Der Xcode Accessibility Inspector kann helfen, fehlende Labels und Trait-Mismatches während der Entwicklung aufzudecken.

Für Dynamic Type skalieren die Systemschriften UIFont.preferredFont(forTextStyle:) in UIKit und .font(.body) in SwiftUI automatisch mit der bevorzugten Textgröße des Nutzers. Hart codierte Schriftgrößen in Punkten, die scaledValue(for:) nicht verwenden, werden 1.4.4 Resize Text verfehlen. Für Zielgrößen können Sie die tappbare Fläche eines kleinen Icons mit contentEdgeInsets in UIKit oder dem Modifier .contentShape() in SwiftUI vergrößern, ohne die visuelle Darstellung des Elements zu ändern.

// SwiftUI: Tap-Fläche vergrößern, ohne die visuelle Größe zu ändern
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android und Jetpack Compose / Views

Die Barrierefreiheit von Android wird über die AccessibilityNodeInfo-API bereitgestellt, die von TalkBack und Switch Access genutzt wird. In Jetpack Compose ermöglicht der Block Modifier.semantics das Setzen von Content Descriptions, Rollen, Zustandsbeschreibungen und das Zusammenführen von Semantik-Nachkommen. Für View-basierte UIs erlaubt ViewCompat.setAccessibilityDelegate() die programmatische Manipulation von Barrierefreiheits-Eigenschaften für jede View.

Für Touch-Zielgrößen empfiehlt die Material-Design-Leitlinie mindestens 48 × 48 dp. Wenn ein Composable oder eine View visuell kleiner ist, können Sie in Compose Modifier.minimumInteractiveComponentSize() (eingeführt in Material3) verwenden, um automatisch ein Minimum von 48 dp durchzusetzen, oder eine kleine View in einen TouchDelegate einbetten, um ihre Trefferfläche im Legacy-View-System zu vergrößern. Für Textskalierung sollten alle Textgrößen in sp (scale-independent pixels) und nicht in dp angegeben werden, damit sie die in den Android-Display-Einstellungen festgelegten Schriftgrößenvorlieben des Nutzers respektieren.

// Jetpack Compose: barrierefreier Icon-Button mit Mindestgröße
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // erzwingt mindestens 48dp
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // wird vom Eltern-Element beschrieben
    )
}

Testen Ihrer App gegen WCAG 2.2

Das Testen mobiler Barrierefreiheit erfordert eine Kombination aus automatisierten Tools und manuellen Tests mit realen unterstützenden Technologien. Automatisierte Tools – darunter Deques axe DevTools Mobile, Googles Accessibility Scanner für Android und Apples Accessibility Inspector in Xcode – können fehlende Labels, unzureichenden Kontrast und Touch-Ziele unterhalb der Plattformminima erkennen. Allerdings erfassen automatisierte Tools nur einen Bruchteil der tatsächlichen Barrierefreiheitsprobleme. Manuelle Tests mit VoiceOver auf iOS und TalkBack auf Android sind unerlässlich, um korrekte Lesereihenfolge, aussagekräftige Labels und eine logische Fokusverwaltung über komplexe Flows hinweg zu verifizieren.

Für die spezifischen WCAG-2.2-Kriterien ist manuelles Testen besonders wichtig. Um 2.5.8 (Target Size) zu testen, verwenden Sie Ihren tatsächlichen Finger – nicht den Mauszeiger im iOS-Simulator –, um Interaktionen mit kleinen Steuerelementen zu versuchen. Um 3.3.8 (Accessible Authentication) zu testen, vergewissern Sie sich, dass Ihr Login-Flow das Einfügen in Passwortfeldern erlaubt, Passwortmanager (1Password, Bitwarden, System-Keychain) unterstützt und biometrische Authentifizierung ermöglicht. Um 2.4.11 (Focus Not Obscured) zu testen, navigieren Sie Ihre App ausschließlich über Switch Control auf iOS oder Switch Access auf Android und stellen Sie sicher, dass kein fokussiertes Element hinter einer Navigationsleiste, einem Modal-Overlay oder einem Floating Button verschwindet.

Ein umfassender Barrierefreiheitstestplan sollte Tests auf mindestens zwei physischen Geräten umfassen – einem iPhone und einem Android-Gerät – bei der Standard-Schriftgröße des Nutzers und bei maximaler Systemschriftgröße, mit jeweils aktiviertem VoiceOver bzw. TalkBack. Reine Simulator-Tests werden reale Unterschiede im Rendering und im Verhalten unterstützender Technologien nicht aufdecken.

Erwägen Sie, Barrierefreiheitsprüfungen in Ihre CI/CD-Pipeline zu integrieren. Sowohl Espresso (Android) als auch XCUITest (iOS) unterstützen das Schreiben automatisierter UI-Tests, die Barrierefreiheits-Eigenschaften – Content Descriptions, Traits und Aktivierungszustände – verifizieren, sodass Regressionen erkannt werden, bevor Code gemergt wird, statt erst in einem Production-Audit.

Der rechtliche und geschäftliche Grund, jetzt zu handeln

Über den moralischen Imperativ der Inklusion hinaus ist der geschäftliche Nutzen mobiler Barrierefreiheit konkret. Unternehmen, die bei der Inklusion von Menschen mit Behinderungen führend sind, erzielen 1,6-mal mehr Umsatz und 2,6-mal mehr Nettogewinn als Branchenkollegen. Menschen mit Behinderungen verfügen in den USA über nahezu eine halbe Billion Dollar an verfügbarem Einkommen. Und da 69% der behinderten Online-Konsumenten Apps und Websites verlassen, die sie als schwer nutzbar empfinden, ist jede Barriere ein Conversion-Verlust, der nie stattfindet.

Das rechtliche Risiko nimmt zu. Klagen gegen Unternehmen mit Defiziten in der digitalen Barrierefreiheit wachsen von Jahr zu Jahr. Die Übernahme von WCAG durch das DOJ als technischen Standard für ADA-Compliance, die Title-II-Durchsetzungsfristen 2026 und das Inkrafttreten des EAA im Juni 2025 schaffen zusammen eine multi-jurisdiktionale Compliance-Anforderung, die nun ausdrücklich native Mobile-Anwendungen umfasst. Ein früheres WCAG-2.1-Audit weist nicht automatisch WCAG-2.2-Konformität nach – Authentifizierungs-Flows, Formularfelder, interaktive Komponenten und Fokusverwaltung müssen alle im Hinblick auf die neun neuen Erfolgskriterien neu bewertet werden.

Entscheidend ist, dass Barrierefreiheit im Mobile-Bereich keine Funktion ist, die sich nach dem Launch kostengünstig nachrüsten lässt. Die Behebung von WCAG-Verstößen in einer bereits veröffentlichten App bedeutet aktualisierte Assets, neu aufgebaute Komponenten, überarbeitete Layouts, erneut getestete Flows und möglicherweise refaktorierte Authentifizierungssysteme. Teams, die WCAG-2.2-Konformität von Anfang an in ihre Designsysteme und Komponentenbibliotheken integrieren – Mindest-Touch-Zielgrößen, Kontrast-Tokens, semantische Rollen und Authentifizierungsmuster auf Komponentenebene durchsetzen –, zahlen nur einen Bruchteil der Kosten im Vergleich zur nachträglichen Sanierung einer nicht barrierefreien App.

Wesentliche Erkenntnisse

• WCAG 2.2 gilt für native iOS- und Android-Apps. Die W3C-Leitlinie WCAG2Mobile ordnet jedes Erfolgskriterium der Stufen A und AA mobilen Screens und Views zu, was bedeutet, dass Ihre native App im Geltungsbereich liegt – nicht nur Ihre mobile Website.
• Die Größe von Touch-Zielen ist der häufigste neue Fehler in Mobile-Audits. Das 24 × 24-Minimum von WCAG 2.2 ist die Untergrenze; Apple empfiehlt 44 × 44 pt und Google 48 × 48 dp. Vergrößern Sie Trefferflächen mit Padding und plattformeigenen APIs, nicht indem Sie Icons visuell aufblähen.
• Das Blockieren von Einfügen in Passwortfeldern verstößt wahrscheinlich gegen 3.3.8 Accessible Authentication. Unterstützen Sie System-Keychains, Passwortmanager, Biometrie und OTP-Autofill, um die Anforderungen an kognitive Barrierefreiheit für Login-Flows auf beiden Plattformen zu erfüllen.
• Manuelles Testen mit VoiceOver und TalkBack ist unverzichtbar. Automatisierte Tools erfassen nur einen Bruchteil der Barrierefreiheitsprobleme. Testen Sie auf physischen Geräten mit maximaler Schriftgröße, aktivierten unterstützenden Technologien und über alle kritischen User Journeys hinweg.
• Verankern Sie Barrierefreiheit jetzt in Ihrem Designsystem, nicht erst nach dem Launch. Die nachträgliche Sanierung nicht barrierefreier Apps ist deutlich teurer, als von Tag eins an barrierefreie Komponentenstandards durchzusetzen. Mit den Durchsetzungsfristen von DOJ, HHS und EAA in den Jahren 2025–2026 schließt sich das Zeitfenster für kostengünstige Compliance-Arbeit.