Apps auf Barrierefreiheit testen: So erkennst du typische Probleme frühzeitig

Wann hast du zuletzt eine App getestet – und trotzdem nicht gemerkt, wo Nutzende wirklich scheitern?

Typische Beispiele: Ein „Weiter“-Button ist visuell sauber gestaltet – aber in der Nutzung so klein, dass Nutzende ihn mehrfach verfehlen. Oder ein Kontrast, der im Design funktioniert hat, unter realen Bedingungen aber kaum noch lesbar ist. Oder ein Video ohne Untertitel, das in bestimmten Nutzungssituationen nicht zugänglich ist.

Das sind keine Sonderfälle. Das sind Design- und Entwicklungsentscheidungen, die darüber entscheiden, ob eine App funktioniert – oder nicht.

Der Unterschied: Für viele sind das Momente der Frustration. Für Menschen mit Sehbehinderung, motorischen Einschränkungen oder eingeschränktem Hörvermögen sind es keine Ausnahmen, sondern die tägliche Nutzung.

Genau hier liegt der Hebel: Barrierefreiheit darf nicht als Nachbesserung gedacht werden, sondern muss Teil von Design, Entwicklung und Testing sein. Wie du typische Barrieren frühzeitig im eigenen Testing erkennst und systematisch vermeidest, zeigen wir dir im nächsten Schritt.

Drei schnelle Checks für dein Testing

Viele grundlegende Barrieren lassen sich bereits im eigenen Workflow erkennen – ohne zusätzliche Tools. Diese drei Checks helfen dir, typische Probleme früh sichtbar zu machen:

1. Textskalierung testen

Erhöhe die Systemschrift deines Smartphones auf „Groß“. Passt sich die App sauber an – oder bricht das Layout auseinander?

Wenn Inhalte abgeschnitten werden, überlappen oder nicht mehr lesbar sind, ist das ein klares Zeichen dafür, dass flexible Layouts nicht ausreichend berücksichtigt wurden – besonders problematisch für Nutzende, die auf größere Schrift angewiesen sind.

2. Kontrast unter realen Bedingungen prüfen

Ein Kontrast, der im Design-Tool gut aussieht, kann in der Nutzung schnell an seine Grenzen stoßen.

Prüfe kritische UI-Elemente bewusst unter realen Bedingungen – etwa bei hellem Umgebungslicht oder für Nutzende mit eingeschränkter Sehkraft. Wenn Inhalte schwer lesbar sind, ist das kein Designstil, sondern ein Accessibility-Problem.

3. Touch-Targets bewerten

Sind interaktive Elemente groß genug und ausreichend voneinander getrennt?

Kleine oder eng platzierte Buttons führen schnell zu Fehlinteraktionen – besonders bei einhändiger Nutzung, zitternden Händen oder eingeschränkter Feinmotorik. Ausreichend große Touch-Flächen sind keine Optimierung für Einzelfälle, sondern eine grundlegende UX-Anforderung.

Einen Schritt weiter: Der Screenreader-Test 

Einer der schnellsten Wege, Accessibility-Probleme sichtbar zu machen, ist ein Perspektivwechsel im Testing: die Nutzung ohne visuelle Orientierung.

Screenreader machen genau das möglich – sie geben Inhalte strukturiert aus und machen sichtbar, wie gut Semantik, Beschriftungen und Navigationslogik tatsächlich umgesetzt sind. Gleichzeitig wird sichtbar, ob deine App auch ohne visuelle Orientierung konsistent bedienbar ist. Für Menschen mit Sehbehinderung ist das die Grundlage der gesamten Nutzung.

• iOS: VoiceOver (Einstellungen → Bedienungshilfen) 

• Android: TalkBack (Einstellungen → Bedienungshilfen) 

So gehst du im Testing vor:
Aktiviere den Screenreader und navigiere schrittweise durch die App, indem du mit einem Finger von links nach rechts wischst. Elemente werden nacheinander fokussiert und vorgelesen, Aktionen führst du per Doppeltipp aus.

Versuche dabei, eine typische Aufgabe aus Nutzersicht zu erledigen – zum Beispiel ein Produkt in den Warenkorb zu legen oder ein Formular auszufüllen.

Achte dabei auf die semantische Ausgabe:

• Wird ein Element nur als „Schaltfläche“ oder „Bild“ vorgelesen, fehlt die semantische Information – Nutzende wissen nicht, welche Funktion es erfüllt.

• Wird hingegen klar benannt, was passiert – etwa „In den Warenkorb legen“ oder „Produktbild: blaues T-Shirt, Größe M“ – ist die App auf einem guten Weg.

Dieser Test gibt dir ein realistisches Gefühl dafür, wie zugänglich eine App tatsächlich ist. Gleichzeitig wird deutlich: Viele Probleme sind subtil – und lassen sich ohne systematisches Testing und echte Nutzungsperspektiven nur schwer zuverlässig identifizieren.

Die 7 häufigsten Screenreader-Probleme im Testing

Viele dieser Probleme bleiben selbst bei aktivem Screenreader unentdeckt. Sie entstehen durch fehlende Semantik, unklare Zustände oder fehlerhafte Fokusführung – und lassen sich ohne systematisches Testing und reale Nutzungsperspektiven nur schwer erkennen.

Die folgenden Beispiele stammen aus realen Anwendungen und treten in der Praxis deutlich häufiger auf, als man vermuten würde.

1. Elemente, die der Screenreader nicht erreicht

In einer Shopping-App sind Filteroptionen für Farbe oder Größe visuell sichtbar – für den Screenreader aber nicht zugänglich. Die Elemente sind nicht fokussierbar oder fehlen in der Accessibility-Struktur. Für Nutzende existiert diese Funktion schlicht nicht.

2. Zustände, die nicht kommuniziert werden

Ein Dropdown-Menü öffnet sich – aber der Screenreader gibt keinen Hinweis auf den veränderten Zustand. Eine Checkbox wird aktiviert, ohne Rückmeldung. Ohne korrekt gesetzte Zustände (z. B. „expanded“, „checked“) fehlt die notwendige Orientierung.

3. Statusmeldungen, die nur visuell erscheinen

„Artikel wurde in den Warenkorb gelegt“ – die Meldung erscheint kurz visuell und verschwindet wieder. Ohne entsprechende Live-Region oder Ankündigung bleibt sie für Screenreader-Nutzende unsichtbar.

4. Interaktionen ohne klaren Ausweg

Eine Fehlermeldung erscheint, blockiert die Oberfläche – lässt sich aber nicht schließen oder verlassen. Der Screenreader liest sie zwar vor, bietet aber keinen klaren Fokus oder Weg zurück in den Flow.

5. Fokusführung ohne Kontext

Der Screenreader springt in Bereiche, die visuell nicht aktiv sind – etwa in einen minimierten Kalender. Nutzende navigieren durch Inhalte, die aktuell keine Funktion haben. Ohne konsistente Fokuslogik entsteht Desorientierung.

6. Bilder ohne semantische Beschreibung

Ein Produktbild wird lediglich als „Bild“ ausgegeben. Ohne Alternativtext fehlen zentrale Informationen wie Farbe, Form oder Kontext – das Element verliert seinen inhaltlichen Wert.

7. Eingabefelder ohne eindeutige Beschriftung

Ein Feld wird als „Textfeld“ angekündigt, ohne Label oder Kontext. Nutzende wissen nicht, welche Information erwartet wird. Ohne korrekt zugeordnete Labels sind Formulare nicht nutzbar.

Selbst testen reicht nicht aus

Die drei Checks aus diesem Artikel lassen sich direkt in deinen bestehenden Workflow integrieren – ohne zusätzliche Tools oder großen Aufwand. Sie helfen dir, grundlegende Barrieren früh sichtbar zu machen und typische UX-Probleme schneller zu erkennen.

Gleichzeitig zeigt sich in der Praxis: Barrierefreiheit geht deutlich tiefer. Viele der beschriebenen Probleme entstehen durch fehlende Semantik, unklare Zustände oder fehlerhafte Fokusführung – und lassen sich ohne systematisches Testing und reale Nutzungsperspektiven nur schwer vollständig erfassen.

Genau hier setzt Eye-Able an: Wir kombinieren technisches Testing mit der Perspektive von Menschen, die Apps täglich mit Screenreader und anderen Hilfsmitteln nutzen – und decken so Barrieren auf, die im klassischen QA-Prozess oft verborgen bleiben.

Gemeinsam mit unserem Partner Abra verbinden wir automatisierte Checks mit manuellen Tests durch unser Expertenteam – für einen ganzheitlichen Blick auf die Barrierefreiheit deiner App, direkt in deinem Entwicklungs- und QA-Prozess.

Automatisierte Tests identifizieren typische technische Probleme wie fehlerhafte Textskalierung, unzureichenden Kontrast oder fehlende Beschriftungen. Manuelle Prüfungen und Tests mit echten Nutzenden zeigen zusätzlich, wie sich diese Probleme in der realen Nutzung auswirken – genau dort, wo reine Tool-Analysen an ihre Grenzen stoßen.