Votre app créée par IA est-elle accessible à tout le monde ? Un guide simple sur l'accessibilité

Quand vous créez une app avec l’IA, vous la testez comme vous vous en servez : votre écran, vos yeux, votre prise à deux mains bien stable sur un ordinateur portable. Le problème, c’est qu’une bonne partie des gens qui ouvriront votre app ne l’utilisent pas de cette façon-là. Il y a la personne qui zoome le texte de son téléphone à deux fois la taille normale. Celle qui ne distingue pas votre message d’erreur rouge du texte noir qui l’entoure. Celle qui tient un bébé dans les bras et tape avec un seul pouce. L’accessibilité d’une app, c’est simplement de savoir si ces personnes peuvent quand même s’en sortir — et c’est une question que la plupart des apps créées par IA ne se posent jamais.

Pas besoin d’un diplôme ni d’une équipe de conformité pour s’en occuper. Il suffit de connaître les quatre ou cinq endroits où les apps mettent habituellement des gens à l’écart, et de savoir comment demander à votre outil de création de les corriger. Laissez-moi vous montrer les cas les plus fréquents à travers des histoires concrètes, car ils sont plus faciles à repérer une fois qu’on les a vus.

Pourquoi la mise en page de mon app se casse-t-elle quand quelqu’un zoome ?

Parce que la plupart des apps créées par IA sont conçues pour une seule taille de texte fixe. Donc quand quelqu’un agrandit le texte de son téléphone ou de son navigateur — ce que beaucoup de gens font, en particulier les plus de soixante ans — les boutons se chevauchent, les colonnes s’effondrent en un empilement illisible, et les commandes glissent les unes sous les autres.

Une créatrice que je connais a bâti une jolie petite app de prise de rendez-vous pour le salon de coiffure de sa mère. Ça avait fière allure. Puis sa mère l’a ouverte, et la première chose qu’elle a faite — comme beaucoup de gens de plus de soixante ans — a été de pincer l’écran pour agrandir le texte. La mise en page s’est effondrée. Les boutons se chevauchaient, le bouton « Réserver » glissait sous le menu, et une colonne d’horaires s’est transformée en un empilement brouillon et illisible.

C’est la rupture d’accessibilité la plus fréquente dans les apps créées par IA, et elle reste invisible jusqu’à ce que quelqu’un zoome. Demandez à votre outil de création : « Assure-toi que la mise en page fonctionne toujours quand le texte est zoomé à 200 %. Rien ne doit se chevaucher ni être coupé. » Puis testez-le vous-même — sur votre téléphone, poussez la taille de police du système au maximum et ouvrez votre app. Si tout part en morceaux, voilà votre première correction à faire.

Pourquoi ne pas utiliser uniquement la couleur pour indiquer un statut dans mon app ?

Parce qu’environ un homme sur douze perçoit les couleurs différemment, le plus souvent le rouge et le vert — donc un statut affiché uniquement par un point rouge ou un point vert leur paraît identique, et ils ne peuvent tout simplement pas distinguer « payé » de « en retard ».

Un freelance a créé un suivi de factures qui affichait le statut uniquement par la couleur — point vert, point rouge. Un de ses clients, qui se trouvait être daltonien rouge-vert, continuait à payer des factures déjà réglées parce que les deux points lui paraissaient identiques. L’information était bien là. Elle n’était simplement pas accessible pour lui.

La solution est une habitude à prendre, pas une fonctionnalité à ajouter : ne jamais faire reposer un message uniquement sur la couleur. Ajoutez un mot, une icône ou une forme à côté. « En retard » à côté du rouge. Une coche à côté du vert. Un astérisque et le mot « obligatoire », pas seulement un contour rouge. La couleur peut rester — elle ne peut simplement pas porter le message toute seule.

Pourquoi les lecteurs d’écran disent-ils juste « bouton » au lieu de le nommer ?

Parce qu’un bouton-icône sans libellé — une corbeille, un crayon, une loupe sans aucun mot — n’a pas de texte que le lecteur d’écran (le logiciel que les personnes aveugles ou malvoyantes utilisent pour se faire lire l’écran à voix haute) puisse annoncer, alors il lit, littéralement, « bouton ». Pas « supprimer ». Pas « modifier ». Juste « bouton ».

Les outils de création IA adorent les boutons-icônes épurés parce qu’ils ont l’air modernes. Mais imaginez utiliser une app où chaque commande s’appelle « bouton » et où il faut deviner. Vous n’avez pas besoin d’ajouter un texte visible à chaque icône — vous devez vous assurer que chaque commande a un nom sous-jacent, même invisible, que le lecteur d’écran peut annoncer. Demandez à votre outil de création : « Donne à chaque bouton-icône un libellé accessible — une icône de corbeille doit être annoncée comme “Supprimer”, un crayon comme “Modifier”. » C’est un petit changement, et c’est ce qui fait la différence entre une app qu’une personne aveugle peut parcourir et un mur de boutons anonymes.

Quelle taille doivent avoir les zones tactiles sur une app mobile ?

La règle approximative des designers, c’est que tout élément cliquable devrait mesurer environ 44 pixels — à peu près la taille d’un bout de doigt —, avec un vrai espacement pour que deux éléments cliquables ne soient pas collés bord à bord.

Observez quelqu’un utiliser votre app d’une seule main dans le bus. Les pouces sont larges et imprécis, le bus bouge, et votre « X » pour fermer n’est qu’un point de 16 pixels dans un coin. La personne le rate deux fois, touche par erreur ce qui se trouve derrière, et abandonne. Des zones tactiles petites et serrées sont un problème d’accessibilité, pas juste une gêne — elles pénalisent davantage les personnes qui ont des tremblements, des doigts plus larges, ou qui sont dans un environnement en mouvement. Demandez à votre outil de création : « Fais en sorte que les zones tactiles mesurent au moins 44 pixels et ajoute de l’espacement entre elles pour que les gens ne touchent pas la mauvaise. » Puis testez : ouvrez votre app sur votre téléphone et essayez l’action principale d’une seule main, en marchant. Si vous continuez à mal cliquer, tout le monde le fera aussi.

Comment tester l’accessibilité de mon app en cinq minutes ?

Vous pouvez repérer la plupart de ces problèmes vous-même, sans aucun outil, avec trois vérifications rapides sur l’écran le plus utilisé :

1. Zoomez. Poussez le texte de votre téléphone ou de votre navigateur à sa taille maximale et ouvrez l’écran principal. Est-ce que quelque chose se chevauche, disparaît ou est coupé ?
2. Retirez la couleur. Regardez tous les endroits où votre app utilise la couleur pour signifier quelque chose — statut, erreurs, champs obligatoires. Si vous imaginez tout ça en gris, pouvez-vous encore comprendre ce qui se passe ? Si non, ajoutez un mot ou une icône.
3. Activez le lecteur d’écran pendant deux minutes. iPhone (VoiceOver) et Android (TalkBack) en ont un intégré. Activez-le, fermez les yeux, et essayez de faire la chose principale pour laquelle votre app existe. Vous entendrez tout de suite quels boutons n’ont pas de nom.

Rien de tout cela n’exige d’être développeur. Il suffit d’arrêter, pendant cinq minutes, de tester en tant que vous-même, et de tester comme quelqu’un dont les mains, les yeux ou l’écran ne correspondent pas aux vôtres.

Vous n’avez pas à tout corriger d’un coup. Choisissez l’écran le plus utilisé — le formulaire de réservation, l’inscription, la liste principale — et faites en sorte qu’il fonctionne zoomé, sans couleur, et lu à voix haute. Cet écran unique, bien fait, touche plus de monde qu’un audit d’accessibilité complet des recoins que personne ne visite. Commencez par là, et la prochaine personne qui ouvrira votre app avec un seul pouce et un écran zoomé pourra être une utilisatrice à part entière, plutôt qu’un rebond de plus.