Tester l’accessibilité d’une app : lecteur d’écran et WCAG

Fermez les yeux, puis essayez d’acheter un forfait internet sur votre téléphone. Impossible ? Pour une personne aveugle, c’est pourtant un geste ordinaire : son téléphone lit l’écran à voix haute et elle navigue du doigt, élément par élément. À une condition : que l’app ait été pensée, et testée, pour cela. Un seul bouton sans nom, et le parcours s’arrête net.

L’Organisation mondiale de la santé estime que 1,3 milliard de personnes vivent avec un handicap important, soit environ une personne sur six. Ce ne sont pas des cas rares : ce sont des clients, des élèves, des patients, des parents.

Cet article vous apprend à tester une app avec TalkBack et VoiceOver, à vérifier le contraste, la taille des cibles, le texte agrandi et la navigation au clavier, puis à rapporter un défaut d’accessibilité avec le bon critère WCAG.

Pourquoi l’accessibilité concerne bien plus de monde qu’on ne le croit

L’accessibilité, c’est la possibilité pour chacun d’utiliser l’app, quelles que soient ses capacités. Elle concerne quatre groupes, et vous appartiendrez un jour à l’un d’eux :

• Les handicaps durables : cécité, basse vision, daltonisme, surdité, tremblements, usage d’un seul doigt, dyslexie, troubles de l’attention.
• Les situations temporaires : un bras dans le plâtre après une chute de moto, des lunettes cassées, une opération de l’œil.
• Les situations du moment : le soleil de midi sur l’écran au marché, un taxi bruyant où l’on n’entend pas la vidéo, un enfant dans un bras et le téléphone dans l’autre main.
• Le vieillissement : vos parents qui règlent la taille du texte au maximum et touchent l’écran avec moins de précision.

Ce que vous corrigez pour les uns profite à tous. Un bon contraste se lit mieux en plein soleil ; un gros bouton se touche mieux dans un bus qui secoue.

Le droit s’en mêle aussi. Dans l’Union européenne, l’Acte européen sur l’accessibilité (directive 2019/882) s’applique depuis le 28 juin 2025 à de nombreux produits et services, dont le commerce en ligne, les services bancaires, les livres numériques et le transport de voyageurs. Une app africaine qui vend aussi en Europe peut donc être concernée. Ailleurs, les règles varient d’un pays à l’autre : si votre app vise un marché précis, faites vérifier ses obligations par un juriste plutôt que de supposer qu’il n’y en a aucune.

WCAG 2.2 en clair : quatre principes, trois niveaux

WCAG range 13 règles sous quatre principes. Chaque règle se décline en critères de succès vérifiables, numérotés (par exemple 1.4.3) et classés en trois niveaux : A (le minimum), AA et AAA (le plus exigeant). La plupart des projets visent le niveau AA, qui inclut le niveau A.

Le tableau suivant traduit les quatre principes en questions de testeur, avec un défaut typique sur mobile.

La version 2.2 ajoute neuf critères, dont la taille minimale des cibles, le focus qui ne doit pas être masqué et une connexion sans énigme à résoudre. Elle retire un ancien critère devenu obsolète, 4.1.1.

Comment tester avec un lecteur d’écran : TalkBack et VoiceOver pas à pas

Activer TalkBack sur Android

Ouvrez Paramètres > Accessibilité > TalkBack, puis activez Utiliser TalkBack. Si le raccourci est configuré, maintenir enfoncées les deux touches de volume pendant quelques secondes active ou désactive TalkBack.

Activer VoiceOver sur iPhone

Ouvrez Réglages > Accessibilité > VoiceOver, ou demandez à Siri « Active VoiceOver ». Le raccourci d’accessibilité, une fois configuré, permet aussi de l’allumer et de l’éteindre. Les réglages de VoiceOver proposent une zone d’entraînement pour essayer les gestes sans rien déclencher.

Les gestes essentiels

Ce tableau compare les gestes de base des deux lecteurs d’écran.

Le protocole en six étapes

1. Parcourez chaque écran élément par élément, du haut vers le bas, en balayant. Notez ce que vous entendez.
2. Vérifiez les noms. Chaque élément interactif doit avoir un nom clair : « Payer 5 000 FCFA », pas « Bouton », « Image » ou « ic_pay_24 ».
3. Vérifiez les rôles et les états : « bouton », « case cochée », « désactivé », « onglet 2 sur 4 ».
4. Vérifiez l’ordre : la lecture suit-elle la logique de l’écran ? Les images purement décoratives sont-elles ignorées ?
5. Faites le parcours principal sans regarder. Sur iPhone, le rideau d’écran (toucher trois fois avec trois doigts) éteint l’affichage tout en laissant l’écran actif : vous êtes dans les conditions d’un utilisateur aveugle.
6. Écoutez les changements : un message d’erreur est-il lu ? Quand une fenêtre s’ouvre, la sélection va-t-elle dedans ? Entend-on la fin d’un chargement ?

Contraste, cibles, texte agrandi : les vérifications visuelles

Le contraste. Le texte doit atteindre un rapport de contraste de 4,5:1 avec son fond, ou 3:1 s’il est grand, c’est-à-dire au moins 18 points, ou 14 points en gras (critère 1.4.3, niveau AA). Les bordures de champs, les icônes seules et les indicateurs d’état doivent atteindre 3:1 (1.4.11). Sur Android, l’application Accessibility Scanner signale les contrastes insuffisants ; sur le web, un vérificateur de contraste fait le même travail.

La couleur seule. Un champ en erreur signalé uniquement par une bordure rouge échappe à une personne daltonienne. Ajoutez une icône ou un texte (1.4.1, niveau A).

Les cibles tactiles. WCAG 2.2 demande au moins 24 × 24 pixels CSS par cible, ou assez d’espace autour (2.5.8, AA) ; le niveau AAA monte à 44 × 44. Android recommande au moins 48 × 48 dp. Testez au pouce, sur le plus petit téléphone : les petites croix, les liens collés les uns aux autres, les cases à cocher minuscules.

Le texte agrandi. Le texte doit pouvoir grossir jusqu’à 200 % sans perte de contenu ni de fonction (1.4.4, AA). Réglez la taille du texte du téléphone au maximum : sur iPhone, dans Réglages > Accessibilité > Affichage et taille du texte > Police plus grande ; sur Android, dans les paramètres d’affichage ou d’accessibilité, selon les marques. Cherchez les textes coupés (« Confir… »), superposés, les boutons poussés hors de l’écran et, pire, les textes qui ne grossissent pas du tout.

L’adaptation à l’écran. Sur le web, le contenu doit rester utilisable sur 320 pixels CSS de large sans défilement horizontal (1.4.10, AA), ce qui correspond à un zoom de 400 % sur un écran de 1 280 pixels.

L’orientation. L’app ne doit pas imposer le mode portrait ou paysage, sauf si c’est indispensable (1.3.4, AA). Pensez à la personne dont le téléphone est fixé sur un fauteuil roulant.

Comment tester la navigation au clavier sur le web

Le test le plus rapide de l’accessibilité web tient en un geste : rangez la souris. Utilisez seulement Tab et Maj + Tab pour avancer et reculer, Entrée et Espace pour activer, les flèches dans les menus et Échap pour fermer. Vérifiez que :

• tout ce qui se clique peut aussi s’atteindre et s’utiliser au clavier (2.1.1, A) ;
• vous pouvez toujours sortir d’une fenêtre ou d’un menu, sans piège (2.1.2, A) ;
• l’ordre de déplacement suit la logique de la page (2.4.3, A) ;
• l’élément sélectionné est toujours entouré d’un indicateur visible (2.4.7, AA) ;
• cet élément n’est jamais caché sous un bandeau collant, une bannière de cookies ou une bulle de discussion (2.4.11, AA, nouveau dans la version 2.2) ;
• un lien permet de sauter le menu répété pour aller au contenu principal (2.4.1, A).

Votre liste de contrôle d’accessibilité en 19 points

Voici la liste à dérouler sur chaque écran important, avec le numéro du critère WCAG correspondant.

• Chaque image utile a une alternative textuelle ; les images décoratives sont ignorées (1.1.1)
• Les vidéos ont des sous-titres (1.2.2)
• Le texte atteint un contraste de 4,5:1, ou 3:1 s’il est grand (1.4.3)
• Bordures de champs, icônes et états atteignent 3:1 (1.4.11)
• Aucune information ne passe par la couleur seule (1.4.1)
• Le texte agrandi à 200 % reste complet et lisible (1.4.4)
• L’app fonctionne en portrait comme en paysage (1.3.4)
• Chaque bouton-icône a un nom parlé clair (4.1.2)
• Rôles et états sont annoncés correctement (4.1.2)
• Les messages d’état (« Paiement envoyé ») sont annoncés sans déplacer la sélection (4.1.3)
• Les cibles mesurent au moins 24 × 24 pixels CSS, idéalement 48 × 48 dp sur Android (2.5.8)
• Toute action par glissement a une alternative par simple appui (2.5.7)
• Tout se fait au clavier, sans piège (2.1.1, 2.1.2)
• Le focus est visible et jamais masqué (2.4.7, 2.4.11)
• Les limites de temps peuvent être prolongées quand c’est possible (2.2.1)
• Chaque champ a une étiquette visible et annoncée (3.3.2)
• Les erreurs sont décrites en texte, avec la façon de les corriger (3.3.1, 3.3.3)
• La connexion ne repose pas sur une énigme ou un effort de mémoire sans aide : le collage et les gestionnaires de mots de passe fonctionnent (3.3.8)
• La langue de l’app est déclarée, pour que la voix prononce correctement le français ou l’anglais (3.1.1)

Comment rapporter un défaut d’accessibilité

Un défaut d’accessibilité se rapporte comme un autre bug, avec trois informations en plus : la technologie d’assistance utilisée, ce que vous avez entendu mot pour mot, et le critère WCAG concerné. Voici un modèle.

Titre : TalkBack annonce « Image » sur les touches du code secret (paiement impossible)
Contexte : Android 15, TalkBack activé, taille de police par défaut
Étapes : 1. Ouvrir « Envoyer de l'argent »  2. Saisir le montant  3. Arriver au code secret
Entendu : « Image, image, image » pour chaque touche
Attendu : « 1 », « 2 », « 3 »… et « Effacer »
Critère : WCAG 2.2, 4.1.2 Nom, rôle et valeur (niveau A)
Impact : bloquant, un utilisateur de lecteur d'écran ne peut pas payer
Suggestion : donner un nom accessible à chaque touche

Classez la gravité selon l’impact réel : un défaut qui empêche un utilisateur de lecteur d’écran de payer est aussi grave, pour lui, qu’un plantage. Pour tout le reste de la rédaction, appuyez-vous sur le guide du rapport de bug efficace.

Une heure d’entraînement ne fait pas de vous un utilisateur expert de TalkBack. Dès que possible, organisez un test utilisateur avec des personnes qui se servent d’un lecteur d’écran au quotidien : elles trouveront ce qu’aucune liste ne prévoit. Et si vous voulez faire de ces vérifications votre métier, commencez par devenir testeur.

Pour aller plus loin

• Règles pour l’accessibilité des contenus web (WCAG) 2.2, W3C (nouvel onglet) (en anglais) : le texte officiel, avec les quatre principes et chaque critère de succès.
• Handicap, aide-mémoire de l’OMS (nouvel onglet) : l’estimation de 1,3 milliard de personnes vivant avec un handicap important.
• Gestes TalkBack, aide Accessibilité Android (nouvel onglet) : la liste complète des gestes, selon la version de TalkBack.
• Utiliser les gestes VoiceOver sur l’iPhone, assistance Apple (nouvel onglet) : tous les gestes, dont le rideau d’écran.
• Rendre les applications plus accessibles, Android Developers (nouvel onglet) : taille des cibles de 48 dp, contraste, noms des éléments et Accessibility Scanner.
• Directive (UE) 2019/882 relative aux exigences en matière d’accessibilité, EUR-Lex (nouvel onglet) : le texte de l’Acte européen sur l’accessibilité et sa date d’application.