Können alle Ihre KI-erstellte App nutzen? Ein einfacher Leitfaden zur Barrierefreiheit

Wenn Sie eine App mit KI bauen, testen Sie sie so, wie Sie selbst sie nutzen: Ihr Bildschirm, Ihre Augen, Ihr sicherer beidhändiger Griff am Laptop. Das Problem ist: Ein echter Teil der Menschen, die Ihre App öffnen werden, nutzt sie ganz anders. Jemand zoomt den Handytext auf die doppelte Größe. Jemand kann Ihre rote Fehlermeldung nicht vom schwarzen Text drumherum unterscheiden. Jemand hält ein Baby und tippt mit einem Daumen. App-Barrierefreiheit ist schlicht die Frage, ob diese Menschen trotzdem durchkommen — und diese Frage stellt sich bei den meisten KI-erstellten Apps nie jemand.

Sie brauchen dafür keinen Abschluss und kein Compliance-Team. Sie müssen nur die vier oder fünf Stellen kennen, an denen Apps Menschen üblicherweise aussperren, und wissen, wie Sie Ihren Builder bitten, sie zu beheben. Ich zeige Ihnen die häufigsten anhand von Beispielen — sie sind leichter zu erkennen, wenn man sie einmal gesehen hat.

Warum bricht das Layout meiner App zusammen, wenn jemand hineinzoomt?

Weil die meisten KI-erstellten Apps für eine feste Textgröße gestaltet sind. Vergrößert jemand also den Text auf Handy oder im Browser — was viele Menschen tun, besonders alle über sechzig —, überlappen sich Buttons, Spalten stürzen zu einem wirren Stapel zusammen, und Bedienelemente rutschen übereinander.

Eine Macherin, die ich kenne, baute eine ordentliche kleine Terminbuchungs-App für den Friseursalon ihrer Mutter. Sah großartig aus. Dann öffnete ihre Mutter die App, und das Erste, was sie tat — wie viele Menschen über sechzig — war, mit zwei Fingern den Text größer zu zoomen. Das Layout fiel auseinander. Buttons überlappten sich, der „Buchen”-Button rutschte unter das Menü, und eine Spalte mit Uhrzeiten wurde zu einem wirren, unlesbaren Stapel.

Das ist der häufigste Barrierefreiheits-Fehler bei KI-erstellten Apps, und er ist unsichtbar, bis jemand zoomt. Bitten Sie Ihren Builder: „Stelle sicher, dass das Layout auch bei 200 % Textzoom noch funktioniert. Nichts darf sich überlappen oder abgeschnitten werden.” Testen Sie es dann selbst — stellen Sie auf Ihrem Handy die Systemschriftgröße auf die größte Stufe und öffnen Sie Ihre App. Zerfällt sie, ist das Ihre erste Baustelle.

Warum sollte meine App Status nicht allein über Farbe zeigen?

Weil etwa einer von zwölf Männern Farben anders wahrnimmt, am häufigsten Rot und Grün — ein Status, der nur als roter oder grüner Punkt dargestellt wird, sieht für sie gleich aus, und sie können „bezahlt” von „überfällig” schlicht nicht unterscheiden.

Ein Freelancer baute einen Rechnungstracker, der den Status rein über Farbe anzeigte — grüner Punkt, roter Punkt. Einer seiner Kunden, der rot-grün-blind war, bezahlte immer wieder bereits bezahlte Rechnungen, weil die beiden Punkte für ihn identisch aussahen. Die Information war da. Nur eben nicht für ihn.

Die Lösung ist eine Gewohnheit, kein Feature: Nutzen Sie Farbe nie als einzigen Träger einer Aussage. Ergänzen Sie sie um ein Wort, ein Icon oder eine Form. „Überfällig” neben dem Rot. Ein Häkchen neben dem Grün. Ein Sternchen und das Wort „Pflichtfeld”, nicht nur ein roter Rahmen. Farbe darf bleiben — sie darf die Botschaft nur nicht allein tragen.

Warum sagen Screenreader nur „Schaltfläche” statt sie zu benennen?

Weil ein unbeschrifteter Icon-Button — ein Papierkorb, ein Stift, eine Lupe ohne Worte — für den Screenreader (die Software, die blinde und sehbehinderte Menschen nutzen, um sich den Bildschirm vorlesen zu lassen) keinen Text zum Ansagen hat. Er liest wortwörtlich vor: „Schaltfläche.” Nicht „Löschen.” Nicht „Bearbeiten.” Nur „Schaltfläche.”

KI-Builder lieben cleane Icon-Buttons, weil sie modern aussehen. Aber stellen Sie sich vor, Sie nutzen eine App, in der jedes Bedienelement „Schaltfläche” heißt und Sie raten müssen. Sie müssen nicht jedem Icon sichtbaren Text hinzufügen — Sie müssen nur sicherstellen, dass jedes Element einen Namen darunter trägt, und sei er unsichtbar, den der Screenreader ansagen kann. Bitten Sie Ihren Builder: „Gib jedem Icon-Button eine zugängliche Beschriftung — ein Papierkorb-Icon soll als ‚Löschen’ angesagt werden, ein Stift als ‚Bearbeiten’.” Es ist eine kleine Änderung, und sie macht den Unterschied zwischen einer App, die ein blinder Nutzer bedienen kann, und einer, die nur eine Wand aus namenlosen Schaltflächen ist.

Wie groß sollten Tap-Bereiche in einer mobilen App sein?

Die Faustregel, die Designer verwenden: Alles Antippbare sollte etwa 44 Pixel groß sein — ungefähr die Größe einer Fingerkuppe —, mit echtem Abstand, damit zwei antippbare Elemente nicht Kante an Kante gequetscht sind.

Beobachten Sie jemanden, der Ihre App einhändig im Bus nutzt. Daumen sind breit und ungenau, der Bus fährt, und Ihr „X” zum Schließen ist ein 16-Pixel-Fleck in der Ecke. Er verfehlt es zweimal, trifft stattdessen das Element dahinter, gibt auf. Kleine, dicht gedrängte Tap-Bereiche sind ein Barrierefreiheitsproblem, kein bloßes Ärgernis — sie treffen Menschen mit Zittern, größeren Fingern oder einer bewegten Umgebung am härtesten. Bitten Sie Ihren Builder: „Mache Tap-Bereiche mindestens 44 Pixel groß und füge Abstand zwischen ihnen ein, damit niemand versehentlich das Falsche trifft.” Testen Sie es dann: Öffnen Sie Ihre App auf dem Handy und versuchen Sie die Hauptaktion einhändig, während Sie umhergehen. Verfehlen Sie ständig, wird es allen anderen genauso gehen.

Wie teste ich meine App in fünf Minuten auf Barrierefreiheit?

Die meisten dieser Probleme finden Sie selbst, ganz ohne Tools, mit drei kurzen Checks auf dem Bildschirm, den die Leute am meisten nutzen:

1. Zoomen Sie hinein. Stellen Sie Handy- oder Browsertext auf die größte Stufe und öffnen Sie den Hauptbildschirm. Überlappt sich etwas, verschwindet es, wird es abgeschnitten?
2. Nehmen Sie die Farbe raus. Schauen Sie sich jede Stelle an, an der Ihre App Farbe verwendet, um etwas zu bedeuten — Status, Fehler, Pflichtfelder. Stellen Sie sich alles in Grau vor: Erkennen Sie noch, worum es geht? Wenn nicht, ergänzen Sie ein Wort oder Icon.
3. Schalten Sie zwei Minuten lang den Screenreader ein. Sowohl iPhone (VoiceOver) als auch Android (TalkBack) haben einen eingebaut. Schalten Sie ihn ein, schließen Sie die Augen, und versuchen Sie, die Hauptfunktion Ihrer App zu nutzen. Sie hören sofort, welche Buttons namenlos sind.

Nichts davon setzt voraus, dass Sie Entwickler sind. Es setzt voraus, dass Sie fünf Minuten lang aufhören, als Sie selbst zu testen, und stattdessen testen als jemand, dessen Hände, Augen oder Bildschirm nicht Ihren entsprechen.

Sie müssen nicht alles auf einmal reparieren. Wählen Sie den einen Bildschirm, den die meisten Menschen nutzen — das Buchungsformular, die Anmeldung, die Hauptliste — und sorgen Sie dafür, dass genau dieser funktioniert, wenn er gezoomt, entfärbt und vorgelesen wird. Dieser eine, richtig gemachte Bildschirm erreicht mehr Menschen als ein ganzes Barrierefreiheits-Audit der Ecken, die niemand besucht. Fangen Sie dort an — und die nächste Person, die Ihre App mit einem Daumen und gezoomtem Bildschirm öffnet, wird zur Nutzerin statt zum Absprung.