Ce qu'un audit d'accessibilité détecte — et ce que seul un lecteur d'écran révélera

L'accessibilité est devenue une condition de mise en production plutôt qu'un bonus vers juin 2025, quand l'Acte européen sur l'accessibilité a commencé à s'appliquer aux produits numériques grand public vendus dans l'UE. Beaucoup d'équipes ont réagi en lançant un audit automatique, en corrigeant ce qu'il signalait, et en considérant l'affaire close.

C'est un bon premier geste et un mauvais dernier geste. Les vérifications automatiques sont excellentes sur une bande de problèmes précise et étroite, et structurellement incapables de trouver le reste — or c'est le reste qui empêche réellement quelqu'un d'utiliser votre application.

Voici le partage honnête des tâches.

Ce que l'automatisation détecte réellement

Ce sont des points vérifiables par une machine parce qu'ils portent sur des propriétés de l'arbre, pas sur du sens. Chacun mérite d'être détecté en intégration continue, à chaque build :

Libellés manquants. Un contrôle sans libellé d'accessibilité est annoncé « bouton » — ou pire, sous son identifiant de ressource, ou pas du tout. C'est le constat le plus fréquent des audits mobiles et il se corrige en une ligne. contentDescription sur Android, accessibilityLabel sur iOS.

Cibles tactiles sous le minimum. WCAG 2.2 a ajouté Taille de la cible (minimum) à 24 × 24 pixels CSS pour le niveau AA. Les recommandations des plateformes sont plus strictes et plus utiles comme chiffre de travail : les HIG d'Apple parlent de 44 × 44 pt, Material de 48 × 48 dp. Une cible trop petite est d'abord un problème d'accessibilité motrice, mais c'est un problème d'ergonomie pour tout le monde — une cible qu'on n'atteint pas de façon fiable dans le train est mauvaise pour tous les utilisateurs, pas seulement pour certains.

Contraste sous le seuil. 4,5:1 pour le texte courant, 3:1 pour le grand texte et les composants d'interface. Celui-ci ressort sans arrêt sur les éléments exacts auxquels les designers tiennent le plus : texte d'invite gris clair, boutons qui ont l'air désactivés sans l'être, texte sur image de bannière.

Identifiants manquants ou dupliqués. Deux contrôles portant le même libellé, ou un libellé qui dit seulement « image », rendent impossible pour un utilisateur de lecteur d'écran de distinguer deux actions différentes.

Trous dans l'ordre de parcours. Des éléments que l'arbre d'accessibilité ne peut pas atteindre du tout — d'ordinaire une vue personnalisée qui se dessine elle-même et n'expose jamais rien.

Automatisez ces vérifications. Elles sont peu coûteuses, elles sont déterministes, et un build devrait échouer sur une régression. Sur un appareil réel, le même audit reflète en outre la mise en page réellement rendue, ce qui compte pour les contrôles de taille et de contraste — une cible de 48 dp dans le fichier de layout peut être rognée en dessous par un parent sur un petit écran.

Ce que l'automatisation ne peut pas détecter, par construction

Chacun des points ci-dessous porte sur le sens, et aucune analyse statique n'a accès au sens.

Des libellés présents mais inutiles. contentDescription="button1" passe toutes les vérifications automatiques jamais écrites. accessibilityLabel="image" aussi. Et un libellé sur une icône de suppression qui dit « corbeille » alors que la boîte de dialogue de confirmation dit « retirer » : techniquement libellé, réellement déroutant. L'automatisation vérifie la présence ; seul un humain vérifie que le libellé dit bien ce que fait le contrôle.

Un ordre de lecture licite et pourtant faux. L'arbre d'accessibilité peut être complet et parcourable tout en présentant un prix avant le produit auquel il se rapporte, ou en lisant le badge d'une carte avant son titre. Rien ne manque, donc rien n'est signalé. En balayant l'écran, on le remarque en dix secondes.

Un focus qui atterrit au mauvais endroit. Vous ouvrez une fenêtre modale — où va le focus ? Après la suppression d'un élément, où va-t-il ? Après une erreur, l'utilisateur est-il prévenu, ou le focus reste-t-il sur un champ désormais entouré de rouge qu'il ne peut pas voir ? Ce sont ces interactions qui déterminent si une application est utilisable au lecteur d'écran, et elles sont invisibles dans un instantané de l'arbre.

Un état non annoncé. Un interrupteur qui a l'air actif mais n'expose pas son état. Un indicateur de chargement qui n'annonce jamais « chargement ». Une erreur de formulaire qui apparaît visuellement et n'est jamais énoncée. Le contrôle est libellé ; c'est le changement qui n'est pas communiqué.

Des gestes personnalisés sans solution de rechange. Balayer pour supprimer, menus par appui long, pincer pour zoomer, glisser pour réordonner. Un lecteur d'écran intercepte les gestes que l'application attend : sans chemin alternatif — une action personnalisée, un bouton visible — la fonctionnalité est tout simplement indisponible.

Texte dynamique et grandes tailles. Poussez la police système à son réglage maximal et regardez les mises en page s'effondrer : libellés tronqués, boutons dont le texte disparaît, lignes qui se chevauchent. C'est la vérification d'accessibilité la plus souvent omise et l'une des plus souvent nécessaires — la population qui utilise du grand texte est bien plus large que celle qui utilise un lecteur d'écran.

Les éditeurs de moteurs automatiques annoncent généralement détecter entre un tiers et la moitié des problèmes réels. Quel que soit le chiffre exact, la moitié qu'ils manquent n'est pas un échantillon aléatoire : elle se concentre précisément sur le comportement interactif et contextuel qui détermine si l'application est utilisable tout court.

La passe manuelle qui vaut vraiment le coup

Vous n'avez pas besoin d'un audit complet à chaque sprint. Vous avez besoin d'une passe reproductible de 20 minutes sur vos parcours critiques — inscription, action principale, paiement, réglages.

1. Lecteur d'écran seul, écran éteint si possible. Activez VoiceOver (iOS) ou TalkBack (Android) et menez le parcours à son terme sans regarder. Pas « vérifier les libellés » — mener le parcours à son terme. L'endroit où vous restez bloqué est le constat, et il se trouve généralement là où aucune vérification statique ne regardait.

2. Balayez chaque écran linéairement. Ne tapez pas un peu partout ; balayez vers la droite de façon répétée, comme navigue réellement un utilisateur de lecteur d'écran. Vous vérifiez deux choses : l'ordre a-t-il du sens, et quelque chose est-il inatteignable.

3. Taille de texte maximale. Réglages système, plus grande taille dynamique, et refaites les mêmes parcours. Cherchez les troncatures, les chevauchements et les boutons qui ont perdu leur libellé.

4. À une main, au pouce. Ce n'est pas un critère d'accessibilité formel, mais cela révèle la même classe de problèmes de taille et d'accessibilité des cibles que les limitations motrices amplifient.

5. Vérifiez les trois états que personne ne vérifie. Chargement, vide et erreur. Les erreurs surtout : si un message de validation apparaît visuellement sans être annoncé, un utilisateur de lecteur d'écran soumet le formulaire encore et encore sans la moindre idée de ce qui ne va pas.

Notez ce que vous trouvez à chaque fois. Les cinq mêmes constats qui reviennent de version en version en disent long sur vos composants, pas sur vos écrans — corrigez le composant bouton partagé une fois, au lieu de corriger quarante instances.

L'intégration au pipeline

Un partage viable, par coût croissant :

Fréquence	Vérification
À chaque build	Audit automatique sur les écrans clés ; échec sur toute nouvelle violation
À chaque version	Passe au lecteur d'écran sur les parcours critiques ; passe en texte maximal
Chaque trimestre	Audit manuel complet, idéalement avec une personne qui utilise des technologies d'assistance au quotidien

La formulation « échec sur toute nouvelle violation » compte. Échouer sur toutes les violations, c'est garantir qu'une équipe avec un arriéré existant désactive la vérification dès la première semaine. Établissez une référence de l'existant, bloquez ce qui s'y ajoute, et résorbez la référence délibérément.

Sur RobotActions, la moitié automatique s'exécute sur un appareil réel au sein d'une session : l'audit lit l'arbre d'accessibilité en direct, donc les libellés, les tailles de cible et les contrastes sont évalués sur ce qui a réellement été rendu sur ce matériel, et vous pouvez capturer un aperçu de lecteur d'écran pour un écran afin d'en vérifier l'ordre annoncé sans avoir l'appareil physiquement sous la main. Cela couvre la bande vérifiable par la machine et rend la passe manuelle moins coûteuse, puisque vous parcourez les écrans sur un appareil déjà mis à disposition plutôt qu'en cherchant un téléphone disponible.

La passe manuelle doit tout de même avoir lieu. Il n'existe aucune version de tout ceci où elle n'a pas lieu.

Ce qu'il faut dire à voix haute

Chaque correctif de la colonne automatique est aussi un correctif pour les personnes qui n'utilisent aucune technologie d'assistance. Des cibles plus grandes aident tout le monde dans un bus cahotant. Un meilleur contraste aide tout le monde en plein soleil. Un texte qui survit à une police agrandie aide tout le monde après quarante ans. Et des libellés qui décrivent ce que fait un contrôle aident vos propres tests automatisés à trouver les éléments de façon fiable — une application dotée d'un arbre d'accessibilité complet est mesurablement plus facile à automatiser, parce que vous pouvez cesser de deviner des XPath et sélectionner par les mêmes identifiants qu'un lecteur d'écran.

Ce dernier point mérite d'être pris au sérieux si vous devez défendre ce travail en interne. Un balisage accessible et une automatisation de test stable sont le même investissement décrit de deux façons.

Lancez un audit d'accessibilité sur un appareil réel →