Aller au contenu
Se connecter

La vérification automatique AyScore RGAA

AyScore, by Green iScore, part d’axe-core, puis ajoute ce qu’il ne fait pas, et range chaque résultat dans un critère du RGAA 4.1. Le résultat est un indicateur de suivi, pas un verdict de conformité. Cette page dit exactement ce qui est vérifié ; les chiffres sont lus dans le code à chaque affichage.

En chiffres

Critères du RGAA 4.1
106
Critères avec au moins un test automatisé
59
dont par les règles d’axe-core taguées RGAA
34
dont par des règles écrites par le projet
25
Critères entièrement manuels
47
Règles Lint RGAA dans l’éditeur
5

« Au moins un test automatisé » : un critère du RGAA se décompose en plusieurs tests ; un critère couvert peut avoir des tests qui restent manuels, et aucun critère n’est validé sans revue humaine. Les règles d’axe-core taguées RGAA sont celles que son éditeur rattache lui-même à un test du RGAA ; les règles du projet sont documentées une par une, avec leur spécification, avant d’entrer dans le moteur.

Dans l’éditeur : Lint RGAA

Les plugins IntelliJ et VS Code analysent le code avant la mise en ligne, sur 5 critères (1.1, 6.1, 8.3, 9.1 et 11.1), en JSX/TSX, HTML, Vue, Svelte et gabarits Angular. Chaque signalement donne le critère, le lien vers le référentiel officiel et la recommandation. Le contenu des fichiers analysés est envoyé au serveur Green iScore que vous configurez.

Le jugement par IA, en attente de validation

Pour la pertinence des textes alternatifs, un modèle d’IA peut donner un avis à partir du texte seul, sans voir l’image. Cet avis est toujours présenté « en attente de validation » : il n’entre pas dans le score tant qu’un humain ne l’a pas tranché. Aucune mesure de sa fiabilité n’a encore été faite ; il est activé en option, en ligne de commande.

Le score de A à F

Chaque critère testé pèse selon la gravité que Green iScore lui attribue : bloquant 5, majeur 2, mineur 1 (la grille officielle ne définit aucune gravité ; c’est une classification du projet). Le score est le poids des critères conformes divisé par le poids des critères testés, de 0 à 100. La lettre : A à partir de 90, B de 75, C de 60, D de 40, E de 20, F en dessous. Un critère bloquant non conforme plafonne la lettre à C ; trois ou plus la ramènent à F. Le score est « provisoire » tant que des critères restent à valider.

  • Il indique l’évolution d’un site sur les points que l’outil sait vérifier.
  • Il n’est pas un taux de conformité RGAA et ne dit pas qu’un site est accessible.
  • Le badge public affiche la lettre, la date, le nombre de critères couverts et la mention « score automatique partiel ». Il n’affiche jamais « conforme RGAA ».

Les 106 critères, thématique par thématique

Pour chaque critère : ce qui le vérifie lors de l’audit du site, et s’il est aussi signalé dans l’éditeur par Lint RGAA. Un critère « allumé » a au moins un test automatisé ; un critère en pointillés reste à la revue humaine. L’intitulé renvoie au texte officiel du critère.

10. Présentation

10 critères sur 14 ont au moins un test automatisé ; 4 restent à l’humain.

  1. 10.1Dans le site web, des feuilles de styles sont-elles utilisées pour contrôler la présentation de l’information ?règle AyScore
  2. 10.2Dans chaque page web, le contenu visible porteur d’information reste-t-il présent lorsque les feuilles de styles sont désactivées ?Revue humaine
  3. 10.3Dans chaque page web, l’information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ?Revue humaine
  4. 10.4Dans chaque page web, le texte reste-t-il lisible lorsque la taille des caractères est augmentée jusqu’à 200 %, au moins (hors cas particuliers) ?axe-core
  5. 10.5Dans chaque page web, les déclarations CSS de couleurs de fond d’élément et de police sont-elles correctement utilisées ?règle AyScore
  6. 10.6Dans chaque page web, chaque lien dont la nature n’est pas évidente est-il visible par rapport au texte environnant ?axe-core
  7. 10.7Dans chaque page web, pour chaque élément recevant le focus, la prise de focus est-elle visible ?règle AyScore
  8. 10.8Pour chaque page web, les contenus cachés ont-ils vocation à être ignorés par les technologies d’assistance ?axe-core
  9. 10.9Dans chaque page web, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?Revue humaine
  10. 10.10Dans chaque page web, l’information ne doit pas être donnée par la forme, taille ou position uniquement. Cette règle est-elle implémentée de façon pertinente ?Revue humaine
  11. 10.11Pour chaque page web, les contenus peuvent-ils être présentés sans perte d’information ou de fonctionnalité et sans avoir recours soit à un défilement vertical pour une fenêtre ayant une hauteur de 256 px, soit à un défilement horizontal pour une fenêtre ayant une largeur de 320 px (hors cas particuliers) ?règle AyScore
  12. 10.12Dans chaque page web, les propriétés d’espacement du texte peuvent-elles être redéfinies par l’utilisateur sans perte de contenu ou de fonctionnalité (hors cas particuliers) ?axe-core
  13. 10.13Dans chaque page web, les contenus additionnels apparaissant à la prise de focus ou au survol d’un composant d’interface sont-ils contrôlables par l’utilisateur (hors cas particuliers) ?règle AyScore
  14. 10.14Dans chaque page web, les contenus additionnels apparaissant via les styles CSS uniquement peuvent-ils être rendus visibles au clavier et par tout dispositif de pointage ?règle AyScore

Les limites assumées

  • Les critères qui demandent un jugement (pertinence d’un texte, cohérence d’un parcours, compréhension d’un contenu) restent manuels.
  • L’audit analyse un échantillon de pages découvertes depuis l’adresse déclarée ; il n’analyse pas les images elles-mêmes.
  • Les menus et accordéons sont ouverts selon les motifs courants ; les feuilles de style servies depuis un autre domaine ne sont pas lues.
  • Le moteur ne lit pas les adresses internes d’un réseau (protection contre l’usage détourné), sauf sur une instance locale configurée pour cela.