EAA, RGAA, VPAT : ce que la conformité d’accessibilité exige réellement d’une équipe web

L’accessibilité numérique est passée en quelques années d’un sujet d’équipe design à une obligation contractuelle. Les appels d’offres la demandent, les directions juridiques la vérifient, et les équipes web découvrent trois sigles qu’on leur présente comme équivalents alors qu’ils ne le sont pas du tout.

Trois textes, trois natures

WCAG est une recommandation technique internationale. Elle définit des critères vérifiables, organisés en trois niveaux de conformité : A, AA, AAA. La version 2.2 est la référence courante. Ce n’est pas une loi : c’est le référentiel que les lois citent.

RGAA est le référentiel français. Il reprend les critères WCAG et ajoute ce qui manque à une recommandation pour être opposable : une méthode de test critère par critère, et un format de déclaration de conformité. C’est la différence qui compte : le RGAA dit comment vérifier, pas seulement quoi respecter.

EAA (European Accessibility Act) est une directive européenne. Elle ne se lit pas directement : elle s’applique par transposition dans chaque État membre, avec ses propres échéances, ses propres sanctions, et son propre périmètre d’exemptions. C’est le texte qui a fait entrer le sujet dans les contrats.

VPAT, enfin, n’est aucun des trois. C’est un document standardisé, d’origine américaine, dans lequel un éditeur déclare lui-même le niveau de conformité de son produit. Un VPAT n’est pas une certification : c’est une déclaration du fournisseur, avec la responsabilité que cela implique.

La confusion la plus coûteuse que nous voyons : croire qu’un VPAT rempli vaut conformité. Il vaut engagement de l’éditeur, ce qui est autre chose.

Ce qu’un contrôle automatique peut prouver

C’est la question que tout le monde pose et à laquelle peu de fournisseurs répondent franchement.

Un moteur de test automatique tranche, avec certitude, une part minoritaire des critères. Les autres exigent un jugement humain. La répartition tient à la nature des critères, pas à la qualité de l’outil.

Ce qui se décide sans humain :

• l’absence d’alternative textuelle sur une image ;
• un rapport de contraste insuffisant entre un texte et son fond ;
• un champ de formulaire sans étiquette associée ;
• une hiérarchie de titres incohérente ;
• un attribut de langue manquant ou faux ;
• des rôles ARIA invalides ou contradictoires.

Ce qui ne se décide pas sans humain :

• la pertinence d’une alternative textuelle : un outil voit qu’elle existe, pas qu’elle décrit l’image ;
• l’ordre de lecture logique quand il diffère de l’ordre du code ;
• la clarté d’un message d’erreur ;
• l’utilisabilité réelle au clavier sur un composant complexe ;
• la conformité des contenus vidéo et audio.

Un fournisseur qui annonce « conformité automatique » vend une impossibilité. Ce qu’un outil apporte, c’est de traiter la part mécanique à chaque livraison, sur toutes les pages, sans fatigue, et de laisser le temps humain aux critères qui l’exigent.

Le piège du rendu

Une erreur technique fréquente mérite d’être isolée : auditer le HTML initial plutôt que le rendu.

Sur une application moderne, le HTML servi par le serveur est souvent un conteneur vide. L’audit qui le lit trouve une page presque parfaite, parce qu’il n’y a presque rien à trouver. Les vraies erreurs apparaissent après exécution du JavaScript, dans le DOM final.

Le contrôle qui tire : comparez le nombre d’éléments interactifs vus par votre outil avec ce que vous voyez à l’écran. S’il en trouve trois sur une page qui en compte quarante, il lit le mauvais document.

Ce qu’il faut produire

Pour un appel d’offres ou une revue juridique, trois pièces :

1. Un relevé daté, critère par critère, avec la méthode de test employée.
2. Une déclaration de conformité au format attendu : RGAA en France, VPAT pour un acheteur américain.
3. Un plan de correction pour les non-conformités restantes, avec des échéances. Personne n’attend cent pour cent le premier jour ; on attend de savoir où vous en êtes et où vous allez.

Le point qui coûte du temps n’est jamais la production du document : c’est de retrouver, six mois plus tard, sur quelles pages et à quelle date le relevé a été fait. D’où la règle que nous appliquons à tous nos rapports : une donnée figée porte la configuration qui l’a produite. Sans cela, rien n’est comparable après un changement de périmètre, et la déclaration devient invérifiable, y compris par vous.

Par où commencer

Dans cet ordre :

1. Mesurez sur le rendu, pas sur le HTML initial, sur vos pages les plus vues.
2. Traitez d’abord le contraste et les étiquettes de formulaire. Ce sont les deux familles les plus fréquentes, les moins coûteuses à corriger, et celles qui bloquent le plus d’utilisateurs.
3. Faites une revue humaine des parcours critiques : inscription, paiement, recherche. Un site conforme sur ses pages statiques et inutilisable sur son tunnel n’est pas conforme.
4. Écrivez la déclaration, avec ses non-conformités assumées et leurs échéances.

C’est plus long que d’acheter un badge. C’est aussi la seule version qui tient devant une contestation.