Comment auditer l'accessibilité de votre site en 2 heures : stack open-source et checklist EAA

Par l'équipe de Kiwop · Agence Digitale spécialisée en Développement Logiciel et Intelligence Artificielle appliquée · Publié le 7 mai 2026 · Dernière mise à jour : 7 mai 2026

TL;DR — La deadline de l'European Accessibility Act était le 28 juin 2025. La majorité des sites sont encore non conformes. Ce post vous donne le framework pratique : 5 outils open-source qui couvrent ~70 % des erreurs automatisables, un audit complet en 2 heures, et une checklist EAA priorisée par impact légal. Sans consultants, sans budget spécial. Uniquement un stack éprouvé et des commandes copiables.

Quand l'European Accessibility Act est entré en vigueur le 28 juin 2025, la réaction la plus courante dans les équipes techniques a été : « on regarde ça la semaine prochaine ». Dix mois après, la majorité de ces sites sont restés identiques. Le rapport WebAIM Million 2024 l'avait confirmé avant même la deadline : 94,8 % des pages d'accueil analysées présentaient des erreurs WCAG détectables automatiquement.

Le problème n'est pas le manque de volonté. C'est le manque d'un point d'entrée clair. Vous savez que vous devez respecter WCAG 2.2 AA, vous savez qu'il existe des outils, mais vous ne savez pas par où commencer, combien de temps cela demande, ni comment prioriser ce que vous trouvez.

Cet article est ce point d'entrée. Si vous avez déjà lu notre guide sur la réglementation EAA, les délais et les sanctions, c'est l'étape suivante : la procédure technique concrète. Si vous ne l'avez pas lu, faites-le d'abord — ici nous supposons que vous savez ce que la loi vous exige et nous nous concentrons sur la façon de l'exécuter.

Pourquoi auditer MAINTENANT (et non la semaine prochaine)

L'état réel de la conformité EAA en 2026

La deadline est passée. Ce n'est pas une menace future : l'EAA est déjà une loi applicable dans tous les États membres de l'UE qui ont transposé la directive avant le 28 juin 2025. Et les chiffres de conformité sont alarmants.

Le WebAIM Million 2024 a analysé les 1 000 000 pages d'accueil les plus visitées. Résultat : 94,8 % présentaient au moins une erreur WCAG 2.1 AA détectable automatiquement — et cela avant de compter les erreurs qui n'apparaissent qu'en révision manuelle. Les erreurs les plus courantes : faible contraste de couleur (81 % des pages), texte alternatif absent (54,5 %), étiquettes de formulaire manquantes (48,6 %), liens vides (44,6 %) et boutons sans nom accessible (28,2 %).

Autrement dit : votre site présente presque certainement tous ces problèmes. La question n'est pas de savoir si vous êtes conforme, mais combien de critères vous ne respectez pas et avec quelle gravité.

Le risque légal concret

Le portail officiel de la Commission européenne sur l'EAA est clair : la réglementation s'applique à toute entreprise qui offre des produits ou services numériques à des consommateurs dans l'UE, quel que soit son siège. Les sanctions sont fixées par chaque État membre, mais la directive exige qu'elles soient « effectives, proportionnées et dissuasives ». Dans plusieurs pays, des amendes allant jusqu'à 100 000 euros par infraction sont déjà prévues.

Au-delà des amendes : toute personne en situation de handicap qui ne peut pas accéder à votre service peut déposer une plainte formelle auprès de l'organisme de supervision de son pays. La charge de la preuve incombe à l'entreprise — vous devez démontrer que vous êtes conforme, pas eux que vous ne l'êtes pas.

Ce qu'exige le régulateur (et ce qu'il n'exige pas)

Ce qu'il exige, c'est la conformité avec WCAG 2.2 niveau AA et une déclaration d'accessibilité publique. Ce qu'il n'exige pas, c'est la perfection totale ni un audit annuel signé par une entreprise certifiée. Il exige un niveau de diligence raisonnable, documenté.

Ce qui ne vous sauve pas : un overlay JavaScript qui se superpose à votre site en promettant de l'accessibilité automatique. La FTC a condamné accessiBe à une amende d'un million de dollars pour publicité trompeuse exactement sur ce point. Aucun organisme de régulation n'accepte un overlay comme preuve de conformité.

Le premier vrai pas de cette diligence, c'est l'audit. Et vous pouvez le faire en 2 heures avec les bons outils.

Le stack : 5 outils open-source qui couvrent ~70 % de WCAG 2.2 AA

Avant de voir le processus, comprenez la limite fondamentale de tout outil automatique : ils détectent environ 30-40 % des problèmes d'accessibilité réels. C'est ce qu'indique le guide d'audit d'accessibilité du W3C. Le reste nécessite une révision manuelle — navigation au clavier, lecteurs d'écran, jugement humain.

Pourquoi alors commencer par des outils automatiques ? Parce qu'ils vous permettent d'éliminer systématiquement la couche la plus épaisse d'erreurs en quelques minutes, libérant du temps pour la révision manuelle où se trouve vraiment la valeur.

axe-core (Deque) — le moteur standard de l'industrie

axe-core est la librairie open-source de Deque Systems qui alimente aujourd'hui pratiquement tous les outils de testing d'accessibilité de l'industrie. Chrome DevTools, Storybook, Playwright, Cypress et des dizaines de frameworks CI l'utilisent. Ce n'est pas une option parmi d'autres : c'est le moteur.

Son principal avantage n'est pas la couverture — c'est le taux de faux positifs pratiquement nul. Quand axe signale une erreur, c'est une vraie erreur. Quand il ne signale rien, cela ne signifie pas que vous êtes propre ; cela signifie que les erreurs qu'il ne détecte pas font partie de ces 60-70 % qui nécessitent une révision manuelle.

Vous pouvez utiliser axe de trois façons :

Comme extension de navigateur (axe DevTools Free) : installez l'extension dans Chrome ou Firefox, ouvrez votre page, lancez l'analyse. Résultat en quelques secondes. Zéro configuration. Idéal pour le premier contact.

Comme librairie dans les tests : intégrez axe-core directement dans votre suite de tests avec Playwright ou Cypress :

Via CLI avec @axe-core/cli :

Lighthouse — le complément gratuit de Chrome

Lighthouse inclut un audit d'accessibilité dans son rapport standard, basé également sur axe-core, mais avec une couverture supplémentaire de métriques de performance et quelques vérifications propres.

Son score d'accessibilité (0-100) n'équivaut pas à un pourcentage de conformité WCAG. C'est une mesure relative qui sert de référence. Ce qui est vraiment utile, c'est la liste d'issues catégorisée qu'il génère.

Vous pouvez l'exécuter depuis :

• Chrome DevTools → Lighthouse → Catégorie « Accessibilité »
• CLI : npx lighthouse https://votre-site.com --only-categories=accessibility --output json
• PageSpeed Insights : https://pagespeed.web.dev/ (gratuit, sans installation)

La documentation officielle de Lighthouse accessibilité de Google documente exactement ce que chaque critère vérifie et comment le score est calculé. Lisez-la une fois pour ne pas mal interpréter les résultats.

Pa11y — audit depuis CLI/CI

Pa11y est l'outil en ligne de commande conçu pour s'intégrer dans les pipelines CI/CD. Il peut auditer une seule URL, un sitemap complet ou une liste de pages, et exporter les résultats dans plusieurs formats.

Pa11y utilise htmlcs par défaut, mais peut être configuré pour utiliser axe-core comme moteur :

L'avantage de Pa11y par rapport à axe lancé manuellement est qu'il gère bien les pages avec JavaScript asynchrone, l'authentification basique et les sites multi-pages sans avoir à écrire des scripts propres.

NVDA + VoiceOver — les vrais lecteurs d'écran

Aucun outil automatique ne peut remplacer 20 minutes de navigation sur votre site avec un lecteur d'écran. Les résultats sont toujours révélateurs — et toujours différents de ce que vous attendiez.

NVDA (Windows, gratuit) : le lecteur d'écran le plus utilisé sous Windows. Téléchargez-le depuis nvaccess.org. Les raccourcis essentiels pour un audit rapide :

VoiceOver (macOS/iOS, inclus dans le système) : activez-le avec Cmd + F5. Pour un audit rapide sur macOS :

Ce que vous cherchez avec les deux lecteurs : annonce-t-il correctement le type de chaque élément (bouton, lien, champ) ? Les formulaires ont-ils des étiquettes ? Les images ont-elles des alt utiles ? L'ordre de lecture est-il logique ?

WAVE (extension navigateur) — vérifications visuelles rapides

L'extension WAVE de WebAIM superpose des icônes visuelles directement sur la page en indiquant erreurs, alertes et éléments structurels. C'est la façon la plus rapide d'avoir une vue visuelle des problèmes sans quitter le navigateur.

Particulièrement utile pour :

• Voir en un coup d'œil la hiérarchie des headings (sautez-vous de H1 à H4 ?)
• Détecter les zones de faible contraste dans le contexte visuel
• Identifier les formulaires sans label avant d'exécuter axe
• Vérifier que les landmarks ARIA sont bien définis (header, nav, main, footer)

Ne l'utilisez pas comme outil principal — il a plus de faux positifs qu'axe. Utilisez-le comme premier coup d'œil visuel avant d'exécuter les autres.

Pas à pas : votre premier audit en 2 heures

Ce protocole couvre les pages les plus critiques de votre site : accueil, une page de listing, une page de détail, et le parcours de conversion principal (contact, inscription ou achat). Les 2 heures réparties ainsi :

Minute 0-15 : setup → Minute 15-45 : automatisation → Minute 45-90 : révision manuelle → Minute 90-120 : priorisation et rapport

Minute 0-15 : setup

Avant de lancer des outils, définissez exactement quelles pages vous allez auditer. Un audit qui essaie de couvrir tout le site d'un coup finit sans bien couvrir quoi que ce soit.

Liste minimale recommandée pour un premier audit :

1. Accueil (/)
2. Une page de listing ou catégorie représentative
3. Une page de détail ou service représentative
4. Page de contact ou formulaire principal
5. Une page de checkout ou d'inscription (si applicable)

Avec cette liste, installez les outils :

Installez aussi l'extension WAVE dans Chrome ou Firefox, et téléchargez NVDA si vous êtes sous Windows (ou activez VoiceOver sur macOS avec Cmd + F5).

Minute 15-45 : exécution automatisée (axe + Lighthouse + Pa11y)

Exécutez les trois outils sur chaque URL de votre liste. L'ordre importe : commencez par axe parce que son output est le plus propre, puis Lighthouse pour la vue performance + accessibilité combinée, et Pa11y pour valider avec un second moteur.

Pendant l'exécution, ouvrez chaque URL dans Chrome avec l'extension WAVE active. Notez visuellement les patterns que vous observez avant de lire les rapports.

Quand les scripts se terminent, ouvrez les JSON avec n'importe quel visualiseur ou comptez simplement les violations :

Minute 45-90 : tests manuels avec lecteurs d'écran

C'est la partie qui apporte le plus et que l'on saute le plus souvent. Ne la sautez pas.

Protocole de 20 minutes avec NVDA ou VoiceOver (répétez pour chaque page critique) :

1. Naviguez uniquement avec Tab depuis le début de la page. Le premier élément est-il « aller au contenu principal » (skip link) ? Le focus est-il visible à tout moment ? L'ordre est-il logique ?

1. Ouvrez la liste des headings (Insert + F7 sous NVDA, rotor sous VoiceOver). Y a-t-il un H1 ? La hiérarchie est-elle cohérente ? Y a-t-il des headings sur des éléments qui ne sont visuellement pas des headings ?

1. Activez le mode formulaire s'il y a des formulaires. Remplissez le formulaire en utilisant uniquement le clavier. Chaque champ annonce-t-il son étiquette ? Les erreurs de validation sont-elles annoncées correctement ? Pouvez-vous soumettre le formulaire ?

1. Naviguez par liens (touche K sous NVDA). Tous les liens ont-ils un texte descriptif hors contexte ? Aucun ne dit-il « cliquez ici », « voir plus » ou « lire » ?

1. Écoutez les images. Quand le focus arrive sur une image, le texte alternatif décrit-il son contenu ou sa fonction ? Les images décoratives sont-elles ignorées (alt="") ?

Documentez chaque problème trouvé avec : URL, élément affecté, critère WCAG non respecté, et priorité (nous la verrons à l'étape suivante).

Minute 90-120 : priorisation et rapport

Vous avez deux sources d'issues : les rapports automatiques et vos notes manuelles. Le travail consiste maintenant à les unifier et à les prioriser par impact légal et utilisateur.

N'essayez pas de résoudre quoi que ce soit pour l'instant. L'objectif des 2 heures est le diagnostic, pas la remédiation.

Pour le rapport, créez un document avec cette structure minimale :

Comment interpréter les résultats : priorisation par impact légal

La plus grande erreur dans l'interprétation d'un audit d'accessibilité est de traiter toutes les issues de façon identique. Un faible contraste dans un texte de pied de page a des conséquences très différentes d'un formulaire d'inscription non opérable au clavier.

La matrice de priorisation combine deux axes : sévérité pour l'utilisateur (est-ce que cela bloque l'usage ?) et exposition légale (cela affecte-t-il des parcours critiques que le régulateur examinerait en premier ?).

Issues critiques (bloquent la conformité)

Une issue est critique quand elle empêche de réaliser une tâche pour un utilisateur en situation de handicap ou quand elle affecte un parcours que le régulateur examinerait prioritairement (inscription, achat, contact, accès au service).

Les candidats habituels :

• Formulaires non accessibles au clavier : le critère WCAG 2.1.1 (Clavier) est de niveau A — le niveau minimal. Ne pas le respecter dans le formulaire de contact est un blocage de conformité direct.
• Images fonctionnelles sans alt : une image qui est un lien ou un bouton sans texte alternatif prive l'utilisateur de lecteur de l'information pour agir. Critère 1.1.1.
• Boutons sans nom accessible : <button><svg>...</svg></button> sans aria-label. Le bouton existe, l'utilisateur sait qu'il est là, mais il ne sait pas ce qu'il fait. Critère 4.1.2.
• Vidéo avec audio sans sous-titres : si vous avez des vidéos avec de l'information audio, le critère 1.2.2 exige des sous-titres synchronisés. L'absence est bloquante et très visible.

Issues majeures (haut risque de plainte)

Une issue est majeure quand elle gêne significativement l'usage sans le bloquer complètement, ou quand elle affecte des pages très visitées même si l'impact individuel est partiel.

• Faible contraste sur le texte principal : critère 1.4.3. Un ratio inférieur à 4,5:1 dans le corps de texte affecte les utilisateurs malvoyants et les utilisateurs dans des conditions de lumière difficiles (qui ne sont pas seulement des personnes en situation de handicap déclaré).
• Hiérarchie des headings rompue : sauter de H1 à H4, utiliser des headings uniquement pour leur style visuel, ou ne pas avoir de H1. Affecte les lecteurs d'écran et les utilisateurs cognitifs qui naviguent par structure. Critère 1.3.1.
• Focus visible absent : si l'outline du focus est supprimé globalement avec *:focus { outline: none; }, la navigation au clavier devient opaque. Critère 2.4.7 (AA) et 2.4.11 (AA dans WCAG 2.2).
• Messages d'erreur sans ARIA live regions : quand un formulaire valide et affiche des erreurs, le lecteur d'écran les annonce-t-il automatiquement ? Sinon, l'utilisateur ne sait pas que quelque chose a mal tourné. Critère 3.3.1.

Issues mineures (améliorations)

Une issue est mineure quand elle a un impact limité, affecte des éléments secondaires, ou nécessite un jugement de contexte pour déterminer si c'est vraiment un problème.

• Alt descriptif mais imprécis sur des images décoratives ou d'appui.
• Contraste légèrement inférieur au minimum sur des textes de pied de page ou des disclaimers.
• Rôles ARIA redondants qui ne causent pas de dommage mais n'ajoutent pas de valeur.
• Textes de liens contextuels (qui ont un sens avec le texte environnant, même pas seuls).

N'ignorez pas les mineures indéfiniment — elles finissent par s'accumuler. Mais ne bloquez pas la remédiation des critiques pour résoudre les mineures d'abord.

Ce que les outils NE détectent pas (et que vous devez faire manuellement)

Voici les 60-70 % qu'axe, Pa11y et Lighthouse ne voient pas. Ce bloc est ce qui différencie un vrai audit d'un check automatique et d'un clic sur « partager ». La documentation du W3C sur l'évaluation d'accessibilité le détaille rigoureusement ; voici la version pratique.

Texte alternatif « décoratif » mal utilisé : axe vérifie que les images ont un alt, mais ne peut pas savoir si le texte alternatif décrit correctement le contenu. « Image 1 » ou le nom du fichier passent le check automatique et constituent une vraie erreur.

Ordre de tabulation logique : Tab parcourt les éléments interactifs dans l'ordre du DOM. Si votre CSS réordonne visuellement les éléments, l'ordre de tabulation peut être chaotique. Aucun outil ne le détecte — seulement en naviguant avec Tab.

Étiquettes de formulaire correctement associées : axe détecte les labels absentes, mais ne détecte pas les labels présentes dans le HTML mais non associées au bon champ (que ce soit par des for/id incorrects ou une association de proximité mal implémentée).

Textes de liens contextuels : WCAG autorise les liens dont le texte (« voir plus ») a un sens en contexte grâce au texte environnant (critère 2.4.4 — En Contexte). Axe ne peut pas évaluer si ce contexte est suffisant. Seul un humain peut en juger.

Lecture du flux dans le lecteur d'écran : l'ordre de lecture d'un lecteur d'écran suit le DOM, pas la présentation visuelle. Les layouts avec CSS Grid ou Flexbox qui réordonnent visuellement les éléments peuvent générer un flux de lecture incompréhensible qu'aucun outil automatique ne détecte.

Sous-titres et transcriptions de vidéo : axe détecte si un élément <track> existe dans un <video>, mais ne peut pas vérifier si les sous-titres sont précis, complets ou bien synchronisés. Cela nécessite une révision humaine.

Gestes complexes sans alternative : si votre interface possède des fonctions activées par des gestes multi-doigts (pinch, swipe) sans alternative au clavier ou au toucher simple, c'est une violation du critère 2.5.1. Les outils de bureau ne le détectent pas.

ARIA mal utilisé : axe détecte l'ARIA invalide, mais ne détecte pas l'ARIA techniquement valide qui rompt la sémantique. Un role="presentation" sur un élément interactif, ou un aria-hidden="true" sur du contenu pertinent, passent le check automatique et constituent des erreurs graves.

Rédiger en format de conformité EAA

Un audit qui ne génère pas de documentation utile est un audit à moitié fait. Le régulateur ne demande pas un test axe ; il demande une preuve de diligence. Le guide d'accessibilité GOV.UK — référence du secteur bien qu'il soit de portée UK — documente le standard de facto pour les déclarations d'accessibilité que plusieurs régulateurs européens ont adopté comme référence.

Structure du rapport demandée par l'administration

Un rapport d'audit d'accessibilité que vous pouvez présenter au régulateur (ou qui vous servira de base pour votre déclaration) doit inclure :

1. Périmètre : quelles pages ont été auditées, pourquoi ces pages ont été choisies, et quelles technologies d'assistance ont été utilisées pour la révision manuelle.
2. Méthodologie : outils automatisés (versions exactes), processus de révision manuelle (lecteurs d'écran, versions de navigateur).
3. Standard évalué : WCAG 2.2 niveau AA / EN 301 549.
4. Résultats : liste des critères non respectés, avec preuves (captures d'écran, fragments HTML), classés par sévérité.
5. État de conformité : conformité totale, partielle ou non conforme — avec justification.
6. Exceptions documentées : s'il y a du contenu tiers incontrôlable (widget externe, carte intégrée), le documenter comme exception temporaire avec plan de résolution.
7. Date de l'audit et fréquence de révision.

Modèle de déclaration d'accessibilité

La déclaration d'accessibilité est le document public que l'EAA exige de publier sur votre site (habituellement sur une URL comme /accessibilite ou dans le pied de page). Structure minimale :

Comment documenter les exceptions temporaires

Si vous avez du contenu qui ne respecte pas les normes mais que vous ne pouvez pas remédier immédiatement (widget de chat tiers, carte intégrée, PDF hérité), l'EAA permet de le documenter comme exception temporaire sous certaines conditions :

• Décrire le contenu affecté et le critère WCAG non respecté.
• Justifier pourquoi c'est une charge disproportionnée de le résoudre immédiatement.
• Indiquer la date prévue de résolution ou l'alternative accessible disponible.
• Mettre à jour la déclaration quand c'est résolu.

Une exception documentée est une protection légale. Une exception sans documentation, non.

Maintenir la conformité : intégration dans la CI

L'audit ponctuel vous dit où vous en êtes aujourd'hui. L'intégration dans la CI vous dit si ce que vous publiez demain casse ce que vous avez corrigé hier. Sans CI d'accessibilité, la remédiation est un seau percé.

axe-core dans GitHub Actions / GitLab CI

Le bloc CI le plus basique avec axe et Playwright :

Et le test correspondant :

Si votre projet utilise React ou tout autre framework SPA, assurez-vous que le test attend que le contenu dynamique ait été rendu avant d'exécuter axe — utilisez page.waitForSelector ou page.waitForLoadState('networkidle').

Pa11y dashboard

Pa11y dispose d'un dashboard web open-source qui permet de surveiller l'accessibilité d'un site complet dans le temps et de voir l'évolution des issues par page. Particulièrement utile pour :

• Les sites avec de nombreuses pages générées dynamiquement (blogs, e-commerce).
• Les équipes où les résultats sont consultés par des personnes non techniques.
• Les audits programmés hebdomadaires ou mensuels sans intervention manuelle.

Pour les projets plus petits, Pa11y CI avec output JSON et un fichier de configuration versionné dans le dépôt suffit généralement :

Le paramètre threshold permet de définir un nombre maximum de violations acceptables avant d'échouer le build — utile quand vous êtes en cours de remédiation et que vous voulez éviter les régressions sans bloquer chaque PR.

Gating des pull requests

La façon la plus efficace de maintenir la conformité est de bloquer les merges de PRs qui introduisent de nouvelles violations. Le flux recommandé :

1. Le workflow de CI exécute axe sur les pages affectées par la PR.
2. S'il y a de nouvelles violations (par rapport à la branche de base), le check échoue.
3. La PR ne peut pas être mergée jusqu'à ce que les nouvelles violations soient résolues ou que l'exception soit documentée.

La clé est d'auditer uniquement les pages affectées — auditer tout le site sur chaque PR est trop lent. Une stratégie pratique : mapper quels composants chaque PR affecte et auditer les pages qui utilisent ces composants.

Ce modèle de QA automation intégré dans le cycle de développement est le même que nous appliquons à d'autres types de qualité : performance, sécurité, couverture de tests.

Métriques à surveiller

Les métriques qui comptent vraiment pour le suivi de l'accessibilité dans le temps :

Erreurs courantes en remédiation

L'audit représente la moitié du travail. La remédiation est là où la plupart des équipes font des erreurs qui créent de nouveaux problèmes ou donnent une fausse impression de conformité.

Erreur 1 : corriger uniquement ce que détecte axe

Si vous ne remédiez que les issues automatiques, vous couvrez 30-40 % du problème en laissant 60-70 % intouché. Le régulateur n'accepte pas « nous passons axe sans erreurs » comme preuve de conformité WCAG. Passez le check automatique ET la révision manuelle.

Erreur 2 : texte alternatif automatique par IA sans révision

Plusieurs outils d'accessibilité et CMS proposent la génération automatique de texte alt par IA. Le résultat peut être techniquement présent (ce qui satisfait axe) mais sémantiquement inutile ou incorrect. Un alt généré par IA décrivant « une personne utilisant un ordinateur portable dans un bureau » quand l'image montre un diagramme d'architecture technique passe le check automatique et échoue le critère réel. Révisez toujours les alts générés.

Erreur 3 : rôles ARIA inutiles qui cassent l'arbre

L'antipatron le plus courant en essayant d'« améliorer » l'accessibilité : ajouter des rôles ARIA à des éléments qui ont déjà une sémantique native correcte. <button role="button"> est redondant. <nav role="navigation"> est redondant. Mais <div role="button"> au lieu de <button> casse l'arbre d'accessibilité parce que le div n'a pas le comportement clavier du bouton natif. La règle générale : utilisez du HTML sémantique natif avant d'ajouter de l'ARIA. ARIA est pour les cas que le HTML ne couvre pas, pas pour décorer du HTML existant.

Erreur 4 : modifier le markup sans re-tester avec NVDA

Chaque changement de HTML qui affecte la structure, les rôles, les landmarks ou l'ordre des éléments peut modifier l'expérience dans le lecteur d'écran de façon non évidente. Un changement qui améliore le score axe peut dégrader la navigation réelle. Re-testez avec NVDA ou VoiceOver chaque fois que vous modifiez la structure sémantique d'une page, pas seulement quand vous faites des changements spécifiques d'accessibilité.

Erreur 5 : corriger sans comprendre le critère

« Ajoutez aria-label aux boutons » est une instruction qui peut être interprétée littéralement et appliquée en excès. Si un bouton a déjà un texte visible descriptif, ajouter un aria-label peut le contredire et perturber le lecteur d'écran (le critère 2.5.3 — Étiquette dans le nom — exige que l'aria-label contienne le texte visible). Avant d'appliquer une correction, lisez le critère WCAG qui justifie le changement dans la spec officielle du W3C.

Questions fréquentes

Le niveau AA suffit-il ou faut-il AAA ?

L'EAA exige WCAG 2.2 niveau AA. Le niveau AAA n'est pas obligatoire par la loi. Cela dit, certains critères AAA sont très simples à implémenter et offrent des améliorations significatives pour certains groupes d'utilisateurs (comme le critère 2.4.12 — Apparence du focus — qui exige une meilleure visibilité du focus). Si vous atteignez AA sans effort supplémentaire, vérifiez si certains critères AAA spécifiques sont pertinents pour votre audience. Mais ne faites pas du AAA un objectif de conformité réglementaire — ce n'est pas le cas.

Que faire si j'ai un widget tiers qui n'est pas conforme ?

C'est l'un des scénarios les plus courants et les plus délicats. Si le widget est dans un parcours critique (chat de support, passerelle de paiement, formulaire d'inscription), vous avez trois options : le remplacer par un widget accessible, fournir une alternative accessible équivalente, ou le documenter comme exception temporaire avec une date de résolution. Ce que vous ne pouvez pas faire, c'est l'ignorer — la loi vous rend responsable de l'expérience complète que vous offrez à l'utilisateur, y compris les composants que vous ne contrôlez pas directement. Si le fournisseur du widget n'a pas de roadmap d'accessibilité, c'est un critère de sélection du fournisseur.

Combien coûte un audit professionnel d'accessibilité ?

Un audit professionnel indépendant — celui qui génère un rapport formel avec valeur légale pour présenter au régulateur — oscille généralement entre 3 000 et 15 000 euros pour un site de taille moyenne, selon le nombre de pages, la complexité des interactions et l'inclusion ou non de tests avec de vrais utilisateurs en situation de handicap.

L'audit de 2 heures décrit dans ce post n'est pas équivalent à un audit professionnel. C'est un diagnostic de haut niveau qui vous permet de savoir où vous en êtes et de prioriser. Il sert de base pour la remédiation interne. Si vous avez besoin du rapport formel pour le présenter au régulateur ou dans un contexte légal, vous avez besoin d'un audit professionnel. Chez Kiwop, nous réalisons des audits formels d'accessibilité — si vous en êtes à ce stade, parlons-en.

L'audit doit-il être répété ?

Oui, et à deux niveaux. Le niveau automatique (axe dans la CI) doit s'exécuter à chaque PR qui modifie des composants UI. Le niveau complet (automatisation + révision manuelle avec lecteurs d'écran + révision des parcours) doit être répété au moins une fois par an et à chaque changement significatif de design, nouvelles fonctionnalités principales, ou changement de technologie de rendu.

L'accessibilité n'est pas un état que l'on atteint et qui se maintient seul. C'est un processus continu — exactement comme la performance ou la sécurité.

Mes PDFs ou documents doivent-ils également être conformes ?

Oui. L'EAA ne s'applique pas uniquement au HTML. Les documents téléchargeables (PDF, Word, Excel) qui font partie d'un service numérique doivent aussi être accessibles s'ils contiennent des informations pertinentes pour l'utilisateur. Les PDFs accessibles nécessitent une structure d'en-têtes, un ordre de lecture correct, du texte alt sur les images, et du vrai texte (pas une image scannée). Outils : PAC 2024 (PDF Accessibility Checker, gratuit) et le vérificateur d'accessibilité intégré dans Adobe Acrobat. Si votre site propose de la documentation, des contrats, des factures ou des formulaires en PDF, incluez-les dans l'audit.

Conclusion : la conformité est un processus, pas un événement

S'il y a une leçon qui résume tout ce qui précède, c'est celle-ci : l'accessibilité se maintient comme le logiciel — avec des tests automatisés qui détectent les régressions, des révisions périodiques qui valident ce que l'automatisation ne voit pas, et une documentation qui démontre la diligence.

La deadline de l'EAA est passée. Vous ne pouvez pas effacer cela. Ce que vous pouvez faire, c'est commencer aujourd'hui, avec le stack que vous avez, en 2 heures, et construire à partir de là. Un audit imparfait fait aujourd'hui est infiniment plus précieux qu'un audit parfait qui n'est jamais exécuté.

Le chemin est : diagnostic (ce post) → remédiation priorisée → intégration dans la CI → audit formel si votre exposition légale le requiert.

Si à un moment du chemin vous avez besoin d'un soutien externe — un audit formel, une remédiation complexe, ou intégrer l'accessibilité dans le processus de Développement Logiciel de votre équipe dès le début — c'est exactement ce que nous faisons chez Kiwop. Dites-nous où vous en êtes et nous vous indiquons par où commencer.