Tester l’accès clavier d’un bouton : pourquoi le clic automatisé ne suffit pas

Un bouton peut ajouter un article au panier lorsqu’un test automatisé le clique, tout en restant inaccessible à une personne qui navigue avec Tab.

Dans une démonstration publiée par Alsacréations sur les tests clavier et les clics automatisés, trois variantes de « Ajouter au panier » fonctionnent au clic, mais Tab en ignore deux.

Pour une équipe produit ou une PME qui valide une application, la décision est donc simple : un test d’activation ne remplace pas un test de parcours.

Premier choix : que valide réellement le test ?

Un test qui cible directement un contrôle et déclenche son action répond à une question limitée : l’action se produit-elle lorsque le test la demande ? Il ne démontre pas que la commande est atteignable avec le clavier, que son focus est visible ou que le résultat est perceptible.

La démonstration rapporte que Playwright MCP peut cliquer les trois variantes testées et faire passer le compteur de zéro à un. Pourtant, deux variantes sont ignorées lors de la tabulation. Le point décisif est que browser_click cible une référence de l’instantané : il ne reproduit pas nécessairement le trajet d’une personne qui parcourt l’interface au clavier.

Le choix de contrôle dépend donc de la preuve recherchée :

• Si le besoin est de vérifier le résultat métier d’une action déjà atteinte, un test de clic peut convenir à cette vérification précise.
• Si le besoin est de vérifier l’accès clavier, le test doit envoyer Tab à la page et vérifier que le focus atteint le contrôle attendu.
• Si le test doit valider l’usage complet, il faut également vérifier l’activation au clavier, le retour de focus et le retour d’information associé à l’action.

Ces contrôles répondent à des questions différentes. Les réunir dans une même stratégie de recette évite de prendre la réussite d’un seul scénario pour une validation globale.

Si Tab ignore la commande, examinez d’abord son élément HTML

Dans les trois versions comparées, le même gestionnaire click incrémente le compteur. Deux commandes sont des div volontairement incomplètes ; l’une reçoit en plus role="button". Le rôle décrit une fonction, mais ne fournit pas à lui seul les interactions clavier correspondantes. Ajouter une apparence de bouton ou un rôle explicite ne répare donc pas automatiquement un parcours de tabulation absent.

Pour une action qui se comporte comme un bouton, l’élément HTML natif fournit les interactions clavier attendues. Dans l’exemple rapporté, le gestionnaire click reçoit aussi l’activation clavier native. Le type button évite par ailleurs une soumission involontaire si le contrôle se trouve dans un formulaire. Ce choix réduit le comportement à programmer, mais il ne dispense pas de tester le parcours réel de l’application.

Si un composant personnalisé est nécessaire, ne traitez pas tabindex="0" ou role="button" comme une solution complète. La démonstration montre que tabindex peut rendre un élément atteignable par Tab dans un essai, mais qu’il reste à programmer l’activation attendue. Le bon arbitrage est de comparer le coût de cette implémentation et de sa maintenance au besoin réel du composant.

Un score automatisé élevé ne tranche pas la question

Le score Lighthouse d’accessibilité agrège des audits automatisés. Dans les pages de la démonstration, une modification de la couleur de fond fait disparaître le signal de contraste observé et le score atteint 100/100, alors que les tests clavier échouent toujours sur deux variantes. Cela ne signifie pas que le score est inutile : il répond à son périmètre, qui n’est pas une validation complète de chaque interaction.

La même prudence s’applique aux audits expérimentaux destinés à la navigation par agent. Dans les rapports décrits, les audits applicables concernant l’arbre d’accessibilité et la stabilité de mise en page réussissent, mais leur périmètre ne couvre pas le parcours Tab observé. Un indicateur favorable ne peut donc pas remplacer un contrôle ciblé lorsque l’exigence porte sur l’accès clavier.

Pour un responsable qui reçoit une recette, la question à poser n’est pas seulement « Quel est le score ? », mais « Quel parcours a été exercé, et quelle preuve montre que le contrôle reçoit le focus ? ». La distinction entre ces preuves est également un enjeu de prise en compte de l’inclusion dans un projet numérique.

Une chronologie de vérification avant livraison

1. Décrire le parcours attendu. Pour l’écran concerné, préciser l’ordre des commandes au clavier, le contrôle qui doit recevoir le focus et le résultat attendu après activation. L’ordre de tabulation dépend du parcours de la page ; il ne faut pas recopier mécaniquement celui d’une démonstration.

2. Vérifier l’atteignabilité. Depuis le début du parcours prévu, envoyer Tab jusqu’à la commande et vérifier explicitement que le focus se trouve sur elle. Un test qui appelle directement click() sur la cible ne répond pas à cette question.

3. Vérifier l’activation et le retour. Tester Entrée et Espace lorsque le contrôle doit les prendre en charge. Vérifier aussi le retour avec Maj + Tab, l’indicateur visuel de focus et le retour d’information après l’action. Un compteur qui change ne suffit pas à établir que le résultat a été perçu.

4. Faire échouer la recette en cas de défaut. Une assertion de focus manquante ou un simple journal « non atteint » peut laisser une suite de tests verte. La recette doit échouer clairement lorsque le contrôle attendu n’est pas atteint.

5. Conserver une preuve lisible. Relier le scénario, le résultat attendu et l’assertion exécutée. Le décideur peut alors distinguer un contrôle d’activation d’un contrôle d’accessibilité clavier, au lieu de recevoir un résultat global difficile à interpréter.

Un exemple de recette pour éviter le faux positif

Scénario hypothétique : une PME fait évoluer une commande « Ajouter au panier ». Le test existant clique le contrôle et vérifie l’augmentation du compteur ; il passe. Après une demande de validation plus complète, l’équipe ajoute un scénario distinct : elle envoie Tab à la page, attend le focus sur la commande, puis vérifie l’activation au clavier et le résultat. Si Tab passe directement au contrôle suivant, la recette échoue, même si le clic automatisé continue de réussir.

Cette séparation évite deux erreurs de décision. La première consiste à déclarer l’interface accessible parce que l’action métier fonctionne. La seconde consiste à demander à un score automatisé une preuve qu’il ne fournit pas. Les contrôles doivent être liés à des critères d’acceptation explicites, puis présentés séparément dans les livrables de recette.

Les conclusions doivent toutefois rester proportionnées à leur preuve. L’article d’Alsacréations décrit une démonstration sur trois pages simples et des clics MCP pilotés par un script déterministe ; il précise qu’il ne s’agit pas d’une étude statistique ni d’un audit complet de conformité. Aucun essai autonome d’agent, ni essai avec VoiceOver ou NVDA, n’y est inclus.

Ces résultats illustrent un angle mort possible des tests ciblés, sans établir que tous les outils ou toutes les interfaces se comportent de la même façon.

La règle de décision reste utile au quotidien : si l’exigence concerne le clavier, la preuve doit montrer le trajet au clavier. Le clic, le score et la présence d’un rôle peuvent apporter d’autres informations ; aucun ne démontre à lui seul que la commande est atteignable et utilisable dans ce parcours.