Un audit RGAA fiable combine 106 critères et tests manuels

Un audit d’accessibilité numérique évalue la capacité réelle d’un site web ou d’une application à être utilisé par tous, notamment avec un clavier, un lecteur d’écran ou une autre technologie d’assistance. En France, il s’appuie sur le RGAA, un référentiel fondé sur les WCAG. L’objectif ne consiste pas uniquement à obtenir un taux de conformité. Il faut repérer les obstacles concrets, les corriger dans le bon ordre et formaliser un niveau d’accessibilité vérifiable.

Ce que vérifie un audit RGAA, et ce qu’il ne promet pas

Le Référentiel général d’amélioration de l’accessibilité fournit des critères de contrôle et des procédures de test pour évaluer un service numérique. Un audit de conformité complet couvre les 106 critères du RGAA sur un échantillon de pages représentatif. Chaque résultat est qualifié selon les conditions applicables : conforme, non conforme, non applicable ou, dans certains cas, concerné par une dérogation justifiée.

Quiz sur l’audit d’accessibilité numérique

Testez vos connaissances sur le RGAA, les méthodes d’évaluation et la restitution d’un audit.

0/6 question répondue Score : — / 6
1. Quel est le rôle principal du RGAA dans un audit d’accessibilité ?
2. Quelle est une limite importante des outils automatisés ?
3. Que doit couvrir en priorité un échantillon représentatif ?
4. Que permettent notamment les tests au clavier ?
5. Pourquoi compléter l’évaluation avec un lecteur d’écran ?
6. Que doit notamment contenir un rapport d’audit ?

Le RGAA traduit les principes des WCAG en méthode opérationnelle. Il permet notamment de vérifier les alternatives textuelles des images, la lisibilité des contenus, les contrastes, la structure des titres, les formulaires, les médias, les tableaux et les interactions dynamiques. Pour l’administration, l’objectif affiché est d’atteindre 100 % de conformité. Dans la pratique, l’audit sert surtout à établir un diagnostic traçable et à organiser une amélioration continue.

La conformité ne se déduit pas d’un score automatique

Les outils automatiques détectent certains défauts de code, par exemple une image sans alternative ou un champ de formulaire sans étiquette. Ils ne peuvent pas déterminer si l’alternative décrit réellement l’image, si l’ordre de lecture est pertinent, si un lien reste compréhensible hors contexte ou si une fenêtre modale est utilisable au clavier. Un scan est donc un indicateur utile, mais il ne remplace pas un audit.

L’outil Ara accompagne la démarche et la documentation des résultats, sans effectuer automatiquement l’ensemble des contrôles. Son utilisation suppose de connaître les critères RGAA et leurs procédures techniques. L’interprétation humaine reste indispensable, notamment pour les composants JavaScript et les contenus éditoriaux.

Choisir le bon niveau d’audit avant de lancer les tests

Le périmètre doit répondre à une décision précise : obtenir une première vision des risques, préparer une refonte, produire une déclaration d’accessibilité ou vérifier un service après correction. Confondre ces objectifs peut conduire à un échantillon trop réduit ou à un rapport difficile à exploiter.

Les trois phases d’un audit accessibilité numérique selon le RGAA
Les trois phases d’un audit accessibilité numérique selon le RGAA
Type d’évaluation Périmètre Utilité principale Limite à connaître
Analyse automatisée Détection de règles techniquement vérifiables Repérer rapidement des erreurs répétées Ne valide ni l’usage réel ni la conformité globale
Audit essentiel 25 critères essentiels associés au niveau A des WCAG Faire émerger les blocages les plus fréquents Ne suffit pas pour conclure à la conformité
Audit partiel Critères et pages ciblés selon un besoin défini Sécuriser une fonctionnalité, une refonte ou un parcours Ses conclusions restent limitées au périmètre audité
Audit complet de conformité 106 critères RGAA sur un échantillon représentatif Établir un état de conformité et une déclaration Demande une méthode rigoureuse et des tests manuels

Un audit initial est souvent le bon point de départ lorsqu’une organisation ne connaît pas son niveau d’accessibilité. Il donne une vision commune aux décideurs et aux équipes produit, design, contenu et développement. Un audit complet devient pertinent lorsque le résultat doit soutenir une déclaration d’accessibilité ou une démarche réglementaire.

Conduire l’audit en 3 phases, de l’échantillon à la restitution

1. Cadrer et sélectionner des pages représentatives du service

La préparation consiste à délimiter le site ou l’application, à recenser les technologies employées, à identifier les contenus tiers et à choisir les pages à auditer. L’échantillon doit réunir les pages obligatoires, mais aussi les pages stratégiques : accueil, recherche, contact, authentification, formulaire, tunnel d’achat ou de démarche, espace connecté, pages de résultat et contenus riches.

Il faut sélectionner des gabarits différents et des états d’interface variés : erreur de saisie, confirmation, menu ouvert, filtre appliqué, accordéon déployé ou dialogue affiché. Auditer cinq pages presque identiques peut donner un résultat rassurant, mais peu représentatif. À l’inverse, une page complexe peut révéler des défauts présents dans toute une bibliothèque de composants.

2. Tester les parcours, pas uniquement le code

Les contrôles combinent inspection HTML, vérification des styles, tests JavaScript et manipulation au clavier. La touche Tab doit permettre d’atteindre les éléments interactifs dans un ordre cohérent. Le focus doit rester visible. Les actions doivent pouvoir être déclenchées sans souris, et une fenêtre ouverte ne doit ni faire perdre le contexte ni piéger l’utilisateur.

Dans un parcours numérique, le libellé, le focus, l’état annoncé et l’action attendue doivent rester cohérents. Un bouton visuellement clair devient un point de rupture s’il ne restitue pas son état « ouvert », « sélectionné » ou « indisponible » à la synthèse vocale. Le test doit donc porter sur l’interaction complète, et pas seulement sur le rendu graphique ou la présence d’un attribut HTML.

Les lecteurs d’écran de référence, JAWS, NVDA et VoiceOver, permettent d’évaluer cette restitution. Ils révèlent les titres absents, les régions mal nommées, les liens ambigus et les composants ARIA mal implémentés. Une attention particulière est nécessaire pour les design patterns ARIA tels qu’Accordion, Dialog, ProgressBar, RadioButton, Checkbox, Slider, TabPanel et Tooltip. ARIA ne corrige pas une interaction mal pensée : il complète une sémantique et un comportement déjà solides.

3. Qualifier les écarts pour rendre la correction possible

Pour chaque non-conformité, le rapport doit indiquer le critère concerné, la page ou le composant observé, la preuve, l’impact utilisateur et une recommandation actionnable. « Améliorer l’accessibilité du formulaire » n’aide pas l’équipe à agir. « Associer chaque champ à une étiquette visible et annoncer l’erreur reliée au champ » permet de corriger puis de retester précisément.

Transformer le rapport d’audit en plan d’actions utile

Un bon rapport d’audit d’accessibilité ne se limite pas à une liste d’anomalies. Il comprend une synthèse de la méthode, le périmètre, l’échantillon retenu, les résultats par critère, les non-conformités détaillées, les éventuelles dérogations et des recommandations. La réunion de restitution permet de vérifier la compréhension des constats, d’expliquer les impacts et de traiter les contestations factuelles.

Prioriser selon le blocage, la fréquence et l’effort

Les corrections doivent commencer par ce qui empêche d’accéder à une fonction essentielle : connexion impossible au clavier, paiement inaccessible, formulaire sans indication d’erreur, navigation sans intitulé intelligible ou modale inutilisable avec un lecteur d’écran. Viennent ensuite les défauts récurrents, souvent corrigibles dans un composant partagé ou un modèle de page. Les améliorations locales peuvent enfin être planifiées avec les évolutions du produit.

  • Priorité 1 : obstacle bloquant sur un parcours essentiel ou une information indispensable.
  • Priorité 2 : défaut fréquent qui dégrade fortement l’autonomie sur plusieurs pages.
  • Priorité 3 : écart local, sans blocage immédiat, à intégrer au cycle de maintenance.

Le plan d’actions correctives gagne à désigner un responsable, une échéance, le composant ou la page concernée et le statut du retest. Après les corrections, un contre-audit ciblé vérifie que la résolution fonctionne dans les navigateurs et avec les technologies d’assistance concernés, sans créer de régression.

Déclaration d’accessibilité, ressources et montée en compétence

La déclaration d’accessibilité formalise le niveau de conformité constaté à partir de l’audit. Elle doit correspondre au périmètre réellement évalué et rester à jour lorsque le service évolue. Elle ne remplace ni le rapport détaillé ni le plan d’actions. Elle rend l’information accessible aux utilisateurs et fournit à l’organisation un cadre de suivi.

Pour travailler avec une méthode fiable, consultez le référentiel RGAA, le guide de l’auditeur et les procédures de test associées. Une formation à l’audit d’accessibilité numérique aide à interpréter les critères, à manipuler les lecteurs d’écran, à tester les composants interactifs et à rédiger des recommandations exploitables. La maîtrise de la méthode par l’auditeur et l’implication des équipes facilitent le maintien de l’accessibilité dans la durée.

Apolline Gendreau-Lafitte

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Retour en haut