Organisation des règles

Cette page décrit la structure des 145 règles du catalogue, ce qui aide à interpréter un résultat ou à trouver la règle que vous cherchez. Elle reflète ce qui existe déjà dans le jeu de règles, pas une conception abstraite.

Automatique ou manuelle

Le type de chaque règle prend l’une de deux valeurs, et la différence tient à ce que la règle est capable de trancher, pas au résultat qu’elle renvoie dans un cas donné :

• automatique : tranche de façon déterministe, sans heuristique ni supposition. Peut rapporter fail. cantTell apparaît quand même ici, dans les situations suivantes : une violation réelle existe mais n’établit pas à elle seule l’échec du critère WCAG associé (une exigence d’auteur ARIA dont le nom, le rôle ou la valeur exposés restent valables) ; la règle établit de façon déterministe qu’une bonne pratique n’est pas respectée, ne revendique aucun critère de succès, et ce qu’elle a trouvé ne gêne pas forcément qui que ce soit, puisque le rôle ou l’élément parvient tel quel aux technologies d’assistance (aria-allowed-role, landmark-role-name-present, marquées comme bonne pratique) ; ou la règle peut seulement confirmer qu’un mécanisme est présent, tandis que la validité de ce qui est présent relève d’une règle sœur (aria-required-children, associée à aria-prohibited-children) ; ou la règle ne peut pas trancher sans supposer, et pose donc la question au lieu d’échouer : un nom qui peut provenir d’une shadow root fermée, d’un ElementInternals que le moteur ne peut pas lire, ou d’un contenu imbriqué trop profondément pour être lu (les règles *-name-present), un texte qui peut être tronqué ou se chevaucher une fois espacé (text-spacing-content-loss), un bloc de media query d’orientation qui fait pivoter un autre élément que le contenu de la page (css-orientation-lock), un texte de placeholder sous son rapport dont on ne peut pas dire si les couleurs sont celles de la page ou du navigateur, ou un caractère isolé qui tient lieu de nom à son contrôle sous son rapport (contrast-minimum), ou une couleur ou une taille impossible à calculer (les règles de contraste, target-size-minimum). Une règle qui lève une exception est également signalée comme cantTell, par sécurité.
• manuelle : signale qu’une personne doit trancher ; la règle ne peut pas trancher si ce qu’elle a trouvé pose problème. Rapporte cantTell ou notApplicable, et pass seulement lorsque la réponse qui ne demande aucun jugement est celle qui a été trouvée ; jamais fail. landmark-unique ne peut pas trancher si deux landmarks qui partagent un nom posent problème (l’APG l’admet quand leur contenu est identique), c’est donc cantTell ; mais « tous les noms diffèrent » est un fait, c’est donc pass. Une règle qui demande à une personne de juger chaque cible qu’elle trouve, par exemple si l’alternative textuelle d’une image est exacte, ne rapporte jamais pass. Une règle manuelle qui ne pose la question que là où une heuristique trouve un indice, et n’en trouve aucun, rapporte notApplicable, pas pass : elle ne s’applique qu’à ce que son heuristique signale, et ne rien y trouver ne montre pas que tout va bien. image-redundant-alt cherche une alternative textuelle qui répète le texte voisin de l’image ; n’en trouver aucune ne dit rien de la justesse de l’alternative. form-control-label-quality, password-paste-enabled, scrollable-region-focusable et image-of-text font de même.

Une règle marquée comme bonne pratique ne revendique aucun critère de succès, et rapporte pourtant fail quand ce qu’elle établit est en soi un obstacle : un titre vide est annoncé comme un titre sans rien dedans (empty-heading, comme le rapporte la règle ACT du W3C correspondante). Son fail dit que l’attente propre à la règle n’est pas remplie, pas celle d’un critère : aucune agrégation WCAG n’en tient compte. Là où le constat ne gêne peut-être personne, elle rapporte cantTell à la place, comme ci-dessus.

Une règle manuelle qui rapporte cantTell ne correspond pas au même événement qu’une règle automatique qui rapporte cantTell, même si la valeur est identique : la règle automatique a tranché et vous dit ce qu’elle a trouvé ; la règle manuelle vous dit que la question ne peut pas du tout être tranchée à partir du balisage. Dans les deux cas, le cantTell d’une règle de core dit comment y répondre (howToCheck), et certains disent vers où pointent les indices de la page (lean, voir le schéma de sortie). Voir Résultats et rapports pour la référence complète sur les résultats, la sévérité et la confiance.

Structure des identifiants de règle

Un identifiant de règle suit généralement la forme <family>-<intent> : les éléments ou le mécanisme ciblés par la règle, puis la question qu’elle pose à leur sujet. La famille des alternatives aux images (WCAG 1.1.1) en est l’exemple le plus clair :

• present : vérifie qu’un mécanisme requis existe. Généralement automatique.
• quality : vérifie la pertinence, l’exactitude ou le sens. Toujours manuelle.
• decorative : vérifie le traitement correct d’un contenu purement décoratif. Toujours manuelle.

L’intention détermine si une règle peut être automatique : « quelque chose est-il présent ? » peut souvent se trancher à partir du seul balisage, alors que « est-ce pertinent ? » ne le peut presque jamais. C’est aussi la logique des liens Règles associées sur chaque page de règle : les règles qui partagent une famille (tout ce qui précède le dernier segment - de l’identifiant) y sont regroupées. Le jeu de règles couvre des dizaines de familles au-delà de img (aria-*, contrast-*, dialog-*, iframe-*, label-*, link-*, list-*, landmark-* et d’autres) ; le catalogue en est la liste actuelle, générée automatiquement.

Les règles ne mélangent jamais les familles : chacune interroge un seul type d’élément, avec les helpers adaptés. C’est aussi pourquoi le jeu compte 145 règles ciblées plutôt qu’une douzaine de règles larges : deux vérifications qui diffèrent par ce qu’elles tranchent, ce qu’elles ciblent ou la facette WCAG qu’elles couvrent restent des règles distinctes au lieu d’être fusionnées, pour qu’un résultat n’ait jamais à être démêlé après coup pour savoir ce qui a été trouvé précisément.

Facettes WCAG

Un critère de succès WCAG est généralement plus large que ce qu’une seule règle peut trancher de façon déterministe. En interne, chaque critère est découpé en « facettes » nommées : pour le 1.1.1 Contenu non textuel, il s’agit par exemple de savoir si un attribut alt est présent, si son texte a du sens, et si les images décoratives sont correctement marquées par un attribut alt vide. Une règle correspond à une ou plusieurs facettes, et plusieurs règles couvrent souvent différentes facettes du même critère, ce que fait exactement la famille img-alt ci-dessus pour le 1.1.1.

C’est important pour lire un résultat composite (agrégation par critère de succès WCAG) : un composite ne réussit que si ses règles vérifient tout ce que demande le critère, et aucun ne le fait encore. Là où chaque vérification automatisée d’un critère revient sans erreur, le composite est donc ?can't tell, vérifié en partie : les facettes que couvrent ses règles sont respectées, et une personne vérifie le reste. Voir Conformité pour les trois couches (règles atomiques, facettes, composites) et la façon dont le résultat d’un composite est réellement calculé.