Barrierefreiheit in mobilen Apps: So machen Sie Ihre App zugänglicher

Eine Vorschau oder ein Kontrastwert kann nicht beweisen, dass eine App barrierefrei ist. Sie können jedoch erstaunlich viele Barrieren beseitigen, bevor formelle Tests überhaupt beginnen.

Mobile Barrierefreiheit reicht weit über den Farbkontrast hinaus. Typografie, Abstände, Navigation, Touch-Ziele, Beschriftungen, Bewegung, Medien und das Verhalten mit assistiven Technologien beeinflussen ebenfalls, ob eine Person eine Aufgabe abschließen kann.

Die WCAG wurden für Webinhalte entwickelt. Die WCAG2Mobile-Empfehlungen des W3C erläutern, wie die Kriterien der WCAG 2.2 auf den Stufen A und AA auf native, webbasierte und hybride mobile Apps angewendet werden können. Das Dokument ist informativ, keine eigenständige normative Mobil-Norm, und reicht allein nicht aus, um die Barrierefreiheit einer App nachzuweisen.

Diese Checkliste unterscheidet zwischen zentral konfigurierbaren Punkten und Aspekten, die im veröffentlichten Produkt weiterhin geprüft werden müssen:

Auf diesem ersten Bildschirm wirkte nichts offensichtlich defekt. Genau das machte die Übung wertvoll: Probleme mit der Barrierefreiheit sind nicht immer dramatisch. Oft verbergen sie sich in geschmackvollen Designentscheidungen.

Wir verwendeten helle Schrift auf hellem Hintergrund, reduzierten den Fließtext auf 10 px, entfernten die globalen Ränder und behielten allgemeine Navigationsbezeichnungen wie „Videos“ und „Podcasts“ bei. In einer Präsentation wirkte das Ergebnis weiterhin ruhig. Auf einem Smartphone brach die Hierarchie zusammen: Sekundärtext verblasste, Karten rückten dicht an den Bildschirmrand und die untere Navigation ließ sich deutlich schwerer erfassen.

Die Lehre lautet nicht „Verwenden Sie niemals Pastellfarben“ oder „Machen Sie alles groß“. Markenentscheidungen brauchen ein lesbares System als Grundlage.

Wir begannen unter Meine App > App-Stil > Farben und ordneten Farben nach ihrer Rolle zu. Der warme Hintergrund blieb erhalten. Verändert wurde der Abstand zwischen jeder Vordergrundfarbe und ihrem Hintergrund:

Die WCAG 2.2 legen für Stufe AA ein Mindestkontrastverhältnis von 4,5:1 für normalen Text und 3:1 für großen Text fest. Für die wichtigsten Texte haben wir bewusst mehr Spielraum gelassen: Ein Paar, das rechnerisch besteht, kann bei einer dünnen Schrift, kleiner Größe oder auf einem hellen Display im Freien weiterhin schwach wirken.

Mit GoodBarber können Sie mit einem integrierten Thema beginnen, eine Palette generieren oder eine eigene erstellen. Entscheidend ist nicht die Anzahl der Farbfelder, sondern ihre Wiederverwendung. Header- und Fließtext, Trennlinien, Schaltflächen und Navigationszustände können in allen Bereichen konsistente Rollen erhalten. Die Dokumentation zum App-Stil erklärt, wie sich diese globalen Entscheidungen auswirken.

Eine lesbare Palette ist ein starker Ausgangspunkt, kein Zertifikat für Barrierefreiheit. Prüfen Sie jedes tatsächliche Vordergrund-Hintergrund-Paar, einschließlich ausgewählter Zustände, Overlays, Bilder und bereichsspezifischer Anpassungen.

Der Kontrast machte die Wörter sichtbar. Größe und Abstände machten sie angenehm lesbar.

Wir wählten das Schriftartenthema Formateca, das Work Sans für Überschriften mit Manrope für Fließtext kombiniert. Anschließend bauten wir mit dem globalen Typografie-Regler die Hierarchie neu auf: Der Fließtext wuchs von 10 px auf 16 px, die Hauptüberschrift erreichte 30 px und der Hauptinhalt erhielt wieder 16 px Rand.

Die globale Schriftskala von GoodBarber passt acht Textebenen proportional an. Das erleichtert eine konsistente Hierarchie über mehrere Bildschirme hinweg, garantiert aber kein barrierefreies Ergebnis. Prüfen Sie die resultierenden Größen, Umbrüche und Zeilenabstände in der generierten App.

Die WCAG schreiben keine universelle Mindestgröße für Fließtext vor. Die 16 px sind der für diese Oberfläche gewählte Standard, keine Konformitätsschwelle. Größerer Text braucht außerdem mehr Platz; andernfalls wirken Karten gedrängt und Beschriftungen brechen ungünstig um.

Testen Sie die App schließlich mit der bevorzugten Textgröße der Nutzerinnen und Nutzer. Apple empfiehlt, Textvergrößerung und Dynamic Type zu unterstützen; Webinhalte sollten auch bei vergrößertem Text nutzbar bleiben. Eine ausgewogene Editor-Vorschau ist nur der erste zu prüfende Zustand.

In diesem Vorher-Nachher-Vergleich zeigte die ursprüngliche TabBar „Videos“, „Podcasts“ und „Navigation“. Diese Bezeichnungen beschrieben Formate oder die Mechanik der Oberfläche, nicht klar, was ein Mitglied der Yoga-Community als Nächstes tun konnte.

Wir benannten sie in Classes, Audio und More um. Die Struktur blieb gleich, aber die Entscheidung wurde leichter: einen Kurs starten, eine Audio-Session auswählen oder die übrigen Bereiche öffnen.

Die Android-Empfehlungen zur Barrierefreiheit raten zu nützlichen, beschreibenden Beschriftungen für interaktive Elemente, weil Dienste wie TalkBack deren barrierefreie Namen vorlesen können. Die Änderung des sichtbaren Titels verbessert die visuelle Navigation; trotzdem müssen Sie prüfen, was die generierte Komponente tatsächlich an VoiceOver und TalkBack übermittelt.

Halten Sie Beschriftungen kurz, eindeutig und aufgabenbezogen. Kombinieren Sie Symbole mit Text, wenn der Platz es erlaubt. Ein einfacher Test: Würden die Wörter auch ohne Symbole noch erklären, wohin ein Tippen führt?

Barrierefreiheit scheitert, wenn Inhalte sichtbar sind, ein Bedienelement aber schwer zu treffen ist — oder wenn ein wesentliches Medium einen Sinneskanal ausschließt.

Beginnen Sie mit den Touch-Zielen. Android empfiehlt für interaktive Elemente eine fokussierbare Fläche von mindestens 48 × 48 dp. Für die PWA legt das WCAG-2.2-Kriterium Zielgröße (Minimum) auf Stufe AA vorbehaltlich definierter Ausnahmen mindestens 24 × 24 CSS-Pixel fest. Das sichtbare Symbol darf kleiner als seine bedienbare Fläche sein, benachbarte Ziele müssen jedoch klar voneinander getrennt bleiben.

Prüfen Sie anschließend, wie Bedeutung vermittelt wird. Fehler, Fortschritt und Verfügbarkeit benötigen wahrnehmbare Hinweise. Informative Bilder brauchen sinnvolle Textalternativen, relevante Videos Untertitel und reine Audioinhalte ein Transkript oder eine gleichwertige Alternative. Das sind redaktionelle Entscheidungen, die ein konsistentes App-Design nicht für Sie automatisieren kann.

GoodBarber zentralisiert Schaltflächenhierarchie, Farben und Formen über den App-Stil. Nutzen Sie diese Einstellungen, um Inkonsistenzen zu reduzieren, und prüfen Sie anschließend Zielgröße, Fokus, Beschriftungen und Zustände in den generierten iOS-, Android- und PWA-Versionen.

Lotus Yoga nutzte sowohl haptisches Feedback als auch eine Öffnungsanimation. Unter Meine App > App-Stil deaktivierten wir den dekorativen Öffnungseffekt und behielten haptisches Feedback in den nativen Apps bei. GoodBarber bietet im selben Bereich außerdem Scroll-Effekte; die zusätzlichen Optionen des App-Stils erläutern, wo diese Einstellungen zu finden sind.

Diese Entscheidung ist keine allgemeingültige Vorgabe für Barrierefreiheit. Bewegung kann einen Zustandswechsel erklären, Haptik eine Aktion ohne zusätzliche visuelle Unruhe bestätigen. Entscheidend ist, ob der Effekt nützliche Informationen vermittelt. Wenn nicht, lässt sich eine ruhigere Standardeinstellung leichter begründen.

Gehen Sie nicht davon aus, dass eine Änderung im Editor bereits die Unterstützung reduzierter Bewegung beweist. Prüfen Sie die veröffentlichte App mit aktivierten Bewegungseinstellungen des Geräts und bestätigen Sie, dass vollständige Aufgaben auch ohne den Effekt verständlich bleiben.

Diese finale Version ist leichter zu lesen und zu navigieren, ohne den ruhigen Charakter der Marke zu verlieren. Vor allem sind die Verbesserungen systemisch: Eine Palette, eine Schriftskala und ein Abstandssystem können viele Bildschirme gleichzeitig verbessern.

Die Vorschau zeigt Farbe, Hierarchie, Abstände, Beschriftungen und sichtbare Zustände. Sie kann nicht beurteilen, ob jede Screenreader-Ansage hilfreich ist, ob der Fokus logisch weiterwandert oder ob ein vollständiger Ablauf mit einer alternativen Eingabemethode bedienbar bleibt.

Vor der Veröffentlichung:

• Durchlaufen Sie wichtige iOS-Abläufe mit VoiceOver und Android-Abläufe mit TalkBack, ohne auf den Bildschirm zu schauen.
• Erhöhen Sie die Systemtextgröße und prüfen Sie auf abgeschnittene oder überlappende Inhalte, verborgene Bedienelemente und verlorene Informationen.
• Prüfen Sie Schaltflächen, Links, Formulare und Menüs auf eindeutige Namen, Rollen, Zustände und Fokusreihenfolgen.
• Testen Sie die PWA mit Tastaturnavigation, Browser-Zoom und unterschiedlichen Fenstergrößen.

Automatisierte Werkzeuge finden wertvolle Probleme. Sie verstehen jedoch nicht, ob eine Beschriftung sinnvoll, eine Anweisung kognitiv klar oder eine vollständige Aufgabe frustrierend ist. Manuelle Tests — idealerweise mit Menschen mit Behinderungen — bleiben unerlässlich.

Der Vorteil eines Design Systems liegt in seiner Hebelwirkung. GoodBarber baut Bildschirme aus gemeinsamen Grundlagen und wiederverwendbaren Komponenten auf. Farbe, Typografie, Abstände, Formen und Navigation sind Regeln, die in der gesamten App wiederverwendet werden, statt isolierte Dekorationen zu sein. Im GoodBarber Design System sehen Sie, wie diese Ebenen zusammenwirken.

Diese Hebelwirkung schafft zugleich eine klare Aufgabenverteilung:

Das Design System von GoodBarber nimmt Ihnen einen Teil der wiederkehrenden Arbeit an der Barrierefreiheit ab, indem es gemeinsame Regeln für Typografie, Farbe, Abstände und Komponenten in der gesamten App anwendet. Die resultierende Oberfläche und ihre Inhalte müssen Sie dennoch auf jeder Plattform validieren.

Gelten die WCAG für native mobile Apps?

Die WCAG wurden für Webinhalte entwickelt, ihre Prinzipien und Erfolgskriterien werden jedoch häufig für mobile Barrierefreiheit eingesetzt. Der WCAG2Mobile-Entwurf des W3C erklärt, wie Kriterien der WCAG 2.2 auf den Stufen A und AA auf native, webbasierte und hybride mobile Apps angewendet werden können. Die Empfehlungen sind informativ, keine eigenständige normative Mobil-Norm und keine Garantie für rechtliche Konformität.

Kann ein App-Baukasten automatisch eine barrierefreie App erstellen?

Nein. Wiederverwendbare Komponenten, lesbare Standardwerte und globale Designregeln können eine stärkere Basis schaffen. Barrierefreiheit hängt jedoch auch von Konfiguration, Inhalten, Drittanbieterfunktionen und vollständigen Abläufen ab. Die generierte App muss weiterhin getestet werden.

Was sollte ich in einer bestehenden mobilen App zuerst testen?

Beginnen Sie mit den Abläufen, die niemand umgehen kann: App öffnen, navigieren, anmelden, Inhalte finden und die Hauptaktion abschließen. Testen Sie diese mit Screenreader, vergrößertem Text und reduzierter Bewegung; prüfen Sie danach Touch-Ziele, Formularfehler und Medienalternativen.

Wie hoch ist der minimale Textkontrast für eine mobile App?

WCAG 2.2 auf Stufe AA legt ein Mindestkontrastverhältnis von 4,5:1 für normalen Text und 3:1 für großen Text fest. Diese Werte werden mithilfe der WCAG2Mobile-Empfehlungen auch häufig zur Bewertung mobiler Oberflächen verwendet. Betrachten Sie sie als Untergrenze, nicht als Designziel.

Wo ändere ich diese Einstellungen in GoodBarber?

Öffnen Sie Meine App > App-Stil, um globale Farben, Schriftarten, Ränder, Schaltflächen, Animationen und haptisches Feedback zu verwalten. Navigationsbeschriftungen und Layouts werden in der App-Struktur konfiguriert. Prüfen Sie das Ergebnis während der Arbeit in der Vorschau und testen Sie vor der Veröffentlichung die generierten iOS-, Android- und PWA-Versionen.

Eine barrierefreie App ist kein bestimmter visueller Stil. Sie entsteht aus Entscheidungen, die mehr Menschen ermöglichen, Inhalte wahrzunehmen, die Oberfläche zu verstehen und eine Aufgabe abzuschließen. Erstellen Sie Ihre App mit GoodBarber, bauen Sie diese Basis einmal auf und verbessern Sie sie mit Erkenntnissen realer Nutzerinnen und Nutzer.