React Native Barrierefreiheit: Accessibility für mobile Apps

1. Warum Barrierefreiheit in React Native kein Nice-to-have ist

Der European Accessibility Act (EAA) verpflichtet seit Juni 2025 einen wachsenden Kreis digitaler Produkte in der EU, darunter viele Consumer-Apps mit E-Commerce- oder Bankingfunktionen, zu nachweisbarer Barrierefreiheit. Für React-Native-Teams bedeutet das, Accessibility nicht mehr als optionalen Polish-Schritt am Projektende zu behandeln, sondern als festen Bestandteil jeder neuen Komponente. Wird eine App erst nachträglich barrierefrei gemacht, entstehen erheblich höhere Aufwände, weil Fokus-Reihenfolge und semantische Struktur oft tief mit der bestehenden Komponentenarchitektur verwoben sind.

Auch abseits rechtlicher Pflichten lohnt sich Barrierefreiheit wirtschaftlich: Millionen Nutzer verlassen sich dauerhaft oder situativ auf Screenreader, Sprachsteuerung oder vergrößerte Schrift, und App Stores selbst prüfen zunehmend grundlegende Accessibility-Kriterien im Review-Prozess. Eine App, die bei aktiviertem VoiceOver unbedienbar wird, kann im schlimmsten Fall sogar wegen Verstößen gegen Store-Richtlinien abgelehnt werden, unabhängig von der rechtlichen EAA-Verpflichtung.

Der entscheidende Unterschied zu Web-Accessibility ist, dass React Native keine DOM-Struktur mit HTML-Semantik besitzt. Es gibt kein automatisches <button>-Element, das von sich aus mit dem Screenreader kommuniziert, stattdessen muss jede interaktive Komponente ihre Rolle, ihren Zustand und ihre Beschreibung explizit über Accessibility-Props deklarieren. Genau diese fehlende Automatik macht bewusstes Design für Accessibility in React Native unverzichtbar.

2. Die zentralen Accessibility-Props im Überblick

Die Basis jeder barrierefreien Komponente ist die Prop accessible={true}, die ein Element für Screenreader als eine einzige, fokussierbare Einheit markiert. Darauf aufbauend liefert accessibilityLabel die hörbare Beschreibung, die anstelle des visuellen Textes vorgelesen wird, während accessibilityHint zusätzlich erklärt, was bei einer Interaktion passiert, etwa "Öffnet das Warenkorb-Menü". Diese beiden Props sollten sich ergänzen, nicht wiederholen, ein Label wie "Warenkorb" mit dem Hint "Öffnet den Warenkorb" liefert mehr Information als ein redundanter zweiter Satz.

accessibilityRole teilt dem Screenreader mit, um welche Art von Element es sich handelt, etwa button, link, header oder checkbox, wodurch VoiceOver und TalkBack automatisch passende Bedienhinweise und Gesten anbieten. Ergänzend liefert accessibilityState dynamische Zustandsinformationen wie disabled, selected oder checked, und accessibilityValue wird für Elemente mit einem Wertebereich wie Slider verwendet. Für komplexere Interaktionen jenseits eines einfachen Tap ermöglicht accessibilityActions in Kombination mit onAccessibilityAction zusätzliche, per Screenreader auslösbare Aktionen wie Swipe-to-delete.

// AccessibleCartButton.tsx - core accessibility props in practice
import { Pressable, Text } from 'react-native';

export function AccessibleCartButton({ itemCount, onPress, disabled }) {
  return (
    <Pressable
      onPress={onPress}
      disabled={disabled}
      accessible={true}
      accessibilityRole="button"
      accessibilityLabel={`Shopping cart, ${itemCount} items`}
      accessibilityHint="Opens the shopping cart overview"
      accessibilityState={{ disabled }}
    >
      <Text>Cart ({itemCount})</Text>
    </Pressable>
  );
}

3. Elemente gruppieren und Fokus-Reihenfolge steuern

Eine Produktkarte mit Bild, Titel, Preis und Bewertungssternen sollte für Screenreader-Nutzer nicht als vier separate Fokus-Stopps erscheinen, sondern als eine zusammenhängende Einheit. Dafür wird accessible={true} auf dem umschließenden View gesetzt, während die einzelnen Kind-Elemente selbst nicht mehr individuell fokussierbar sind, sondern ihr Text automatisch zu einer zusammengesetzten Beschreibung verkettet wird. Ohne diese Gruppierung springt der Screenreader-Fokus umständlich durch jedes einzelne Detail-Element, was die Navigation durch lange Listen erheblich verlangsamt.

Die Reihenfolge, in der ein Screenreader durch den Bildschirm navigiert, folgt in React Native primär der Reihenfolge im Komponentenbaum, nicht der visuellen Anordnung durch absolute Positionierung. Mit importantForAccessibility="no-hide-descendants" lassen sich rein dekorative Container komplett aus der Fokus-Reihenfolge entfernen, was besonders bei Icon-Overlays oder Hintergrundgrafiken sinnvoll ist, die keinen semantischen Mehrwert für Screenreader-Nutzer bieten.

Ein besonders anfälliger Fall für falsche Fokus-Reihenfolge sind absolut positionierte Overlays wie Modals oder Toast-Nachrichten, die visuell über dem restlichen Inhalt schweben, im Komponentenbaum aber an anderer Stelle eingehängt sein können. Öffnet sich ein Modal, sollte der Screenreader-Fokus explizit auf das erste fokussierbare Element im Modal gesetzt werden, statt weiterhin im Hintergrund-Inhalt zu verharren, der für die Dauer des Modals ohnehin nicht interagierbar sein sollte. Dieses Verhalten wird oft erst bei einem tatsächlichen Screenreader-Test bemerkt, weil es visuell unauffällig bleibt.

4. Dynamische Inhalte und Ankündigungen

Wenn sich Inhalte ändern, ohne dass der Nutzer aktiv navigiert, etwa nach einem asynchronen API-Aufruf oder bei einer Formularvalidierung, bemerkt ein Screenreader-Nutzer diese Änderung normalerweise nicht automatisch. AccessibilityInfo.announceForAccessibility('Nachricht') löst eine gesprochene Ankündigung unabhängig vom aktuellen Fokus aus und ist damit das zentrale Werkzeug, um Nutzer über Zustandsänderungen wie "3 neue Nachrichten erhalten" oder "Formular erfolgreich abgeschickt" zu informieren.

Wichtig ist Zurückhaltung bei der Häufigkeit solcher Ankündigungen. Wird bei jeder kleinen UI-Änderung eine Ankündigung ausgelöst, entsteht ein ständiges akustisches Rauschen, das die eigentliche Navigation erschwert statt erleichtert. Als Faustregel sollten Ankündigungen auf Ereignisse beschränkt werden, die für die Aufgabe des Nutzers tatsächlich relevant sind, etwa Fehler, Bestätigungen und größere Kontextwechsel, nicht aber jede kleine visuelle Aktualisierung.

// FormSubmission.tsx - announce dynamic state changes explicitly
import { AccessibilityInfo } from 'react-native';

async function submitForm(formData) {
  try {
    await api.submit(formData);
    AccessibilityInfo.announceForAccessibility('Form submitted successfully');
  } catch (error) {
    AccessibilityInfo.announceForAccessibility('Submission failed, please check the form fields');
  }
}

5. Reduced Motion respektieren

Manche Nutzer erleben durch stark animierte Übergänge Schwindel oder Unwohlsein, ein Zustand, der unter dem Begriff vestibuläre Störung bekannt ist. Beide mobilen Betriebssysteme bieten eine systemweite Einstellung "Bewegung reduzieren", die von der App über AccessibilityInfo.isReduceMotionEnabled() abgefragt werden kann. Ist diese Einstellung aktiv, sollten aufwendige Parallax-Effekte, große Slide-Übergänge und automatisch abspielende Video-Hintergründe durch einfache Fades oder sofortige Übergänge ersetzt werden.

Reanimated und andere Animationsbibliotheken bieten dafür meist eigene Hooks an, die den Systemwert reaktiv beobachten, sodass sich Animationsdauer und -komplexität zur Laufzeit anpassen lassen, ohne die App neu starten zu müssen. Diese Anpassung an Barrierefreiheit-Präferenzen des Betriebssystems ist einer der Fälle, in denen ein einziger API-Aufruf einen spürbaren Unterschied für eine ganze Nutzergruppe macht, ohne die Erfahrung für andere Nutzer zu verschlechtern.

6. Touch-Ziele und Kontrast im Design-System

Die Apple Human Interface Guidelines verlangen mindestens 44 mal 44 Punkte für jedes interaktive Element, während die Material-Design-Richtlinien von Google 48 mal 48 dp vorschreiben. Kleinere Touch-Ziele sind nicht nur für Nutzer mit motorischen Einschränkungen problematisch, sondern erhöhen für alle Nutzer die Fehlerquote bei der Bedienung, besonders unterwegs oder bei ungünstigen Lichtverhältnissen. In einem Design-System sollte diese Mindestgröße als globale Konstante definiert und in jeder Pressable- oder Touchable-Komponente konsequent durchgesetzt werden.

Farbkontrast ist der zweite große Hebel, insbesondere in einem Design-System mit Dark Mode, in dem sich Kontrastverhältnisse je nach Farbschema stark unterscheiden können. Die WCAG-Richtlinie von mindestens 4.5:1 für normalen Text und 3:1 für großen Text lässt sich zwar aus dem Web übernehmen, muss aber für beide Farbschemata separat validiert werden, da ein im Light Mode ausreichender Kontrast im Dark Mode durchaus unzureichend sein kann.

Beide Anforderungen, Mindestgröße und Kontrast, lassen sich am effizientesten über Design-Tokens im zentralen Theming-System durchsetzen, statt sie in jeder einzelnen Komponente manuell zu prüfen. Ein Linting-Schritt, der Farbkombinationen aus dem Theme automatisch gegen die WCAG-Schwellenwerte rechnet, deckt Verstöße bereits beim Hinzufügen einer neuen Farbvariante auf, lange bevor sie in produktivem Code auftauchen.

7. Manuelles Testing mit Accessibility Inspector und Scanner

Der Accessibility Inspector in Xcode zeigt für jedes Element auf dem Bildschirm die tatsächlich an VoiceOver übergebenen Werte an, inklusive Label, Traits und Hint, und deckt so unmittelbar auf, wenn ein Element ohne sinnvolles Label bleibt oder fälschlich als reines Bild statt als Button erkannt wird. Auf Android übernimmt der Accessibility Scanner eine ähnliche Rolle und markiert zusätzlich automatisch erkennbare Probleme wie zu kleine Touch-Ziele oder fehlenden Kontrast direkt auf dem Screenshot der App.

Kein Werkzeug ersetzt jedoch den tatsächlichen Test mit aktiviertem VoiceOver beziehungsweise TalkBack bei laufender App. Viele Probleme, etwa eine verwirrende Fokus-Reihenfolge oder eine fehlende Ankündigung nach einer Aktion, werden erst beim tatsächlichen Navigieren mit geschlossenen Augen oder deaktiviertem Bildschirm sichtbar. Ein kurzer manueller Durchlauf der wichtigsten User-Flows mit aktiviertem Screenreader sollte fester Bestandteil jedes größeren Feature-Reviews sein.

Ein praktikabler Kompromiss für Teams ohne dedizierten Accessibility-Spezialisten ist eine feste Checkliste mit den fünf bis sechs kritischsten User-Flows, etwa Login, Checkout und Formular-Absendung, die bei jedem größeren Release stichprobenartig mit aktiviertem Screenreader durchlaufen werden. Das deckt die gröbsten Regressionen zuverlässig auf, ohne den vollen Aufwand eines umfassenden externen Accessibility-Audits bei jedem Release zu erfordern.

# iOS: enable VoiceOver via simulator accessibility shortcut
xcrun simctl spawn booted notifyutil -s com.apple.accessibility.voiceover 1

# Android: enable TalkBack via adb for automated test runs
adb shell settings put secure enabled_accessibility_services \
  com.google.android.marvin.talkback/com.google.android.marvin.talkback.TalkBackService

8. Automatisierte Prüfung mit ESLint-Plugin

Da React Native keinen direkten Äquivalent zu axe-core für automatisierte DOM-Audits besitzt, verlagert sich ein Großteil der automatisierten Prüfung auf statische Code-Analyse. eslint-plugin-react-native-a11y prüft beim Schreiben des Codes, ob interaktive Komponenten ein accessibilityLabel besitzen, ob Touchable-Komponenten eine passende Rolle deklarieren, und warnt vor häufigen Mustern wie einem Bild ohne Alternative für Screenreader.

Ergänzend lässt sich in Jest-Tests prüfen, ob kritische Komponenten die erwarteten Accessibility-Props überhaupt rendern, etwa durch einen Snapshot-Test, der explizit auf das Vorhandensein von accessibilityRole und accessibilityLabel abzielt. Das ersetzt keinen manuellen Screenreader-Test, verhindert aber zuverlässig die Regression, bei der ein zuvor barrierefreies Element durch eine spätere Änderung sein Label verliert.

{
  "extends": ["plugin:react-native-a11y/all"],
  "rules": {
    "react-native-a11y/has-accessibility-hint": "warn",
    "react-native-a11y/has-valid-accessibility-role": "error",
    "react-native-a11y/touchable-has-accessibility-props": "error"
  }
}

9. Plattformunterschiede und Vergleich

Obwohl React Native eine gemeinsame API für Accessibility-Props bereitstellt, unterscheiden sich VoiceOver und TalkBack in Detailverhalten, Gestennavigation und Testwerkzeugen spürbar. Ein Rollenname wie accessibilityRole="header" wird auf iOS beispielsweise anders in native Traits übersetzt als der entsprechende TalkBack-Rollenhinweis auf Android, was in Randfällen leicht abweichendes Vorleseverhalten erzeugen kann.

Für Teams, die ernsthaft in Barrierefreiheit investieren, lohnt sich deshalb immer ein Test auf beiden Plattformen, nicht nur auf der primären Zielplattform des Entwicklerteams. Die folgende Übersicht fasst die wichtigsten Unterschiede zusammen.

10. Zusammenfassung

Barrierefreiheit in React Native beginnt bei den Grundbausteinen accessibilityLabel, accessibilityRole und accessibilityState, die jede interaktive Komponente explizit deklarieren muss, weil eine native DOM-Semantik wie im Web fehlt. Gruppierung mit accessible={true}, eine durchdachte Fokus-Reihenfolge und gezielte Ankündigungen über AccessibilityInfo sorgen dafür, dass Screenreader-Nutzer komplexe UIs sinnvoll navigieren können, statt sich durch unzusammenhängende Einzelelemente zu kämpfen.

Reduced Motion, ausreichende Touch-Ziele und valider Farbkontrast in beiden Farbschemata runden die technische Umsetzung von Accessibility ab. Manuelles Testen mit aktiviertem VoiceOver und TalkBack bleibt unverzichtbar, ergänzt durch ESLint-Regeln, die Regressionen im laufenden Entwicklungsprozess verhindern. Angesichts des European Accessibility Act ist diese Investition längst keine Kür mehr, sondern eine rechtliche und wirtschaftliche Notwendigkeit für jede ernsthafte React-Native-App.

11. FAQ: React Native Barrierefreiheit und Accessibility