WCAG für native Apps: So gilt der Standard auch jenseits des Webs
Die Web Content Accessibility Guidelines (WCAG) sind, der Name sagt es, für Web-Inhalte geschrieben. Trotzdem sind sie der Maßstab, an dem auch native iOS- und Android-Apps gemessen werden: über die offizielle Übersetzungshilfe WCAG2ICT, über die europäische Norm EN 301 549 und über Gesetze wie das BFSG. Diese Seite zeigt, wie diese Kette funktioniert, welche WCAG-Kriterien sich direkt auf Apps übertragen lassen und wo die Übersetzung hakt.
Warum WCAG auch für Apps der Maßstab ist
Wenn du eine native App barrierefrei machen willst, findest du keinen eigenen „WCAG für Apps"-Standard. Es gibt ihn schlicht nicht. Und trotzdem führt an den WCAG kein Weg vorbei. Der Grund liegt in den Gesetzen und Normen, die Barrierefreiheit verbindlich machen: Sie alle verweisen direkt oder indirekt auf die WCAG-Erfolgskriterien.
In Deutschland verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) seit dem 28. Juni 2025 viele privatwirtschaftliche Anbieter:innen, ihre digitalen Dienstleistungen barrierefrei anzubieten, ausdrücklich auch dann, wenn diese Dienstleistungen über mobile Anwendungen erbracht werden, etwa eine Shopping-, Banking- oder Ticket-App. Das BFSG setzt den European Accessibility Act (EAA) um, die EU-Richtlinie 2019/882. Für öffentliche Stellen gilt mit der BITV 2.0 schon länger eine Pflicht, die mobile Apps einschließt. Und die technische Messlatte hinter all diesen Regelwerken ist die europäische Norm EN 301 549, die wiederum ihre Software-Anforderungen aus den WCAG ableitet.
| Regelwerk | Was es ist | App-Relevanz |
|---|---|---|
| WCAG 2.2 | Internationaler W3C-Standard für barrierefreie Web-Inhalte | Liefert die Erfolgskriterien, an denen über WCAG2ICT und EN 301 549 auch Apps gemessen werden |
| EAA / BFSG | EU-Richtlinie 2019/882 und ihre deutsche Umsetzung, gilt seit 28.06.2025 | Verpflichtet viele private Anbieter:innen, ausdrücklich auch bei Dienstleistungen über mobile Apps |
| BITV 2.0 | Verordnung für öffentliche Stellen des Bundes | Schließt mobile Anwendungen öffentlicher Stellen ein |
| EN 301 549 | Europäische Norm für barrierefreie ICT (ETSI) | Kapitel 11 „Software" formuliert die konkreten Anforderungen für native Apps, abgeleitet aus den WCAG |
Die Kette lautet also: Gesetz → Norm → WCAG. Wer eine App nach WCAG 2.2 auf Konformitätsstufe AA entwickelt, arbeitet damit genau auf das hin, was BFSG und BITV faktisch verlangen.
WCAG2ICT: die offizielle Übersetzungshilfe
Die WCAG sprechen von „Webseiten", „Browsern" und „Sets von Webseiten": alles Begriffe, die in einer nativen App ins Leere laufen. Genau dafür gibt es WCAG2ICT: „Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies". Das Dokument stammt von der gleichen W3C-Arbeitsgruppe wie die WCAG selbst und wurde am 8. Oktober 2024 in aktualisierter Fassung als W3C Group Note veröffentlicht, erstmals inklusive der WCAG-2.2-Kriterien.
WCAG2ICT ist kein eigener Standard und definiert keine neuen Anforderungen. Es beschreibt Kriterium für Kriterium, wie sich der WCAG-Wortlaut auf Nicht-Web-Software übertragen lässt, also auch auf native iOS- und Android-Apps. Das Grundprinzip ist eine Wortersetzung:
Praktisch wichtig: Regulierungswerke auf der ganzen Welt nutzen genau diese Übersetzung, um WCAG-Anforderungen auf Software anzuwenden: die EN 301 549 in Europa genauso wie die Section-508-Regeln in den USA. Wer wissen will, was ein bestimmtes WCAG-Kriterium für die eigene App konkret bedeutet, schlägt es deshalb am besten direkt in WCAG2ICT nach.
EN 301 549: die Norm hinter den Gesetzen
Die EN 301 549 ist die europäische Norm für barrierefreie Informations- und Kommunikationstechnik. Sie deckt weit mehr ab als das Web und sortiert ihre Anforderungen nach der Art der Technik:
Für native Apps ist Kapitel 11 „Software" der relevante Teil. Seine Anforderungen entsprechen inhaltlich den WCAG-Kriterien der Stufen A und AA, übersetzt nach dem WCAG2ICT-Prinzip. Dazu kommen software-spezifische Anforderungen, etwa zur Zusammenarbeit mit Hilfstechnologien über die Accessibility-Schnittstellen der Plattform (Kapitel 11.5).
Was sich direkt übertragen lässt
Der größte Teil der WCAG-Kriterien funktioniert in Apps ohne gedankliche Verrenkung, nur die technische Umsetzung ist eine andere. Statt HTML-Attributen nutzt du die Accessibility-APIs der Plattform. Ein paar Beispiele:
| WCAG-Kriterium | Im Web | In der nativen App |
|---|---|---|
| 1.1.1 Nicht-Text-Inhalte | alt
-Attribut |
accessibilityLabel
(iOS) bzw. contentDescription
(Android) |
| 1.3.1 Info und Beziehungen | Semantisches HTML, ARIA | Traits/Rollen und Semantik der Accessibility-API (z. B. Überschriften-Trait) |
| 1.4.3 Kontrast | Mindestens 4,5:1 für Text | Gilt unverändert: Farbwerte der App-Oberfläche prüfen |
| 1.4.4 Textgröße | Zoom bis 200 % | Dynamic Type (iOS) bzw. Schriftgrößen-Einstellung (Android) respektieren |
| 2.5.8 Zielgröße | Mindestens 24×24 CSS-Pixel (AA) | Gilt analog. Plattform-Empfehlungen sind strenger: 44×44 pt (Apple), 48×48 dp (Material) |
| 2.4.7 Fokus sichtbar | Sichtbarer Fokus-Indikator | Gilt analog für Tastatur- und Schalter-Bedienung sowie Screenreader-Fokus |
Diese Tabelle ist zugleich die wichtigste Botschaft dieser Seite: Die Prinzipien wandern mit, nur die Werkzeuge wechseln. Wer die vier WCAG-Prinzipien (wahrnehmbar, bedienbar, verständlich, robust) verinnerlicht hat, kann sie auf jeder Plattform anwenden.
Wo die Übersetzung hakt
Ehrlicherweise: Nicht jedes WCAG-Kriterium lässt sich glatt übertragen. WCAG2ICT dokumentiert diese Fälle ausführlich. Die wichtigsten Stolperstellen:
- Kriterien über „Sets von Webseiten". Kriterien wie 2.4.1 (Blöcke umgehen), 2.4.5 (Mehrere Wege) oder 3.2.3 (Konsistente Navigation) beziehen sich auf zusammengehörige Webseiten. WCAG2ICT überträgt sie auf „Sets von Software-Programmen". Eine einzelne App bildet aber in der Regel kein solches Set, sodass diese Kriterien oft schlicht nicht anwendbar sind.
- Kriterien mit Browser-Annahmen. Manche Kriterien setzen Funktionen des Browsers voraus (etwa Zoom). In der App muss die Anwendung selbst liefern, was im Web der Browser übernimmt, zum Beispiel skalierbare Schrift über Dynamic Type.
- Kein DOM, keine einheitliche Prüfbarkeit. Im Web lässt sich vieles automatisiert gegen das HTML prüfen. In Apps führt der Weg über die Accessibility-Schnittstellen der Plattform. Was du dem System dort nicht mitteilst, existiert für Hilfstechnologien nicht.
Plattform-Guidelines: HIG und Material Design
Neben WCAG und Norm haben Apple und Google eigene, sehr konkrete Barrierefreiheits-Vorgaben: die Human Interface Guidelines (HIG) bei Apple und Material Design bei Google. Sie ersetzen die WCAG nicht, sondern ergänzen sie um das, was die WCAG nicht regeln können: plattformspezifische Konventionen, Systemfunktionen und konkrete Maße.
| Regelwerk | Mindest-/Empfehlungswert | Charakter |
|---|---|---|
| WCAG 2.2 (2.5.8, AA) | 24×24 CSS-Pixel (mit Ausnahmen, z. B. Abstand) | Normative Untergrenze |
| Apple HIG | 44×44 Punkte | Plattform-Empfehlung für iOS |
| Material Design (Google) | 48×48 dp | Plattform-Empfehlung für Android |
Die Faustregel für die Praxis: WCAG als Untergrenze, Plattform-Guidelines als Zielwert. Wer sich an HIG und Material hält, liegt bei Maßen wie der Zielgröße automatisch über dem WCAG-Minimum. Umgekehrt decken die Plattform-Guidelines aber nicht alles ab, was WCAG verlangt. Kontrastwerte oder Alternativtexte bleiben in deiner Verantwortung, egal wie konsequent du Systemkomponenten einsetzt.
Zwei Mythen
„WCAG gilt nur für Webseiten, meine App ist davon nicht betroffen."
Formal richtig, praktisch falsch. Die WCAG selbst sind ein Web-Standard. Aber EN 301 549 Kapitel 11 übersetzt ihre Kriterien für Software, und BFSG wie BITV 2.0 machen diese Norm zur rechtlichen Messlatte, ausdrücklich auch für mobile Anwendungen. Wer eine App im Anwendungsbereich dieser Regelwerke betreibt, wird an WCAG-Kriterien gemessen, ob der Name nun „Web" enthält oder nicht.
„Ich nutze nur native Systemkomponenten, dann ist die App automatisch barrierefrei."
Native Komponenten sind ein echter Vorsprung: Sie bringen Fokus-Verhalten, Rollen und Screenreader-Unterstützung von Haus aus mit. Automatisch barrierefrei wird die App dadurch nicht. Beschriftungen, sinnvolle Fokus-Reihenfolge, ausreichender Kontrast, skalierende Layouts und verständliche Texte bleiben Aufgaben des Teams. Kein UI-Framework kann wissen, was ein unbeschriftetes Icon bedeuten soll.
Praxis-Einstieg: so startest du
Wenn du heute mit der Barrierefreiheit deiner App anfängst, ist das eine sinnvolle Reihenfolge:
Soll deine App das BFSG erfüllen, und du weißt nicht, wo anfangen?
Wir prüfen native Apps gegen WCAG 2.2 und EN 301 549, priorisieren die Befunde und begleiten dein Team bei der Umsetzung, von der Architektur-Entscheidung bis zum Screenreader-Test.
Beratung oder Schulung anfragen