Les services numériques sont désormais le point d’accès privilégié aux administrations, à l’enseignement et aux entreprises en Australie et en Nouvelle-Zélande. À mesure que de plus en plus de transactions, de demandes et d’inscriptions se font en ligne, les autorités de régulation et le grand public s’intéressent de plus près à la question de savoir si ces services sont réellement accessibles aux personnes en situation de handicap. En Australie, la loi de 1992 sur la discrimination fondée sur le handicap (Disability Discrimination Act, 1992) (DDA) est invoquée depuis plus de deux décennies pour contester l’inaccessibilité de sites web, et la Commission australienne des droits de l’homme (AHRC) a renforcé ce contrôle en avril 2025 en publiant de nouvelles lignes directrices affirmant que les WCAG 2.2 niveau AA constituent la référence pratique pour les biens et services numériques. En Nouvelle-Zélande, la norme gouvernementale d’accessibilité du Web 1.2, entrée en vigueur en mars 2025, exige officiellement que les pages Web des services publics soient conformes aux WCAG 2.2, niveau AA.
Dans ce contexte, “ lancer une analyse ” ne constitue plus une alternative valable à un audit. Un audit WCAG est un processus d’évaluation structuré, et non le résultat d’un simple outil ; les organisations qui le considèrent comme tel ont tendance à se rendre compte de cette lacune lors d’une réclamation ou d’un examen des marchés publics, plutôt qu’avant. Comprendre ce que accessibilité numérique ce que cela implique réellement, et en quoi cela diffère de l'automatisation accessibilité des sites web La vérification constitue la première étape vers une position de conformité défendable.
Ce guide présente en détail ce qu'implique un audit WCAG rigoureux, les étapes nécessaires à sa réalisation, ainsi que les spécificités régionales propres aux organisations australiennes et néo-zélandaises. Un audit WCAG rigoureux combine une définition structurée du périmètre, une validation automatisée, une évaluation manuelle et un plan de mise en conformité documenté, le tout conforme aux WCAG 2.2.
Qu'est-ce qu'un audit WCAG ?
Un audit WCAG consiste en une évaluation systématique d'un site web au regard des Directives pour l'accessibilité des contenus web (WCAG), généralement la version 2.1 ou WCAG 2.2, afin de déterminer dans quelle mesure il respecte ou ne respecte pas certains critères de réussite spécifiques. Les WCAG définissent trois niveaux de conformité : A (minimum), AA (le niveau attendu par la plupart des autorités de régulation, des cadres de passation de marchés et des normes gouvernementales de la région) et AAA (un niveau renforcé qui n’est pas entièrement obligatoire). Un audit évalue la conformité par rapport à des critères précis et vérifiables, plutôt que sur la base d’une impression générale d“” accessibilité “ ou d”« inaccessibilité ».”
Chaque critère de conformité relève de l’un des quatre principes, communément abrégés sous l’acronyme POUR : le contenu doit être perceptible (Perceivable), utilisable (Operable), compréhensible (Understandable) et robuste (Robust). Un audit rigoureux évalue ces quatre critères sur toutes les interfaces concernées, et pas seulement sur la page d’accueil ou un site marketing. Cela inclut les pages web et les portails, mais aussi les documents téléchargeables tels que les PDF, qui sont explicitement pris en compte tant dans les recommandations australiennes que dans la norme d’accessibilité web du gouvernement néo-zélandais.
Il convient de préciser ce qu’un audit n’est pas. Les outils d’analyse automatisés sont précieux et nécessaires, mais ils ne détectent mécaniquement qu’un sous-ensemble des non-conformités aux WCAG, généralement compris entre 18 et 30 %, selon l’outil et la complexité du site. Les critères qui relèvent du jugement humain, tels que la pertinence d’un texte alternatif, la cohérence logique d’un ordre de focus ou la clarté d’un message d’erreur, nécessitent des tests manuels et souvent une évaluation directe à l’aide de technologies d’assistance. Un audit WCAG n’est complet que lorsqu’il associe une couverture automatisée à une évaluation manuelle et produit une documentation mettant en correspondance les constatations avec des critères de succès spécifiques, ainsi que les mesures correctives. C’est le raisonnement humain et l’analyse d’experts qui distinguent un audit d’une analyse, et c’est ce qui rend la position de conformité qui en résulte défendable si elle venait à être contestée.
Étape 1 : Définir le périmètre et les normes
Avant de commencer tout audit, il est nécessaire de convenir d’un périmètre et de le consigner par écrit. Les audits qui démarrent sans champ d’application défini ont tendance à se concentrer sur les pages les plus faciles à tester, ce qui donne une image incomplète et un faux sentiment de confiance. Il est tout aussi important de définir la norme par rapport à laquelle vous effectuez les tests, car la “ conformité aux WCAG ” revêt des significations très différentes selon la version et le niveau mentionnés.
Sélectionnez la version et le niveau appropriés des WCAG
Les normes WCAG 2.1 et WCAG 2.2 partagent la même structure de base, mais la version 2.2 ajoute de nouveaux critères de conformité portant sur l’accessibilité cognitive, les troubles moteurs et les modes d’interaction sur les appareils mobiles, qui ne sont pas couverts par la version 2.1, notamment des exigences relatives à la visibilité du curseur, à la taille des éléments cibles et à la suppression des saisies de données redondantes. Tant les recommandations 2025 de l’AHRC que la norme d’accessibilité Web 1.2 du gouvernement néo-zélandais font désormais référence aux WCAG 2.2 niveau AA, ce qui en fait la référence pratique pour les organisations d’Australasie, quel que soit leur secteur d’activité. Le niveau AA est le niveau attendu dans la quasi-totalité des cas où la conformité est évaluée ; les critères AAA sont utiles dans des contextes spécifiques, mais ne constituent pas un objectif global réaliste pour la plupart des environnements numériques. Quelle que soit la version et le niveau que vous choisissez, consignez-les clairement comme norme applicable à l’audit et alignez-les sur toute politique d’accessibilité interne déjà en place, afin qu’il n’y ait aucune ambiguïté par la suite quant à la signification des mentions “ conforme ” ou “ non conforme ”.
Définir clairement le périmètre de l'audit
Le périmètre doit être défini en fonction du parcours utilisateur et des modèles de page, et non sur la base de suppositions. Un périmètre représentatif comprend généralement les pages d’information destinées au grand public, les portails réservés aux membres ou aux clients authentifiés, les workflows transactionnels tels que les demandes, les paiements ou les réservations, les modèles à fort trafic que la plupart des utilisateurs consultent réellement, les outils et widgets tiers intégrés (moteurs de réservation, outils de chat, passerelles de paiement) et les fichiers PDF téléchargeables. Se contenter d’auditer la page d’accueil est l’une des raisons les plus courantes pour lesquelles les organisations finissent par avoir un faux sentiment de conformité, car les pages d’accueil sont souvent les plus soignées d’un site et sont rarement représentatives des formulaires, tableaux et composants interactifs enfouis plus profondément dans l’expérience utilisateur.
Étape 2 : Réaliser des tests d'accessibilité automatisés
Une fois le périmètre défini, les tests automatisés constituent un point de départ efficace. Les outils automatisés analysent le code HTML et CSS généré à la lumière d’un sous-ensemble des critères de conformité des WCAG et peuvent traiter des centaines, voire des milliers de pages en une fraction du temps nécessaire aux tests manuels. Ils sont particulièrement efficaces pour détecter les erreurs récurrentes au niveau du code : attributs « alt » manquants ou vides sur les images, rapports de contraste des couleurs insuffisants, structures de titres qui sautent des niveaux ou sont utilisées à des fins de mise en forme visuelle plutôt que pour la structure du document, et champs de formulaire dépourvus d’étiquettes associées par programmation.
Des outils tels que Vérification de la présence d'un gravelot et Grackle Go sont utiles ici pour établir rapidement une base de référence reproductible à l'échelle d'un site ou d'un ensemble de documents avant le début des tests manuels. Cela dit, les résultats automatisés doivent être considérés comme un état des lieux initial, et non comme une conclusion. Les outils automatisés ne peuvent pas déterminer si un texte alternatif est pertinent dans son contexte, si un ordre de tabulation est logique ou si un widget personnalisé fonctionne correctement pour les utilisateurs de technologies d’assistance ; ces évaluations nécessitent l’intervention d’une personne. Tout audit qui s’arrête à l’étape de l’analyse automatisée ne rend compte que d’une couverture partielle, et non de la conformité aux WCAG.
Étape 3 : Réaliser une évaluation manuelle des WCAG
C'est lors de l'évaluation manuelle que se forge la crédibilité de l'audit, car elle permet de vérifier ce que les outils automatisés ne peuvent structurellement pas évaluer : l'accessibilité réelle à l'aide d'un clavier, d'un lecteur d'écran et via des composants interactifs développés à l'aide de scripts personnalisés. Cette étape est celle qui demande le plus de temps et d'expertise, et c'est celle que les organisations qui s'appuient uniquement sur des outils ont le plus tendance à négliger.
Tests de navigation au clavier
Un testeur doit débrancher la souris et parcourir l'intégralité du parcours testé en utilisant uniquement le clavier, en vérifiant que l'ordre de tabulation suit un ordre de lecture logique, que les indicateurs de focus sont visibles à chaque étape, que les liens de saut sont présents et fonctionnels pour contourner les étapes de navigation répétitives, qu'il n'existe aucun « piège clavier » où le focus reste bloqué à l'intérieur d'un composant, et que les boîtes de dialogue modales capturent et restituent correctement le focus lorsqu'elles sont ouvertes et fermées.
Test du lecteur d'écran
Cette étape permet de vérifier que l'expérience reste cohérente lorsqu'elle est perçue à l'oreille plutôt qu'à l'œil. Les testeurs vérifient que la hiérarchie des titres est logique et reflète fidèlement la structure du document, que les zones de repère (en-tête, navigation, corps du texte, pied de page) sont correctement identifiées afin que les utilisateurs puissent passer d'une section à l'autre, que les champs de formulaire annoncent correctement leurs libellés, leur statut obligatoire et les erreurs de validation, et que l'ordre de lecture corresponde à la mise en page visuelle.
Tests des composants interactifs
Les interfaces modernes s'appuient largement sur des composants sur mesure, tels que les menus déroulants, les onglets, les carrousels et les accordéons, qui ne se comportent pas comme des éléments HTML natifs s'ils ne sont pas correctement codés. Les tests visent ici à vérifier si les rôles, états et propriétés ARIA sont correctement implémentés et mis à jour lorsque le composant change d’état, si les mises à jour dynamiques du contenu (résultats de recherche en temps réel, validation de formulaire) sont signalées aux technologies d’assistance, et si les messages d’erreur sont à la fois visibles et associés par programmation au champ concerné.
Étape 4 : Tester les parcours des utilisateurs réels
Au-delà du test isolé de pages et de composants individuels, un audit complet passe en revue l'intégralité des parcours utilisateur de bout en bout, en suivant le cheminement qu'un utilisateur réel emprunterait sur le site. Cela comprend généralement le fait de remplir et d'envoyer des formulaires, de déposer une demande, de réserver un service ou un rendez-vous, de se connecter à un portail authentifié et d'y naviguer, ainsi que d'ouvrir des documents liés ou d'interagir avec ceux-ci.
Les fichiers PDF méritent ici une attention particulière, car ils constituent souvent le maillon faible d’un parcours numérique par ailleurs accessible. Un formulaire administratif, un rapport annuel ou un document de politique générale publié sous forme de fichier PDF non balisé ou mal structuré peut réduire à néant le travail d’accessibilité réalisé sur le site web qui l’héberge ; or, les fichiers PDF relèvent explicitement du champ d’application tant des recommandations australiennes que de la norme néo-zélandaise. Des outils tels que Canard pilet PDF sont spécialement conçus pour détecter et corriger les problèmes d'accessibilité des documents que les outils d'analyse au niveau de la page ne repèrent généralement pas du tout. L'intérêt général de cette étape réside dans le fait qu'un audit WCAG évalue si une personne est réellement en mesure d'accomplir une tâche, et pas seulement si des éléments individuels satisfont à des contrôles techniques isolés.
Étape 5 : Consigner les résultats par rapport aux critères des WCAG
Les conclusions ne sont utiles que si elles sont consignées de manière à ce qu'une personne extérieure à l'équipe d'audit — un responsable technique, un responsable des achats ou un organisme de réglementation — puisse s'en servir pour agir ou les vérifier. Chaque problème doit être associé au critère de conformité WCAG spécifique qu'il enfreint, plutôt que d'être décrit en termes généraux, afin que les équipes chargées de la correction sachent précisément à quoi ressemble la solution.
Chaque constat doit inclure une capture d’écran, une référence de code ou une description claire des étapes permettant de reproduire le problème, afin qu’un développeur ou un auteur de contenu puisse vérifier le problème sans avoir à relancer l’audit dans son intégralité, ainsi qu’une recommandation quant à la marche à suivre pour y remédier. Une fois les constatations évaluées, incluez une feuille de route de correction assortie de délais réalistes ; la mise en place d’un plan hiérarchisé contribue à faciliter la mise en œuvre des mesures correctives. Ce niveau de documentation permet de justifier la conformité en matière d’accessibilité : il démontre que les problèmes ont été identifiés de manière systématique, hiérarchisés de façon raisonnable et suivis jusqu’à leur résolution, plutôt que traités de manière réactive à la suite d’une réclamation.
Aspects réglementaires en Australasie
Le contexte réglementaire régional détermine l’urgence et l’étendue des audits qu’une organisation doit mener, mais il convient de préciser clairement ce que cette section est et ce qu’elle n’est pas : il s’agit d’une prise de conscience réglementaire destinée à éclairer la planification, et non d’un conseil juridique ; les organisations doivent consulter leur propre conseiller juridique concernant leurs obligations spécifiques. Ce qui est commun à l’Australie et à la Nouvelle-Zélande, c’est que les WCAG, et plus précisément la version WCAG 2.2 AA, sont désormais la référence technique utilisée pour évaluer si un service numérique répond aux attentes en matière d’accessibilité.
Australie – Loi sur la lutte contre la discrimination fondée sur le handicap (DDA)
La loi de 1992 sur la discrimination fondée sur le handicap (Disability Discrimination Act, DDA) interdit toute discrimination à l’encontre des personnes en situation de handicap dans la fourniture de biens et de services ; elle s’applique aux sites web depuis l’affaire Maguire c. Comité d’organisation des Jeux Olympiques de Sydney en 2000, qui a établi que le champ d’application de la DDA s’étendait aux services numériques. L’AHRC, l’organisme officiel chargé d’enquêter sur les plaintes pour discrimination, a publié en avril 2025 des lignes directrices actualisées sur l’égalité d’accès aux biens et services numériques, en désignant spécifiquement les WCAG 2.2 niveau AA comme référence pour évaluer si les produits et services numériques d’une organisation respectent ses obligations. Cette disposition s’applique à l’ensemble des organisations des secteurs public et privé fournissant des services numériques destinés au grand public, et non pas uniquement aux agences gouvernementales.
Nouvelle-Zélande – Norme d'accessibilité du Web
L'approche néo-zélandaise est plus directement normative pour le secteur public. La norme d’accessibilité du Web du gouvernement néo-zélandais 1.2, qui entrera en vigueur le 17 mars 2025, exige que toutes les pages Web relevant de son champ d’application – une définition qui inclut explicitement les applications Web et les documents tels que les fichiers Word et les PDF – soient conformes aux WCAG 2.2 au niveau AA, sous réserve d’un petit nombre d’exceptions définies. Cette norme est obligatoire pour les services de la fonction publique, les forces armées, la police et le Bureau du conseiller parlementaire ; les autres organismes du secteur public et des collectivités locales sont encouragés à l’adopter, sans y être tenus. Pour toute organisation fournissant des services aux agences gouvernementales néo-zélandaises ou en collaboration avec celles-ci, la mise en conformité avec cette norme est de plus en plus considérée comme une exigence plutôt que comme une simple recommandation.
Erreurs courantes lors des audits WCAG
Même les organisations qui s'engagent à mener un audit peuvent en compromettre la valeur en commettant quelques erreurs récurrentes. La plus fréquente consiste à se fier uniquement à des outils automatisés et à présenter les résultats de l'analyse comme un audit complet, ce qui laisse sans vérification les critères les plus susceptibles de bloquer réellement les utilisateurs : l'ordre de focus, les textes alternatifs pertinents et le comportement des composants personnalisés. Un autre écueil étroitement lié est celui de se limiter à la page d’accueil : la page la plus visible et la mieux dotée en ressources d’un site est testée, tandis que les modèles, formulaires et flux transactionnels plus enfouis dans le site, qui génèrent le plus d’activité utilisateur, ne sont pas examinés.
Les fichiers PDF et autres documents téléchargeables sont systématiquement exclus du champ d’application, bien qu’ils soient explicitement couverts par les directives australiennes et néo-zélandaises et qu’ils constituent souvent le principal point faible en matière d’accessibilité. Les outils SaaS tiers et les widgets intégrés, les systèmes de réservation, les interfaces de chat et les passerelles de paiement constituent un autre angle mort courant ; les organisations testent leur propre code tout en partant du principe que les outils intégrés des fournisseurs relèvent de la “ responsabilité de quelqu’un d’autre ”, alors même que l’utilisateur final les perçoit comme faisant partie intégrante de son parcours. Enfin, deux erreurs structurelles ont tendance à compromettre la conformité à long terme, quelle que soit la qualité de l’audit initial : le fait de ne pas effectuer de nouveaux tests après la mise en œuvre des mesures correctives, ce qui ne permet pas de vérifier que les corrections ont bel et bien résolu le problème sous-jacent, et le fait de considérer l’audit comme un projet ponctuel plutôt que comme une pratique récurrente, ce qui garantit que la conformité se détériore à mesure que le site évolue et que de nouveaux contenus sont publiés.
Quand faire appel à des auditeurs professionnels spécialisés dans l'accessibilité ?
Certaines organisations sont en mesure de mener en interne un premier audit crédible, en particulier les sites de petite taille dont les modèles sont peu nombreux et le contenu simple. Cependant, dans certains cas, les ressources internes ne suffisent pas à elles seules pour obtenir un résultat capable de résister à un examen approfondi. Les plateformes d’entreprise complexes, comportant de nombreux types de contenu, des composants personnalisés et des systèmes tiers intégrés, nécessitent des tests approfondis et des outils spécialisés qu’il est difficile de développer en interne à partir de zéro. Les organisations soumises à une forte réglementation, les grands services publics, les institutions financières ou les universités accueillant une population étudiante nombreuse et diversifiée courent davantage de risques si un audit passe à côté d’un élément significatif.
Grâce à la norme australienne AS EN 301 549 relative à l’accessibilité dans les marchés publics, les procédures de passation de marchés publics exigent de plus en plus la présentation de preuves documentées de conformité aux WCAG comme condition d’attribution du marché, ce qui signifie qu’un audit mené en interne et documenté de manière informelle peut ne pas satisfaire aux critères de preuve qu’un responsable des marchés publics est tenu d’appliquer. De plus, en cas de litige ou de plainte officielle, une validation indépendante réalisée par un tiers a plus de poids qu’une auto-évaluation, à la fois parce qu’elle élimine tout soupçon de partialité et parce que les auditeurs expérimentés maîtrisent des méthodologies telles que la WCAG-EM, la méthodologie d’évaluation de la conformité en matière d’accessibilité des sites web du W3C, qui structure l’échantillonnage et l’évaluation selon des principes reconnus et reproductibles. Dans tous ces cas de figure, un audit structuré et validé de manière indépendante constitue un atout nettement plus solide si le résultat venait à être remis en cause.
Prenez rendez-vous dès aujourd'hui pour votre audit stratégique WCAG →
Mise en place d'un programme durable de conformité aux WCAG
Un audit ponctuel, aussi approfondi soit-il, ne constitue qu’un instantané. Les sites web évoluent sans cesse : nouvelles pages, nouvelles fonctionnalités, nouveaux contenus… Et sans programme mis en place, la conformité atteinte aujourd’hui s’érode en l’espace de quelques mois. Une conformité durable consiste à considérer l’accessibilité comme une discipline opérationnelle plutôt que comme un projet doté d’une date butoir.
- Mettre en place une gouvernance en matière d'accessibilité. Définir clairement les responsabilités des dirigeants en matière de résultats liés à l'accessibilité, plutôt que de laisser cette responsabilité sans propriétaire, répartie entre les équipes chargées du contenu, de la conception et du développement.
- Réaliser un audit initial des WCAG. Utilisez le processus structuré décrit ci-dessus pour identifier les problèmes systémiques au sein de l'ensemble du site web, et pas seulement les défauts isolés sur des pages individuelles.
- Définir stratégiquement les priorités en matière de remédiation. Commencez par résoudre les problèmes qui empêchent la plupart des utilisateurs d'accomplir les tâches les plus importantes, plutôt que de traiter les problèmes dans l'ordre où ils ont été identifiés.
- Intégrer l'accessibilité dans les processus de développement. Intégrer des contrôles automatisés et des étapes de vérification manuelle dans les processus de conception et de développement afin de détecter les nouveaux problèmes d'accessibilité avant la publication, et d'éviter ainsi toute régression du travail déjà effectué.
- Prévoir des nouveaux audits réguliers. Réexaminez l'ensemble du processus d'audit à intervalles réguliers afin de vous assurer que les problèmes corrigés le restent et que les nouveaux contenus publiés respectent les mêmes normes.
Un audit WCAG est un point de départ, pas une ligne d'arrivée
La valeur d’un audit WCAG réside dans ce qu’il met en évidence : les obstacles spécifiques et documentés qui empêchent les personnes en situation de handicap d’utiliser pleinement un service numérique. Mais identifier ces obstacles ne représente que la moitié du travail. Une accessibilité numérique durable repose sur une gouvernance, des processus de développement intégrés et une cadence d’audits régulière qui empêchent les mêmes problèmes de réapparaître discrètement quelques mois plus tard. Pour les organisations d’Australasie soumises à une surveillance réglementaire croissante de la part de l’AHRC et de la norme d’accessibilité du Web du gouvernement néo-zélandais, l’accessibilité doit être abordée non pas comme une campagne ponctuelle de mise en conformité, mais comme une discipline opérationnelle permanente, avec la même rigueur que celle appliquée à la sécurité ou à la gouvernance des données.
Si votre organisation se prépare à un audit WCAG ou s'aligne sur les normes WCAG 2.2, contactez l'équipe de GrackleDocs pour discuter d'une évaluation structurée qui favorisera la conformité à long terme en matière d'accessibilité.