RGAA : les erreurs qui reviennent sur 9 audits sur 10

Après plusieurs audits RGAA, un constat s'impose : les mêmes erreurs reviennent, presque indépendamment du contexte. Les projets diffèrent - secteurs, technologies, tailles d'équipe - mais les non-conformités se ressemblent. Ce n'est pas un hasard, et ce n'est pas un problème de compétence des équipes. C'est un problème de process : ces erreurs ne sont visibles que si on teste activement. Et la recette, la plupart du temps, ne teste pas.

Les classiques

Cinq catégories d'erreurs concentrent la majorité des non-conformités que je retrouve d'un audit à l'autre.

Contrastes et couleurs

Les contrastes insuffisants sur les textes secondaires, les états désactivés et les placeholders de formulaire sont les erreurs les plus fréquentes - et les moins détectées, parce que les designers testent le contraste sur les textes principaux, pas sur tous les états de l'interface. Le critère RGAA 3.2 exige un ratio de 4,5:1 pour le texte normal et 3:1 pour le texte large (au-dessus de 18px en gras ou 24px en normal). Les boutons désactivés (opacity: 0.4 sur un texte clair) passent souvent sous cette limite sans que personne ne le vérifie.

Labels et formulaires

Un champ de formulaire sans label explicite ou avec un label uniquement visuel (placeholder utilisé comme seul indicateur) est une erreur critique au sens du RGAA. C'est le critère 11.1 - et c'est systématiquement en échec sur les formulaires de contact construits rapidement ou les formulaires de recherche en ligne. L'erreur est simple à corriger (balise label associée par attribut for/id, ou aria-label), mais elle demande d'être testée avec un lecteur d'écran pour être détectée - ce qui arrive rarement en phase de recette standard.

Alternatives textuelles sur images

Les images décoratives sans alt vide, les images porteuses d'information avec un alt absent ou non descriptif, les graphiques sans description de leur contenu - critère RGAA 1.1. Ce qui complique la détection : les CMS laissent souvent le champ alt vide par défaut, et les contributeurs ne savent pas toujours qu'il faut le remplir, ni comment. La correction demande à la fois de la technique (vérification du rendu HTML) et de la formation des équipes éditoriales.

Focus clavier et navigation sans souris

Le focus clavier invisible (outline: none appliqué globalement dans le CSS) est une erreur massive - critère RGAA 10.7. Elle est souvent introduite par un développeur front-end qui trouve le focus clavier « moche » et l'enlève globalement sans mesurer l'impact sur les utilisateurs de clavier. Ce type de modification touche l'intégralité de l'interface et rend la navigation sans souris impossible ou très difficile pour les utilisateurs qui en dépendent.

• Contrastes de couleur insuffisants sur les textes secondaires et les états désactivés
• Champs de formulaire sans label explicite ou avec un label uniquement visuel
• Images porteuses de sens sans alternative textuelle pertinente
• Focus clavier invisible ou incohérent dans l'ordre de navigation
• Contenus dynamiques (modales, notifications) non annoncés aux lecteurs d'écran

Pourquoi elles persistent

Ce ne sont pas des erreurs de compétence, mais des erreurs de priorité : ces points ne sont visibles que si on teste activement avec les bons outils. Et la recette classique ne le fait pas.

Pas un problème de compétence

Les développeurs qui introduisent ces erreurs savent souvent ce qu'est l'accessibilité. Ce qu'ils ne font pas, c'est tester leur code avec un lecteur d'écran, naviguer leur interface au clavier, ou vérifier les contrastes avec un outil dédié.

Ce n'est pas de la mauvaise volonté - c'est l'absence de cette vérification dans leur workflow quotidien. La formation sensibilise, mais elle ne change pas les comportements si le process de recette ne l'impose pas.

Un problème de process de recette

La recette fonctionnelle teste ce qui est visible dans un navigateur standard, avec une souris. Elle ne teste pas la navigation clavier, la lecture par un lecteur d'écran, les contrastes en dehors des cas nominaux. Intégrer ces tests dans la recette - même de façon minimaliste - change complètement l'équation. Ce n'est pas une refonte du process, c'est l'ajout d'une checklist sur les composants critiques.

La correction la moins coûteuse

Intégrer un test clavier et lecteur d'écran basique sur les composants critiques dès la phase de recette, plutôt que d'attendre l'audit. Le coût de correction d'une non-conformité découverte en recette est 5 à 10 fois inférieur au coût de correction après mise en production.

La checklist minimaliste à intégrer en recette

Pour chaque composant critique (formulaires, navigation principale, modales, messages d'alerte), vérifier : navigabilité au clavier (Tab/Shift+Tab, Entrée, Échap), visibilité du focus, présence et pertinence des alternatives textuelles, ratio de contraste sur tous les états, annonce correcte des changements dynamiques par NVDA ou VoiceOver. Ce test prend 20 à 30 minutes par composant. Il détecte 80% des erreurs RGAA récurrentes avant qu'elles n'atteignent la production.

Ces erreurs ne sont pas une fatalité technique, elles sont un angle mort de process. Combler l'angle mort coûte beaucoup moins cher que de corriger les erreurs après audit. La question n'est pas de savoir si votre interface est accessible - c'est de savoir à quel moment du cycle de développement vous choisissez de le vérifier.

C'est exactement ce que je vérifie lors d'un audit RGAA : ces erreurs récurrentes, et le point du cycle de développement où les corriger coûte le moins cher.

---

Pour aller plus loin : l'accessibilité n'est pas une checklist, c'est une architecture · ce que le RGAA doit à l'accessibilité, et ce qu'il ne couvre pas