EAA ComplyEAA Comply · Accessibility & compliance
Rapport n°EAAC-2026-0624-17AÉmis le 27 juin 2026EXEMPLE — DONNÉES FICTIVES

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
Rapport émis
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é
37
Problèmes trouvés
6
Problèmes critiques

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éNombreCe que cela veut dire ici
Critique6Bloque purement et simplement une tâche pour au moins un groupe d’utilisateurs. L’achat ne peut pas aboutir.
Grave14La tâche reste réalisable, mais au prix de difficultés, de suppositions ou d’une aide extérieure.
Modéré12Nettement plus difficile ou plus confus ; la plupart des gens finissent par y arriver.
Mineur5Ne bloque rien, mais échoue à un critère et mérite d’être nettoyé.

Conformité par critère de succès (extrait)

WCAGCritère de succèsNiveauRésultat
1.1.1Contenu non textuel (texte alternatif)ANon conforme
1.3.1Information et relationsANon conforme
1.3.5Identifier la finalité de la saisieAANon conforme
1.4.1Utilisation de la couleurANon conforme
1.4.3Contraste (minimum) 4,5:1AANon conforme
1.4.10Redistribution à 320 pxAAConforme
1.4.11Contraste du contenu non textuel (commandes)AANon conforme
2.1.1Utilisation au clavierANon conforme
2.1.2Pas de piège au clavierANon conforme
2.4.1Contourner des blocs (lien d’évitement)ANon conforme
2.4.7Visibilité du focusAAConforme
2.5.8Taille de la cible (minimum)AANon conforme
3.3.1Identification des erreursANon conforme
3.3.2Étiquettes ou instructionsANon conforme
4.1.2Nom, rôle et valeurANon conforme
4.1.3Messages d’étatAANon 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

OrdreProblèmeCharge
1Critique F-01 — Le bandeau cookies ne peut pas être fermé au clavier2-3 h
2Critique F-02 — Les boutons à icône seule n’ont pas de nom accessible1 h
3Critique F-03 — Les champs de commande utilisent des textes indicatifs au lieu d’étiquettes2 h
4Grave F-04 — Les erreurs de validation sont affichées mais jamais annoncées2 h
5Grave F-05 — Les prix et les liens de pied de page passent sous le contraste minimal1 h
6Grave F-06 — Les images produit portent le nom de fichier comme texte alternatif3 h
7Les 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 Critique
WCAG: 2.1.2 · 2.4.3Niveau: ARègle axe-core: non détectable automatiquementOccurrences: 41Charge: 2-3 h

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 Critique
WCAG: 4.1.2 · 1.1.1Niveau: ARègle axe-core: button-nameOccurrences: 12Charge: 1 h

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 Critique
WCAG: 3.3.2 · 1.3.1 · 1.3.5Niveau: A / AARègle axe-core: labelOccurrences: 9Charge: 2 h

É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 Grave
WCAG: 3.3.1 · 4.1.3 · 1.4.1Niveau: A / AARègle axe-core: non détectable automatiquementOccurrences: 6Charge: 2 h

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 Grave
WCAG: 1.4.3Niveau: AARègle axe-core: color-contrastOccurrences: 23Charge: 1 h

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 Grave
WCAG: 1.1.1Niveau: ARègle axe-core: non détectable automatiquementOccurrences: 38Charge: 3 h

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é

La suite

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.

© 2026 EAA Comply — ← Retour à eaacompliance.com · hello@eaacompliance.com