In diesem Ratgeber
Schwacher Kontrast und winzige Tippflächen treffen viele: Nutzer in der Sonne, Menschen mit eingeschränktem Sehen, große Finger, zittrige Hände. Zwei schnelle Durchgänge finden viel. Das ist kein vollständiges Barrierefreiheits-Audit; für Screenreader siehe den Screenreader-Test in 10 Minuten.
Die Grenzwerte und woher sie kommen
- Textkontrast: WCAG 2.2, Kriterium 1.4.3, verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (18 Punkt oder 14 Punkt fett).
- Tippflächen: WCAG 2.2, Kriterium 2.5.8, nennt mindestens 24 mal 24 CSS-Pixel, mit Ausnahmen, etwa bei genug Abstand zwischen kleinen Zielen. WCAG ist für Web-Inhalte geschrieben; nimm den Wert als Untergrenze, nicht als Ziel für mobile Apps.
- Android: Googles Barrierefreiheits-Hilfe rät, Touch-Elemente mindestens 48dp breit und hoch zu machen.
- iOS: Apple nennt eine eigene Mindestgröße in den Human Interface Guidelines. Öffne die aktuelle Seite und notiere den Wert, bevor du dich auf eine Zahl verlässt.
Richtlinien ändern sich. Prüfe die Seiten unter den Quellen erneut, bevor du eine Zahl als endgültig behandelst.
Prüfung 1: Farbkontrast
- Fließtext auf seinem Hintergrund. Warum: Graue Schrift auf Weiß ist der häufigste Fehler. So prüfst du: Beide Farben mit Pipette oder Screenshot bestimmen, in einen Kontrastrechner eingeben; Ziel 4,5:1 oder besser.
- Großer Text und Überschriften. Warum: Die Latte liegt niedriger (3:1), muss aber erreicht werden. So prüfst du: Gleiche Methode; prüfe, ob der Text als groß zählt.
- Text auf Bildern und Verläufen. Warum: Der Kontrast ändert sich über das Bild. So prüfst du: Die schlechteste Stelle prüfen, nicht die beste.
- Platzhalter, Hinweise und blasse Texte. Warum: Hinweise sind oft zu hell. Wirklich deaktivierte Elemente sind von der Textregel ausgenommen, Hinweise in aktiven Feldern nicht. So prüfst du: Farbe des Hinweises in einem aktiven Feld prüfen.
- Icons und Rahmen, die etwas bedeuten. Warum: Ein blasses Icon oder ein heller Feldrand kann unsichtbar sein. WCAG 2.2, Kriterium 1.4.11, verlangt mindestens 3:1 gegenüber angrenzenden Farben für die Teile von Bedienelementen und Grafiken, die man zum Verstehen braucht, etwa den Rand eines Eingabefelds oder ein einzelnes Icon. Inaktive Elemente sind ausgenommen. So prüfst du: Icon- und Rahmenfarben gegen den Hintergrund messen.
- Dunkelmodus. Warum: Eine Palette, die hell besteht, kann dunkel durchfallen. So prüfst du: Punkte 1 bis 5 im Dunkelmodus wiederholen.
- Farbe ist nicht das einzige Signal. Warum: Rot und Grün allein scheitern bei Farbsehschwäche. So prüfst du: Screenshot in Graustufen ansehen; Fehler und Zustände müssen klar bleiben (Icon oder Text ergänzen).
Prüfung 2: Tippflächen
- Kleinste tippbare Elemente. Warum: Schließen-Buttons, Icons und Checkboxen sind meist die Übeltäter. So prüfst du: Entwickler-Overlays (zum Beispiel Zeigerposition) einschalten oder im Layout-Inspektor messen; unter Android mit 48dp vergleichen.
- Abstand zu Nachbarn. Warum: Zwei kleine Ziele nebeneinander führen zu Fehltipps. So prüfst du: Mit dem Daumen auf einem echten Gerät schnell tippen und Fehltipps zählen.
- Textlinks im Fließtext. Warum: Ein Link in einer Textzeile ist schwer zu treffen. So prüfst du: Jeden einzelnen antippen; wichtige Aktionen besser als Button anbieten.
- Ränder und Ecken. Warum: Gesten und Bildschirmrand stören Elemente in Randnähe. So prüfst du: Einhändig Elemente nahe dem Rand antippen.
- Große Schrift und Anzeigegröße. Warum: Skalierung ändert Layouts und kann Ziele schrumpfen oder überlappen lassen. So prüfst du: Größte Schrift und Anzeigegröße einstellen und Punkte 1 bis 4 wiederholen.
Festhalten
Notiere Screen, Element, gemessenen Wert und den benutzten Grenzwert. Trage es dann in deinen Testplan oder einen Testfall ein.
Weiterlesen
- Übersicht: Checklisten für mobile App-Tests
- Testplan-Vorlage für mobile Apps
- Testfall-Vorlage mit Beispielen
Starte bei AppReviewX und bekomme privates, strukturiertes Feedback von anderen Entwicklern dazu, wie deine App wirkt.