Une exception d’accessibilité qui se mesure

Pointez un vérificateur d’accessibilité automatique sur un produit réel et vous obtenez un nombre. Corrigez tout ce qu’il a trouvé et vous obtenez un nombre plus petit. Quelque part dans ce processus, vous tomberez sur une anomalie qui n’est véritablement pas un défaut, et à cet instant vous écrivez votre première exception.

C’est la partie intéressante, parce qu’une liste d’exceptions est l’endroit où un programme d’accessibilité meurt discrètement. Elle commence avec deux entrées bien argumentées. Un an plus tard, elle en compte onze, dont trois ne correspondent plus à rien, dont une cache un vrai problème, et plus personne ne se rappelle pourquoi l’une ou l’autre est là. Le rapport dit zéro et ne veut rien dire.

Nous avons construit le vérificateur de notre panneau ce mois-ci. Il ne rapporte aucune anomalie, à aucun niveau de gravité, et cet article parle surtout de la raison pour laquelle nous ne croyons pas ce nombre pris isolément.

Trois règles étaient désactivées par défaut, et deux d’entre elles cachaient des anomalies

La bibliothèque que nous utilisons livre certaines règles désactivées par défaut. Nous avons vérifié lesquelles, en le lui demandant plutôt qu’en le supposant : la discordance entre le nom et le contenu, les cellules de tableau sans en-tête et la taille de cible sont toutes trois désactivées d’origine.

Deux d’entre elles ont produit de vraies anomalies sur notre panneau, 36 à elles deux, dont les deux points qu’une manche antérieure avait laissés ouverts. Un vérificateur qui tourne avec le jeu de règles par défaut est donc vert sur exactement les défaillances que quelqu’un était déjà allé chercher, ce qui est le pire genre de vert : il est indiscernable d’un produit qui va bien.

Elles sont activées explicitement, et cette seule décision a changé la référence de départ plus que n’importe quel autre choix de configuration.

Neuf langues, parce qu’une seule langue est un tirage à pile ou face

Le sélecteur de langue de notre en-tête affiche un code à deux lettres et porte un nom accessible qui dit de quelle langue il s’agit. En anglais, le bouton affiche EN et s’appelle « Language: English », et la règle passe, parce que en se trouve justement apparaître à l’intérieur de English.

En néerlandais, elle échoue. Même composant, même code, même balisage.

Mesuré sur l’ensemble des neuf langues que nous livrons : trois échouent et six passent, et chacune de ces six passe par coïncidence : en dans English, de dans Deutsch, fr dans Français, it dans Italiano, es dans Español, ro dans Română. Tester une seule langue ici est vert par vacuité.

Le parcours marketing exécute donc chaque langue sur les règles dont le résultat peut dépendre de la langue. Cela coûte du temps et c’est la seule manière dont cette anomalie existe.

La référence de départ, et de quoi elle était faite

La première exécution complète sur le marketing, la connexion et le panneau connecté a rapporté 3 anomalies critiques, 51 sérieuses, 72 modérées et 6 mineures. Huit règles en rendaient compte en totalité.

Presque tout était structurel plutôt que visuel. Les pages de connexion et le panneau n’avaient pas d’élément main et pas de lien d’évitement. Les tableaux des articles avaient des en-têtes vides. Les blocs de code défilent horizontalement et ne pouvaient pas être atteints au clavier, ce qui veut dire qu’un utilisateur au clavier ne peut tout simplement pas lire le côté droit d’une commande longue. L’onglet des statistiques plaçait un titre de graphique au mauvais niveau sous le titre de la page.

Après les réparations : zéro, zéro, zéro, zéro. Ce qui nous ramène à la question de savoir ce que vaut ce zéro.

Deux exceptions, chacune avec une mesure

La liste d’exceptions compte exactement deux entrées, et chacune d’elles porte une raison et une mesure qui a réellement été prise.

Le contraste des couleurs sous couleurs forcées. Faire tourner le panneau avec les couleurs forcées actives a produit 610 échecs de contraste sur douze pages. Ce n’est pas un défaut du produit, c’est une interaction entre le vérificateur et le navigateur. Le vérificateur lit -webkit-text-fill-color avant color, et Chrome ne force pas la première. Sur la page de connexion, sur le même titre, dans le même chargement de page :

Il compare donc le premier plan tel qu’il a été écrit à l’arrière-plan forcé et rapporte 1,12 contre 1 là où l’écran affiche en réalité 21 contre 1. Dans ce mode, l’exigence de contraste ne s’applique de toute façon pas, parce que la palette appartient à l’utilisateur.

La règle est désactivée dans ce seul mode, et la raison est remesurée à chaque exécution. Si Chrome ou le vérificateur corrige cela, cette autovérification échoue et l’exception doit être défendue de nouveau. Une exception sans autovérification est une liste d’autorisation silencieuse.

Le bouton de compte. La règle de discordance entre le nom et le contenu se déclenche sur le bouton du menu utilisateur dans le panneau. Six noms accessibles candidats ont été posés sur le bouton réel et la règle a été exécutée contre chacun d’eux. Elle ne passe que lorsque le nom contient littéralement la chaîne DKDemo Klant€0.00, dans laquelle les initiales et le nom du compte ont été collés l’un à l’autre, et elle échoue avec ce même texte espacé en DK Demo Klant €0.00, ainsi qu’avec le nom réel. Les trois enfants de ce bouton sont masqués aux technologies d’assistance, ce que la règle ignore.

Passer voudrait donc dire qu’un lecteur d’écran annonce DKDemo comme un seul mot. C’est un bouton moins bon, adopté pour satisfaire une règle que la bibliothèque elle-même marque comme expérimentale et livre désactivée. L’exigence fonctionnelle est remplie : quelqu’un qui utilise la commande vocale dit « Demo Klant », et cela figure bien dans le nom.

L’exception qui est morte sans rien dire

C’est la partie qui vaut tout l’article.

Une exception doit reconnaître l’élément auquel elle s’applique. Le sélecteur CSS du vérificateur lui-même n’est pas assez stable pour cela : le même bouton de compte était identifié d’une façon sur une page et d’une autre façon sur la suivante, si bien qu’une exception qui s’appuie sur le sélecteur couvre une page et pas l’autre. L’exception s’appuie donc plutôt sur un attribut marqueur que le composant pose lui-même, dans le fragment HTML de l’élément.

Le fragment que rapporte le vérificateur est tronqué à 140 caractères.

Le libellé accessible du bouton s’est allongé, parce que le crédit du compte y a été ajouté. Le marqueur a glissé au-delà de la limite des 140 caractères. Le fragment se terminait désormais par ... Credit €0.00." data-us. L’exception ne correspondait plus à rien, en silence, et l’exécution a rapporté 27 anomalies sérieuses qu’elle avait couvertes lors de l’exécution précédente.

Rien dans cette défaillance n’est bruyant. L’exception n’a pas levé d’erreur, la liste n’a pas rétréci, aucune configuration n’a changé. Un changement d’interface dans une fonctionnalité sans rapport a déplacé une chaîne, et un élément d’infrastructure de sûreté a cessé de fonctionner. Le correctif consiste à s’appuyer sur la balise ouvrante non tronquée, que le vérificateur fournit également.

La leçon générale dépasse l’accessibilité : tout ce qui s’appuie sur du texte tronqué est un garde-fou qui lâche précisément au moment où quelque chose change, c’est-à-dire au seul moment où on en avait besoin.

Une exception qui ne correspond à rien fait échouer l’exécution

Chaque entrée est comptée. Si une exécution complète se termine avec une exception qui a été touchée zéro fois, l’exécution est rouge.

C’est la même forme qu’une liste de constantes ailleurs dans ce code, et pour la même raison : une exception qui ne couvre plus rien devrait être supprimée, pas laissée en place. Laissée en place, c’est une ligne de plus sur laquelle la personne suivante doit raisonner, et pour finir elle n’est plus lue du tout.

Le comptage ne vaut que pour une exécution complète. Restreignez l’exécution à un seul parcours ou à un seul mode et « non touchée » ne veut rien dire.

Prouver qu’un zéro est un vrai zéro

La taille de cible, l’exigence qu’un contrôle mesure au moins 24 par 24 pixels, est l’une des trois règles que la bibliothèque livre désactivées. Nous l’avons activée et nous avons écrit à côté une seconde mesure à nous, parce que les deux exceptions que la norme elle-même accorde doivent être mesurées plutôt que supposées. L’exécution finale a examiné 2056 cibles. 155 étaient en dessous de la taille. 70 d’entre elles relevaient de l’exception « en ligne » de la norme, c’est-à-dire que la cible se trouve à l’intérieur d’une phrase, et 85 de l’exception d’espacement, c’est-à-dire qu’un cercle de 24 pixels autour d’elle ne touche rien d’autre. Il n’en restait aucune.

Un zéro venu d’une sonde que vous avez écrite vous-même ne se distingue pas d’une sonde incapable de rapporter quoi que ce soit. Un script séparé injecte donc un bouton de 16 par 16 pixels à côté d’un voisin sur une page en fonctionnement et exécute ce même texte de sonde, lu depuis le fichier source plutôt que copié, par-dessus. Il passe de 0 à 1 et nomme l’élément. Le chemin de restitution fonctionne : le zéro est donc un résultat et non un silence.

Les deux exceptions de la norme sont mesurées plutôt que devinées. « En ligne » veut dire que la valeur calculée de l’affichage est exactement inline et que le plus proche ancêtre de type bloc contient aussi d’autre texte, ce qui est ce que « se trouve dans une phrase » signifie réellement. Ce n’est pas une liste de noms de classes. Et le test d’espacement mesure le cercle contre les rectangles des autres cibles plutôt que contre leurs cercles, ce qui est plus strict que la norme : il peut produire un faux rouge, jamais un faux vert.

Ce qu’une machine ne peut pas faire

Il existe un court guide de quatre contrôles qui exigent une personne, parce que ce sont les choses qu’aucun vérificateur n’atteint : savoir si l’ordre de lecture a du sens et si une annonce arrive vraiment, si un parcours est faisable avec le seul clavier plutôt que simplement atteignable, si la mise en page reste lisible à 200 % plutôt que simplement contenue, et si l’écran veut encore dire quelque chose dans la palette propre à l’utilisateur.

Ces quatre-là sont ouverts. Le dire fait partie du propos : un rapport qui dit zéro sans dire ce qu’il n’a pas regardé est la même défaillance qu’une exception sans mesure.

Ce que nous retiendrions

1. 01Demandez à la bibliothèque quelles règles sont désactivées, ne le supposez pas. Ce sont les règles désactivées qui portaient nos anomalies.
2. 02Exécutez toutes les langues que vous livrez sur toute règle dont le résultat peut dépendre du texte.
3. 03Donnez à chaque exception une raison et une mesure, écrites là où vit l’exception.
4. 04Faites qu’une exception qui ne correspond à rien fasse échouer l’exécution.
5. 05N’appuyez jamais un garde-fou sur du texte tronqué.
6. 06Prouvez vos zéros en injectant quelque chose qui devrait être attrapé.
7. 07Publiez ce qu’une machine ne peut pas vérifier, pour que le nombre soit lu pour ce qu’il est.

Le même réflexe, appliqué aux traductions plutôt qu’au balisage, est dans seize mille clés, neuf langues.

Issu du travail sur le panneau de Provibr.