Une commande « Ajouter au panier » peut être cliquée par un outil d’automatisation sans être accessible au clavier. C’est ce que montre une expérience menée avec Playwright MCP et Lighthouse, qui compare trois versions d’un même bouton. Le score Lighthouse d’accessibilité peut même atteindre 100/100 alors que la barrière clavier subsiste.
Les trois pages ne diffèrent que par cette commande : une div cliquable, une div à laquelle on ajoute role=«button», et un bouton HTML natif. Les trois clics transmis par MCP ajoutent bien un article. Au clavier, en revanche, la touche Tab ignore deux des trois commandes. Sur les variantes A et B, le parcours passe directement du lien « Voir le produit » au bouton de remise à zéro. Seul le bouton natif reçoit l’ajout, avec Entrée comme avec Espace.
Sur Mac, les réglages de macOS et l’option de Safari permettant de parcourir chaque élément avec Tab peuvent modifier les arrêts. Apple détaille ces réglages dans son guide Safari. Les mesures ont été réalisées avec Chrome.
Ce que transmet Playwright MCP
Playwright MCP expose des outils de navigateur à un agent. L’outil browser_snapshot décrit la page, et browser_click agit sur un élément désigné par une référence de cette description. Pour la variante B, le div avec rôle apparaît comme un bouton, au même titre que le bouton natif, alors que la variante A est décrite comme un élément générique. Dans les trois cas, la référence e14 permet de faire passer le compteur de 0 à 1.
Le style commun ajoute aussi une annotation de curseur, [cursor=pointer]. Lorsqu’on la supprime dans une copie, les références et les clics fonctionnent toujours. Selon la source, cette annotation n’ajoute aucun arrêt de tabulation. Un agent disposant de MCP peut donc cliquer une commande absente du parcours clavier, mais les essais ne mesurent pas la décision d’un agent autonome.
Lighthouse : des scores élevés, la même barrière
Lighthouse obtient d’abord 95/100 pour A, 96/100 pour B et 95/100 pour C. Dans les fichiers d’origine, l’outil signale le contraste du mot « NOTES » dessiné sur le carnet. Une seconde copie modifie uniquement la couleur de fond du carnet, de #687b40 à #647640 : les trois variantes atteignent alors 100/100. Pourtant, après ce changement, les tests clavier échouent toujours sur A et B.
Selon la source, B dépasse C parce que le rôle explicite rend quatre audits ARIA supplémentaires applicables et réussis, ce qui réduit le poids de l’échec de contraste dans la moyenne. Google indique que le score agrège des audits automatisés, tandis que la vérification de la prise de focus des contrôles interactifs relève des contrôles manuels.
Le test écrit avec @playwright/test envoie les touches à la page, puis exige que le bouton reçoive le focus. Sur la variante C, les deux tests, avec Entrée et avec Espace, réussissent. Avec les variantes A et B, l’assertion de focus échoue, ou le bouton recherché par rôle est absent, et le processus se termine avec un code d’erreur.
Ce qu’apporte le bouton HTML
L’ARIA Authoring Practices Guide rappelle qu’un rôle décrit une fonction sans fournir les interactions clavier correspondantes. Le bouton natif les apporte. Dans le cas de l’ajout au panier, il suffit de programmer le gestionnaire click, l’activation clavier étant déjà fournie, et l’attribut type=«button» évite une soumission involontaire dans un formulaire.
Les mesures ont été réalisées le 8 octobre 2026 sur macOS arm64, avec Chrome 155.0.8059.39, Playwright 1.63.0, MCP 0.0.68 et Lighthouse 13.5.0, puis complétées avec Playwright 1.64.0 et MCP 0.0.83. Il s’agit de trois pages volontairement simples, sans étude statistique, sans essai de lecteur d’écran et sans essai d’agent autonome. Les résultats ne constituent pas un audit de conformité complet.
