Audit complet — WCAG 2.1 et 2.2 AA · EN 301 549
Rapport d’audit d’accessibilité web
Ce rapport consigne chaque barrière d’accessibilité trouvée sur le site indiqué ci-dessous, ce qu’elle fait à un client réel et comment la corriger précisément. Il est écrit pour être remis tel quel à votre développeur.
Site audité
shop.demostore-example.com
Titulaire du site
Demo Store S.L. (exemple)
Période d’audit
24–27 juin 2026
Auditeur
EAA Comply · eaacompliance.com
Périmètre
15 pages testées à la main sur 6 gabarits (accueil, catégorie, produit, panier, commande, compte) ; 41 pages parcourues avec axe-core
Testé sur
Bureau 1280 px et mobile 390 px · NVDA et VoiceOver · clavier seul · zoom 200 %
Résumé pour la direction
shop.demostore-example.com n’atteint pas aujourd’hui le niveau AA. Nous avons trouvé 37 problèmes distincts sur les six gabarits du périmètre. Six sont critiques, ce qui signifie dans ce rapport qu’un client au clavier ou au lecteur d’écran ne peut pas les franchir sans aide.
Trois de ces six se trouvent directement sur le chemin de la vente. Le bandeau cookies ne peut pas être fermé au clavier : un visiteur sans souris n’entre donc jamais dans la boutique. Les commandes du panier et de quantité ne sont annoncées que comme « bouton », si bien qu’un utilisateur de lecteur d’écran ne distingue pas « supprimer l’article » de « en ajouter un ». Et quand la commande refuse une adresse, rien n’est annoncé : le formulaire semble simplement ne pas répondre.
Rien de tout cela n’exige une refonte. La liste complète des corrections représente environ 11 à 15 heures de développement, et l’essentiel relève du balisage : étiquettes, noms accessibles, gestion du focus et quatre valeurs de couleur. Le design visuel ne change pas.
Corriger ces 37 problèmes amène le périmètre audité au niveau AA à la date du contre-test. Cela ne rend pas le site conforme pour toujours : l’accessibilité se casse de nouveau à la prochaine mise à jour du thème ou au prochain lot de photos produit. C’est à cela que sert la revérification mensuelle.
Synthèse des résultats
Pas AA
Niveau de conformité atteint
61/100
Score d’accessibilité
Le score est un indice propre à EAA Comply, qui pondère la gravité, la fréquence et l’endroit du parcours d’achat où chaque problème se situe. Il sert à mesurer les progrès d’un audit à l’autre. Ce n’est pas une mesure normalisée : WCAG n’a pas de score, seulement conforme ou non conforme, critère par critère.
Problèmes par gravité
| Gravité | Nombre | Ce que cela veut dire ici |
|---|
| Critique | 6 | Bloque purement et simplement une tâche pour au moins un groupe d’utilisateurs. L’achat ne peut pas aboutir. |
| Grave | 14 | La tâche reste réalisable, mais au prix de difficultés, de suppositions ou d’une aide extérieure. |
| Modéré | 12 | Nettement plus difficile ou plus confus ; la plupart des gens finissent par y arriver. |
| Mineur | 5 | Ne bloque rien, mais échoue à un critère et mérite d’être nettoyé. |
Conformité par critère de succès (extrait)
| WCAG | Critère de succès | Niveau | Résultat |
|---|
| 1.1.1 | Contenu non textuel (texte alternatif) | A | Non conforme |
| 1.3.1 | Information et relations | A | Non conforme |
| 1.3.5 | Identifier la finalité de la saisie | AA | Non conforme |
| 1.4.1 | Utilisation de la couleur | A | Non conforme |
| 1.4.3 | Contraste (minimum) 4,5:1 | AA | Non conforme |
| 1.4.10 | Redistribution à 320 px | AA | Conforme |
| 1.4.11 | Contraste du contenu non textuel (commandes) | AA | Non conforme |
| 2.1.1 | Utilisation au clavier | A | Non conforme |
| 2.1.2 | Pas de piège au clavier | A | Non conforme |
| 2.4.1 | Contourner des blocs (lien d’évitement) | A | Non conforme |
| 2.4.7 | Visibilité du focus | AA | Conforme |
| 2.5.8 | Taille de la cible (minimum) | AA | Non conforme |
| 3.3.1 | Identification des erreurs | A | Non conforme |
| 3.3.2 | Étiquettes ou instructions | A | Non conforme |
| 4.1.2 | Nom, rôle et valeur | A | Non conforme |
| 4.1.3 | Messages d’état | AA | Non conforme |
Le rapport livré couvre les 56 critères de niveau A et AA de WCAG 2.1 et 2.2, chacun avec les preuves qui fondent le verdict, et signale comme non applicables ceux pour lesquels le site n’a pas de contenu concerné. Ceci est un extrait représentatif.
Le plan de correction, dans l’ordre où nous le mènerions
| Ordre | Problème | Charge |
|---|
| 1 | Critique F-01 — Le bandeau cookies ne peut pas être fermé au clavier | 2-3 h |
| 2 | Critique F-02 — Les boutons à icône seule n’ont pas de nom accessible | 1 h |
| 3 | Critique F-03 — Les champs de commande utilisent des textes indicatifs au lieu d’étiquettes | 2 h |
| 4 | Grave F-04 — Les erreurs de validation sont affichées mais jamais annoncées | 2 h |
| 5 | Grave F-05 — Les prix et les liens de pied de page passent sous le contraste minimal | 1 h |
| 6 | Grave F-06 — Les images produit portent le nom de fichier comme texte alternatif | 3 h |
| 7 | Les 31 problèmes restants (modérés et mineurs) | 5–7 h |
Classé par impact client rapporté à la charge de travail, et non par gravité seule. F-02 représente une heure de travail qui débloque douze commandes : il passe donc devant des éléments plus lents de même gravité.
Les constats en détail
Six des 37 constats sont reproduits ci-dessous dans le format qu’emploie le rapport complet. Chaque problème est documenté ainsi, et l’offre « Corrections guidées » ajoute le code corrigé écrit pour votre technologie.
Le bandeau cookies ne peut pas être fermé au clavier
F-01 CritiqueWCAG: 2.1.2 · 2.4.3Niveau: ARègle axe-core: non détectable automatiquementOccurrences: 41Charge: 2-3 h
Où
Les 41 pages — le bandeau de consentement affiché à la première visite.
Qui est concerné
Toute personne qui navigue sans souris : utilisateurs au clavier seul, au lecteur d’écran, au contacteur ou à la commande vocale.
Pourquoi c’est non conforme
Le bandeau est un <div> avec tabindex="-1" et la commande « Accepter » est un <span> muni d’un gestionnaire de clic : elle n’est donc ni focusable ni annoncée comme un bouton. La surcouche recouvre la page, mais la tabulation continue de parcourir le contenu situé derrière et n’atteint jamais « Accepter ». Un utilisateur à la souris clique une fois et passe à autre chose ; un utilisateur au clavier ne peut pas fermer le bandeau et n’entre pas du tout dans la boutique. Cela échoue au critère 2.1.2 Pas de piège au clavier et, puisque l’ordre de focus ne suit plus l’ordre visible, au critère 2.4.3 Parcours du focus.
Trouvé sur le site
<div class="cc-bar" tabindex="-1">
<span class="cc-ok" onclick="acceptAll()">Accept</span>
</div>
Comment le corriger
<div class="cc-bar" role="dialog" aria-modal="true"
aria-labelledby="cc-title">
<h2 id="cc-title">Cookies</h2>
<button type="button" class="cc-ok">Accept</button>
<button type="button" class="cc-no">Reject non-essential</button>
</div>
Les boutons à icône seule n’ont pas de nom accessible
F-02 CritiqueWCAG: 4.1.2 · 1.1.1Niveau: ARègle axe-core: button-nameOccurrences: 12Charge: 1 h
Où
Le panier et la recherche dans l’en-tête, la commande « favoris » sur chaque carte produit, et les compteurs de quantité des gabarits panier et produit — 12 commandes.
Qui est concerné
Les utilisateurs de lecteurs d’écran, et les utilisateurs de commande vocale, qui n’ont aucun nom à prononcer.
Pourquoi c’est non conforme
Chaque bouton ne contient qu’une icône SVG, sans texte ni étiquette : il est annoncé « bouton » et rien d’autre. Sur la page panier, quatre d’entre eux se suivent : augmenter, diminuer, mettre de côté, supprimer. Deviner lequel est lequel, c’est deviner si la commande est sur le point d’être vidée.
Trouvé sur le site
<button class="qty-up">
<svg viewBox="0 0 16 16">...</svg>
</button>
Comment le corriger
<button type="button" class="qty-up" aria-label="Increase quantity">
<svg viewBox="0 0 16 16" aria-hidden="true" focusable="false">...</svg>
</button>
Les champs de commande utilisent des textes indicatifs au lieu d’étiquettes
F-03 CritiqueWCAG: 3.3.2 · 1.3.1 · 1.3.5Niveau: A / AARègle axe-core: labelOccurrences: 9Charge: 2 h
Où
Étape 1 de la commande (adresse de livraison) et étape 2 (paiement) — 9 champs.
Qui est concerné
Les utilisateurs de lecteurs d’écran, les personnes ayant un handicap cognitif, et toute personne interrompue au milieu d’un long formulaire.
Pourquoi c’est non conforme
Les champs ont un placeholder et aucun <label>. Un texte indicatif n’est pas une étiquette : il disparaît dès que le champ contient quelque chose, si bien qu’une personne qui détourne le regard ne voit plus à quoi servait le champ, et il est annoncé de façon inconstante selon les lecteurs d’écran. Le gris du texte indicatif (#9aa4b2 sur blanc) n’est par ailleurs qu’à 2,52:1, bien en dessous du minimum de 4,5:1.
Trouvé sur le site
<input type="text" name="postcode" placeholder="Postcode">
Comment le corriger
<label for="ship-post">Postcode</label>
<input type="text" id="ship-post" name="postcode"
autocomplete="postal-code">
Les erreurs de validation sont affichées mais jamais annoncées
F-04 GraveWCAG: 3.3.1 · 4.1.3 · 1.4.1Niveau: A / AARègle axe-core: non détectable automatiquementOccurrences: 6Charge: 2 h
Où
La commande, l’inscription à la newsletter et le formulaire de contact — 6 formulaires.
Qui est concerné
Les utilisateurs de lecteurs d’écran avant tout, et toute personne qui ne remarque pas un changement de couleur.
Pourquoi c’est non conforme
Le texte d’erreur est écrit dans un <div class="err"> dépourvu de rôle, et le champ n’est signalé que par une bordure rouge. Un utilisateur de lecteur d’écran appuie sur « Envoyer », n’entend rien, et n’a aucun moyen de savoir que le formulaire n’est pas passé. Signaler le champ par la seule couleur échoue en outre au critère 1.4.1 Utilisation de la couleur.
Trouvé sur le site
<div class="err"></div>
<input type="email" id="mail" class="is-error">
Comment le corriger
<input type="email" id="mail" aria-invalid="true"
aria-describedby="mail-err">
<div id="mail-err" class="err" role="alert">
Email address: enter an address in the form name@example.com.
</div>
Les prix et les liens de pied de page passent sous le contraste minimal
F-05 GraveWCAG: 1.4.3Niveau: AARègle axe-core: color-contrastOccurrences: 23Charge: 1 h
Où
Les cartes produit, le bloc prix des pages produit, la pastille promotion et les liens du pied de page — 23 éléments.
Qui est concerné
Les personnes malvoyantes, et tout le monde devant un écran de téléphone en extérieur.
Pourquoi c’est non conforme
Le prix promotionnel est en #e05c5c sur blanc, soit un rapport de 3,59:1, et les liens du pied de page en #8b95a5 sur #f6f9fc, soit 2,86:1. Le niveau AA exige 4,5:1 pour du texte de taille normale. Le prix promotionnel est précisément le chiffre que le client est venu lire.
Trouvé sur le site
.price--sale { color: #e05c5c; } /* 3.59:1 on white */
.site-foot a { color: #8b95a5; } /* 2.86:1 on #f6f9fc */
Comment le corriger
.price--sale { color: #c0392b; } /* 5.44:1 on white */
.site-foot a { color: #5a6678; } /* 5.51:1 on #f6f9fc */
Les images produit portent le nom de fichier comme texte alternatif
F-06 GraveWCAG: 1.1.1Niveau: ARègle axe-core: non détectable automatiquementOccurrences: 38Charge: 3 h
Où
38 images produit dans les gabarits catégorie et produit.
Qui est concerné
Les utilisateurs de lecteurs d’écran, et toute personne dont les images ne se chargent pas.
Pourquoi c’est non conforme
Le texte alternatif est le nom du fichier : alt="product-img-04.jpg". C’est le constat le plus instructif du rapport, car axe-core l’enregistre comme conforme — la règle vérifie qu’un attribut alt existe et n’est pas vide, et c’est le cas. Seul un humain qui lit le résultat remarque qu’on ne dit absolument rien au client sur le produit qu’il envisage d’acheter.
Trouvé sur le site
<img src="/img/product-img-04.jpg" alt="product-img-04.jpg">
Comment le corriger
<img src="/img/product-img-04.jpg"
alt="Navy wool scarf, folded, showing the ribbed weave">
À propos de l’overlay d’accessibilité installé sur cette boutique
La boutique a un widget overlay installé. Nous avons mené l’audit complet deux fois, une fois avec le widget actif et une fois avec le widget désactivé : les 37 problèmes sont identiques dans les deux passages, le widget n’en a corrigé aucun. Il en a même ajouté un, car son propre bouton d’ouverture n’a pas de nom accessible et il est compté dans F-02 ci-dessus. Ce n’est pas une critique de la décision de l’installer ; c’est ce que les tests ont montré.
Ce que les tests automatiques ont trouvé, et ce qu’ils n’ont pas trouvé
axe-core a trouvé 14 des 37 problèmes. Les 23 autres viennent de tests menés à la main, au lecteur d’écran et au clavier. Cette proportion est normale, et c’est la raison pour laquelle un scan n’est pas un audit : les règles automatiques sont bonnes sur ce qu’une machine peut mesurer — un attribut manquant, un rapport de contraste, un id en double — et aveugles à la question de savoir si un nom veut dire quelque chose, si le focus peut sortir d’une boîte de dialogue, ou si un message d’erreur aide vraiment. F-01 et F-06 en sont ici les exemples les plus nets : l’un est invisible pour le scanner, l’autre y est enregistré comme conforme.
Périmètre, limites et ce que nous n’avons pas testé
- •L’étape de paiement est une iframe hébergée par le prestataire de paiement de la boutique. Nous avons vérifié que le focus y entre et en sort correctement ; son balisage interne appartient au prestataire et la boutique ne peut pas le modifier.
- •Les factures PDF et les deux vidéos marketing sont hors du périmètre de ce rapport. Les deux relèvent de l’EAA et peuvent être chiffrées séparément.
- •Les constats décrivent le site tel qu’il était entre le 24 et le 27 juin 2026. Les mises à jour de thème, les nouveaux plugins et les nouveaux contenus produit peuvent réintroduire des problèmes après cette date.
- •Il s’agit d’une évaluation technique, pas d’un conseil juridique. EAA Comply est un service d’audit indépendant, ni une autorité publique ni un organisme de certification.
La suite
- →Votre développeur déroule le plan de correction. Tout relève du balisage, du CSS et de la gestion du focus — rien ici n’exige une refonte.
- →Vous nous prévenez quand c’est fait et nous retestons le même périmètre. Le contre-test est inclus.
- →Une fois le périmètre conforme, les offres payantes délivrent le certificat technique de conformité. Pour cette boutique fictive, c’est le certificat d’exemple EAAC-2026-0428-17A, qui est l’autre moitié de cet exemple.
- →Votre déclaration d’accessibilité est rédigée à partir de ces constats et mise à jour à chaque contre-test. Un extrait du brouillon figure ci-dessous.
Voir le certificat d’exemple correspondant →
Votre déclaration d’accessibilité (extrait du brouillon)
Engagement. Demo Store S.L. s’engage à rendre shop.demostore-example.com accessible conformément à la directive (UE) 2019/882 et à la norme harmonisée EN 301 549.
État de conformité. Ce site web est partiellement conforme à WCAG 2.1 niveau AA. « Partiellement conforme » signifie que certaines parties du contenu ne respectent pas totalement la norme d’accessibilité.
Contenus non accessibles. Le bandeau de consentement ne peut pas être utilisé au clavier (WCAG 2.1.2). Plusieurs commandes n’ont pas de nom accessible (WCAG 4.1.2). Les erreurs de formulaire ne sont pas annoncées (WCAG 4.1.3). Résolution prévue : 31 juillet 2026.
Retour d’information. Si vous rencontrez une barrière sur ce site, écrivez à accessibilite@demostore-example.com. Nous répondons sous 10 jours ouvrés.
La déclaration livrée est complète, datée et prête à publier ; cet extrait montre les parties qui sortent de l’audit. Elle dit « partiellement conforme » parce que, le jour de l’audit, c’était exact. Elle est réécrite au contre-test.
Document d’exemple. shop.demostore-example.com, Demo Store S.L. ainsi que tous les constats, chiffres et dates de ce rapport sont fictifs et n’existent que pour montrer le format du rapport livré par EAA Comply. Aucun client, site ou audit réel n’est représenté. EAA Comply est un service technique d’audit indépendant, ni une autorité publique ni un organisme de certification. Un vrai rapport est produit sur votre code en production et son contenu sera différent.