Votre rapport d'audit signale un échec du 2.1.1 sur chaque élément. Comment savoir si c'est vrai.

Quelqu'un vous envoie un audit d'accessibilité. Sous 2.1.1 Clavier, chaque élément de la page porte le même verdict : aucune alternative à l'usage exclusif de la souris. Vous débranchez la souris, vous parcourez la page à la tabulation, et tout marche — le focus se déplace, l'anneau est visible, Entrée déclenche ce qu'il doit.

L'un de vous deux se trompe. Déterminer lequel n'est pas affaire d'opinion, et la réponse est plus intéressante que « le prestataire gonfle son rapport ».

D'abord, le 2.1.1 ne veut pas dire ce que le rapport suppose sans doute

Le critère dit :

Toutes les fonctionnalités du contenu sont utilisables à l'aide d'une interface clavier sans exiger de minutage particulier pour les frappes individuelles, sauf si la fonction sous-jacente nécessite une saisie qui dépend du tracé du mouvement de l'utilisateur et pas seulement des points de départ et d'arrivée.

Niveau A. Notez ce qui manque : toute mention d'une touche particulière.

Le document Understanding est explicite :

les boutons qui ont le focus peuvent généralement être activés à la fois par la touche Entrée et par la barre d'espace. Si un contrôle bouton personnalisé dans une application web ne réagit au contraire qu'à Entrée (ou même à une touche ou une combinaison entièrement personnalisée), cela satisfait quand même aux exigences de ce critère de succès.

Donc « Entrée n'a rien fait, donc 2.1.1 » n'est pas un constat. Pas davantage « ce contrôle attend une touche que je n'ai pas devinée ». La question que pose le 2.1.1 est de savoir si la fonction peut être accomplie au clavier — pas si elle peut l'être de la façon que vous attendiez.

Cela coupe dans les deux sens. Cela élimine une classe de faux positifs, mais cela signifie aussi qu'un contrôle peut satisfaire le 2.1.1 tout en étant inutilisable en pratique, parce que personne ne devine la touche. C'est un vrai problème, mais il relève d'autres critères et de la simple utilisabilité, pas de celui-ci.

Ensuite, trois choses classées sous 2.1.1 qui sont des critères distincts

Cela compte, car si le rapport range tout sous un seul numéro, c'est déjà un indice sur la façon dont il a été produit.

Rester coincé, c'est 2.1.2 Pas de piège au clavier (A). Vous entrez à la tabulation et vous ne ressortez pas. Autre critère.

Voir où l'on est, c'est 2.4.7 Visibilité du focus (AA). Cet anneau épais que vous avez observé prouve quelque chose sur le 2.4.7. Il ne prouve rien, ni pour ni contre, sur le 2.1.1 — une page peut avoir un indicateur de focus parfait sur chaque contrôle et échouer au 2.1.1, et elle peut satisfaire le 2.1.1 sans aucun focus visible.

Un focus masqué par un en-tête collant, c'est 2.4.11 Focus non masqué (minimum) (AA), nouveau dans WCAG 2.2. Ce n'est pas non plus du 2.1.1.

Si votre propre test s'est résumé à « j'ai tabulé, je voyais le focus et Entrée marchait », vous avez recueilli de bonnes preuves sur le 2.4.7 et des preuves seulement partielles sur le 2.1.1.

À quoi ressemble un vrai constat 2.1.1

Un échec à ce critère doit nommer une fonction qui ne peut pas être accomplie. Pas un élément qui existe. Un constat exploitable contient donc :

• l'élément, et ce que vous tentiez d'en faire
• les étapes de reproduction
• résultat attendu contre résultat obtenu
• navigateur, système d'exploitation, et quelle technologie d'assistance dans quelle version

Ce n'est pas une barre haute. C'est ce que la personne qui testait a noté pendant qu'elle testait, parce qu'il lui fallait cela pour savoir que ça échouait. Tout audit qui vaut son prix l'a déjà.

Si chaque élément porte un verdict identique, ce n'est pas un résultat, c'est un gabarit. Une liste de contrôle remplie une fois puis recopiée le long de la colonne ressemble exactement à cela. Un rapport où « non testé » a été exporté en « échec » aussi.

Revenez vers eux et demandez les étapes de reproduction sur deux ou trois points signalés. C'est une demande factuelle à laquelle on peut répondre ou non, et elle tranche le débat sans que personne ait à discuter la formulation d'un critère.

Mais n'en concluez pas que votre test a innocenté la page

C'est ici que ceux qui ont raison sur le rapport finissent souvent par avoir tort sur leur propre site.

Débrancher la souris et appuyer sur Tab est un vrai test, et il passe à côté de la plupart des défauts qui remontent réellement dans les audits :

• Le contenu qui n'apparaît qu'au survol. Votre pointeur a disparu, vous ne le voyez donc jamais, et les personnes au clavier non plus. (Voisin : 1.4.13 Contenu au survol ou au focus, AA.)
• Tout ce qui exige un glissement. Curseurs, listes réordonnables, déplacement de cartes. WCAG 2.2 a ajouté 2.5.7 Mouvements de glissement (AA) précisément parce que cela continuait d'arriver.
• Les widgets composites où Tab atteint le composant mais où les flèches à l'intérieur n'ont jamais été câblées. Une liste ou un jeu d'onglets personnalisés dans lesquels on entre et où l'on ne navigue pas.
• Les fenêtres modales qui s'ouvrent très bien et ne se ferment pas sans pointeur. C'est du 2.1.2, et c'est le défaut clavier grave le plus fréquent que je rencontre.
• Tout ce qui se trouve après un piège au clavier, que vous n'atteindrez jamais, et dont l'absence de vos notes ressemble à une réussite.

Pourquoi vous pouvez avoir raison tous les deux

Voici l'explication qui s'applique le plus souvent, et que presque personne ne vérifie : le clavier seul et le clavier avec un lecteur d'écran actif sont deux tests différents.

NVDA et JAWS en mode navigation interceptent les frappes avant que la page ne les reçoive. Un élément atteignable à la tabulation lecteur d'écran éteint peut être inatteignable en mode navigation, et parfois l'inverse. Une personne qui teste avec NVDA et une personne qui développe sans rien observent réellement des comportements différents sur la même page.

Donc si le prestataire a testé technologie d'assistance allumée et vous éteinte, aucun des deux ne ment et aucun des deux n'a le tableau complet. C'est aussi pourquoi la ligne d'environnement dans un constat n'est pas de la paperasse : sans elle, le constat ne peut être ni reproduit ni réfuté.

Quoi faire, dans l'ordre

1. Demandez les étapes de reproduction sur deux ou trois points signalés.
2. Essayez précisément ceux-là vous-même, NVDA actif, en mode navigation, sous Windows. Firefox ou Chrome, celui qu'ils ont nommé.
3. S'ils se reproduisent, vous avez appris quelque chose de vrai sur votre site.
4. S'ils ne se reproduisent pas et que le prestataire ne peut fournir aucune étape, vous avez de quoi rejeter la colonne — et de quoi demander ce qui, ailleurs dans le rapport, a été produit de la même manière.

Un scanner automatique, le mien compris, ne tranchera pas cela pour vous. L'utilisabilité au clavier n'est pas détectable de façon fiable par une machine : un outil peut signaler un tabindex positif, un élément masqué aux technologies d'assistance tout en restant focalisable, ou un contrôle sans nom accessible, et c'est utile. Savoir si une personne peut réellement finaliser votre commande sans souris reste une question qui demande une personne.

La réserve

Je décris comment évaluer un rapport, je ne vous dis pas que votre site est conforme. Si l'audit a raison, le fait qu'il soit mal rédigé ne le rend pas faux : il le rend mal rédigé. Demandez les étapes, puis prenez au sérieux ce qui revient.

Sources : Understanding SC 2.1.1 Keyboard · WebAIM: Keyboard Accessibility