Kan iedereen jouw AI-app gebruiken? Een duidelijke gids voor toegankelijkheid

Als je een app bouwt met AI, test je hem zoals jij hem gebruikt: jouw scherm, jouw ogen, jouw stevige tweehandige grip op een laptop. Het probleem is dat een flink deel van de mensen die jouw app openen dat niet zo doen. Iemand zoomt de tekst op zijn telefoon naar het dubbele van de normale grootte. Iemand kan jouw rode foutmelding niet onderscheiden van de zwarte tekst eromheen. Iemand houdt een baby vast en tikt met één duim. App-toegankelijkheid is simpelweg de vraag of die mensen er nog steeds doorheen komen — en het is een vraag die de meeste AI-gebouwde apps nooit gesteld krijgen.

Je hebt geen diploma of compliance-team nodig om dit aan te pakken. Je moet weten waar apps meestal mensen buitensluiten — vier of vijf plekken — en hoe je jouw builder vraagt om dat te verhelpen. Laat me je de meest voorkomende gevallen laten zien aan de hand van voorbeelden, want je herkent ze veel makkelijker zodra je ze een keer hebt gezien.

Waarom breekt de opmaak van mijn app als iemand inzoomt?

Omdat de meeste AI-gebouwde apps zijn ontworpen op één vaste tekstgrootte. Zodra iemand de tekst op zijn telefoon of in de browser groter maakt — iets wat veel mensen doen, vooral iedereen boven de zestig — gaan knoppen overlappen, vallen kolommen samen tot een verwarde stapel, en schuiven bedieningselementen onder elkaar.

Een maker die ik ken bouwde een keurige kleine afsprakenapp voor de kapsalon van haar moeder. Zag er goed uit. Toen opende haar moeder de app, en het eerste wat ze deed — zoals veel mensen boven de zestig — was inzoomen om de tekst groter te maken. De opmaak stortte in. Knoppen overlapten, de knop “Boeken” schoof onder het menu, en een kolom met tijden veranderde in een verwarde stapel die je niet meer kon lezen.

Dit is de meest voorkomende toegankelijkheidsfout in AI-gebouwde apps, en hij is onzichtbaar totdat iemand inzoomt. Vraag je builder: “Zorg ervoor dat de opmaak blijft werken als de tekst tot 200% wordt uitvergroot. Niets mag overlappen of worden afgesneden.” Test het daarna zelf — zet op je telefoon de systeemlettergrootte op de grootste stand en open je app. Als hij dan uit elkaar valt, is dat je eerste fix.

Waarom mag mijn app niet alleen kleur gebruiken om een status te tonen?

Omdat ongeveer één op de twaalf mannen kleuren anders waarneemt, meestal rood en groen — dus een status die alleen wordt getoond als een rode stip versus een groene stip, ziet er voor hen hetzelfde uit, en ze kunnen daadwerkelijk geen onderscheid maken tussen “betaald” en “achterstallig.”

Een freelancer bouwde een facturentracker die de status puur met kleur weergaf — groene stip, rode stip. Een van zijn klanten, die toevallig rood-groen kleurenblind was, bleef facturen betalen die al betaald waren, omdat de twee stippen er voor hem identiek uitzagen. De informatie was er wel. Alleen niet voor hem.

De oplossing is een gewoonte, geen functie: gebruik kleur nooit als enige manier om iets te communiceren. Voeg er een woord, icoon of vorm aan toe. “Achterstallig” naast het rood. Een vinkje naast het groen. Een asterisk met het woord “verplicht”, niet alleen een rode rand. Kleur mag blijven — het mag alleen niet de enige drager van de boodschap zijn.

Waarom zeggen screenreaders alleen “knop” in plaats van hem te benoemen?

Omdat een ongelabelde icoonknop — een prullenbak, een potlood, een vergrootglas zonder tekst — geen tekst heeft die de screenreader (de software die blinde en slechtziende mensen gebruiken om het scherm te laten voorlezen) kan aankondigen. Dus leest hij letterlijk voor: “knop.” Niet “verwijderen.” Niet “bewerken.” Gewoon “knop.”

AI-builders houden van strakke icoonknoppen omdat ze modern ogen. Maar stel je voor dat je een app gebruikt waarin elk bedieningselement “knop” heet en je moet raden wat het doet. Je hoeft niet bij elk icoon zichtbare tekst toe te voegen — je moet ervoor zorgen dat elk element een naam heeft, zelfs een onzichtbare die de screenreader kan aankondigen. Vraag je builder: “Geef elke icoonknop een toegankelijk label — een prullenbakicoon moet worden aangekondigd als ‘Verwijderen’, een potlood als ‘Bewerken’.” Het is een kleine aanpassing, en het is het verschil tussen een app die een blinde gebruiker kan navigeren en een app die een muur van naamloze knoppen is.

Hoe groot moeten tikdoelen zijn op een mobiele app?

De vuistregel die designers hanteren is dat alles wat aantikbaar is ongeveer 44 pixels moet zijn — ruwweg de grootte van een vingertop — met echte ruimte ertussen, zodat twee aantikbare elementen niet tegen elkaar aan geplakt zitten.

Kijk eens naar iemand die jouw app met één hand gebruikt in de bus. Duimen zijn breed en onnauwkeurig, de bus rijdt, en jouw “X” om te sluiten is een spikkeltje van 16 pixels in de hoek. Ze missen hem twee keer, raken één keer wat erachter zit, en geven het op. Kleine, opeengepakte tikdoelen zijn een toegankelijkheidsprobleem, geen simpel ongemak — ze treffen mensen met tremoren, grotere vingers, of een bewegende omgeving het hardst. Vraag je builder: “Maak tikdoelen minimaal 44 pixels en voeg ruimte tussen ze toe, zodat mensen niet het verkeerde raken.” Test het daarna: open je app op je telefoon en probeer de belangrijkste actie met één hand terwijl je rondloopt. Als jij steeds misklikt, doet iedereen dat.

Hoe test ik mijn app in vijf minuten op toegankelijkheid?

Je kunt het meeste hiervan zelf ontdekken zonder hulpmiddelen, met drie snelle checks op het scherm dat mensen het meest gebruiken:

1. Zoom erop in. Zet de tekst op je telefoon of in de browser op de grootste stand en open het hoofdscherm. Overlapt er iets, verdwijnt er iets, of wordt er iets afgesneden?
2. Haal de kleur eruit. Kijk naar elke plek waar jouw app kleur gebruikt om iets te betekenen — status, fouten, verplichte velden. Als je je alles in grijstinten voorstelt, kun je dan nog zien wat er aan de hand is? Zo niet, voeg een woord of icoon toe.
3. Zet twee minuten de screenreader aan. Zowel iPhone (VoiceOver) als Android (TalkBack) heeft er standaard een. Zet hem aan, sluit je ogen, en probeer het hoofddoel van je app te bereiken. Je hoort meteen welke knoppen naamloos zijn.

Niets hiervan vereist dat je developer bent. Het vereist dat je vijf minuten stopt met testen als jezelf, en test als iemand wiens handen, ogen of scherm niet overeenkomen met de jouwe.

Je hoeft niet alles in één keer op te lossen. Kies het ene scherm dat mensen het meest gebruiken — het boekingsformulier, de aanmelding, de hoofdlijst — en zorg dat dat scherm werkt wanneer het is uitgezoomd, ontdaan van kleur, en hardop voorgelezen. Dat ene scherm, goed uitgevoerd, bereikt meer mensen dan een volledige toegankelijkheidsaudit van de hoekjes die niemand bezoekt. Begin daar, en de volgende persoon die jouw app opent met één duim en een uitgezoomd scherm mag een gebruiker zijn in plaats van een afhaker.