Blog

Best Practices

Top 10 violations EAA sur les sites européens — et comment les corriger en une après-midi

Dix erreurs WCAG 2.1 AA présentes sur la majorité des sites EU, avec des correctifs prêts à l'emploi. Résolvez ces problèmes et vous couvrez la majorité des manquements EAA détectables automatiquement.

8 mai 2026

Updated 15 May 2026

14 min read

Ravid, Webply

Also in:

ENDENL

FR

Comment nous les avons classés

L'ordre est basé sur la prévalence × le risque juridique, et non sur la fréquence brute. Une violation présente partout mais rarement citée (ex. : sauts de titres mineurs) se classe moins bien que quelque chose de moins courant mais régulièrement mentionné dans des plaintes (ex. : champs de formulaire sans libellé sur une page de paiement).

Pour chaque point, vous obtenez :

• Le critère WCAG 2.1 AA qu'il ne respecte pas
• La règle axe-core qui le détecte
• Pourquoi cela vous vaut une plainte
• Le correctif, avec le code

C'est parti.

1. Texte alternatif manquant sur les images significatives

WCAG : 1.1.1 Contenu non textuel (Niveau A) · Règle axe : image-alt

C'est le manquement le plus souvent cité dans les audits WCAG et le plus facile à corriger.

L'erreur que presque tout le monde commet : omettre l'attribut alt sur une image décorative, puis l'omettre aussi sur une image significative. Les lecteurs d'écran n'annoncent alors rien pour l'image significative — et l'utilisateur ne sait pas qu'il y a une photo de produit, un graphique ou un CAPTCHA.

<!-- ❌ Mauvais : image significative sans alt -->
<img src="/products/red-chair.jpg">

<!-- ✅ Bon : image significative, alt descriptif -->
<img src="/products/red-chair.jpg" alt="Fauteuil en cuir rouge, style mi-siècle, vue de côté">

<!-- ✅ Bon : image décorative, alt vide est correct -->
<img src="/decorative/swoosh.png" alt="">

Nuance importante : alt="" est la bonne réponse pour les images vraiment décoratives. Ce n'est pas la bonne réponse quand vous ne savez pas quoi écrire. Une description manquante sur une image produit vous vaudra une plainte ; un alt vide sur une décoration est le bon choix selon les spécifications.

2. Contraste texte/arrière-plan insuffisant

WCAG : 1.4.3 Contraste (Minimum) (Niveau AA) · Règle axe : color-contrast

Vous avez besoin d'un rapport de contraste d'au moins 4,5:1 pour le texte normal et 3:1 pour le grand texte (≥18pt ou ≥14pt gras). C'est le manquement AA le plus courant sur les pages d'accueil — texte gris clair sur fond blanc, boutons de couleur marque qui ne passent pas contre l'arrière-plan.

Comment vérifier rapidement : collez votre code hexadécimal de premier plan/arrière-plan dans le vérificateur de contraste de WebAIM ou les outils de développement de votre navigateur (Inspecter → onglet Accessibilité dans Chrome/Firefox).

/* ❌ Mauvais : rapport 2,6:1, échoue AA */
.muted { color: #aaaaaa; background: #ffffff; }

/* ✅ Bon : rapport 4,6:1, réussit AA */
.muted { color: #767676; background: #ffffff; }

/* ✅ Bon pour les espaces réservés et états désactivés (toujours lisible) */
.disabled { color: #595959; background: #ffffff; } /* 7:1 */

Remarque contradictoire : de nombreux systèmes de design (Material, Apple HIG, valeurs par défaut Tailwind) livrent gray-300 et gray-400 comme couleurs de texte courantes sur blanc. Toutes deux échouent AA. Auditez vos jetons de design une fois, pas vos pages.

3. Champs de formulaire sans libellés programmatiques

WCAG : 1.3.1 Information et relations (Niveau A), 4.1.2 Nom, rôle, valeur (Niveau A) · Règle axe : label

C'est la violation au plus haut risque juridique sur les sites e-commerce. Un formulaire de paiement où les lecteurs d'écran ne peuvent pas annoncer « E-mail », « Code postal », « CVV » — c'est ce type de manquement qui a déclenché les premières actions en application françaises en novembre 2025 contre Carrefour, Auchan, E.Leclerc et Picard (voir le régime de sanctions en France).

<!-- ❌ Mauvais : placeholder visuel, pas de libellé -->
<input type="email" placeholder="Adresse e-mail">

<!-- ❌ Mauvais : libellé non associé -->
<label>E-mail</label>
<input type="email">

<!-- ✅ Bon : association de libellé explicite -->
<label for="email">E-mail</label>
<input id="email" type="email">

<!-- ✅ Bon : aria-label quand le libellé visuel n'est pas possible (ex. icône seule) -->
<input type="search" aria-label="Rechercher des produits">

<!-- ✅ Bon : aria-labelledby pointant vers du texte visible existant -->
<span id="zip-label">Code postal</span>
<input aria-labelledby="zip-label">

placeholder n'est jamais un substitut à un libellé. Il disparaît quand l'utilisateur commence à taper.

4. Lien « Passer au contenu » manquant

WCAG : 2.4.1 Contournement de blocs (Niveau A) · Règle axe : skip-link

Les utilisateurs en navigation au clavier uniquement et aux lecteurs d'écran doivent passer par chaque lien de navigation avant d'atteindre le contenu principal — sur chaque page. Un lien de saut leur permet de l'éviter.

<!-- Placez ceci comme tout premier élément focalisable dans <body> -->
<a href="#main" class="skip-link">Passer au contenu principal</a>
<!-- ... -->
<main id="main">...</main>

/* Masquer visuellement jusqu'au focus — n'utilisez jamais display:none -->
.skip-link {
  position: absolute;
  left: -9999px;
  top: 0;
}
.skip-link:focus {
  left: 0;
  background: #000;
  color: #fff;
  padding: 0.75rem 1rem;
  z-index: 9999;
}

Si vous utilisez Next.js / Nuxt / SvelteKit, c'est un composant importé dans votre layout racine. Cinq minutes pour corriger l'une des violations les plus signalées.

5. Liens et boutons vides

WCAG : 2.4.4 Fonction du lien (Niveau A), 4.1.2 Nom, rôle, valeur (Niveau A) · Règles axe : link-name, button-name

Les boutons et liens avec icône uniquement — le menu hamburger, l'icône de recherche, le × de fermeture sur les modales — sont fréquemment livrés sans nom accessible. Les lecteurs d'écran annoncent « bouton » sans aucune indication sur son action.

<!-- ❌ Mauvais : bouton icône, pas de nom -->
<button><svg>...</svg></button>

<!-- ✅ Bon : aria-label fournit le nom -->
<button aria-label="Ouvrir le menu de navigation">
  <svg aria-hidden="true">...</svg>
</button>

<!-- ✅ Bon : texte masqué visuellement pour les lecteurs d'écran -->
<button>
  <svg aria-hidden="true">...</svg>
  <span class="sr-only">Ouvrir le menu de navigation</span>
</button>

aria-hidden="true" sur le SVG est important — sans lui, le lecteur d'écran peut annoncer à la fois le SVG (souvent comme « graphique ») et le libellé, ce qui est bruyant.

6. Attribut de langue manquant sur <html>

WCAG : 3.1.1 Langue de la page (Niveau A) · Règle axe : html-has-lang

Sans lang, les lecteurs d'écran ne savent pas quelles règles de prononciation utiliser — le contenu français est lu avec la phonétique anglaise, l'allemand en français, et le résultat est incompréhensible.

<!-- ❌ Mauvais -->
<html>

<!-- ✅ Bon -->
<html lang="fr">

<!-- ✅ Bon pour le contenu multilingue avec une langue principale -->
<html lang="fr">
  <body>
    <p>Le terme anglais <span lang="en">"deadline"</span> est très utilisé.</p>
  </body>
</html>

C'est un seul attribut. Il n'y a aucune excuse pour l'avoir manqué.

7. Hiérarchie de titres brisée

WCAG : 1.3.1 Information et relations (Niveau A) · Règle axe : heading-order

Les utilisateurs de lecteurs d'écran naviguent par les titres — « titre suivant » est l'une des commandes les plus utilisées. Si votre page a un h1, puis passe directement à h4 en sautant h2 et h3, la hiérarchie est brisée et la navigation échoue.

<!-- ❌ Mauvais : h1 → h4 → h2 -->
<h1>Titre de page</h1>
<h4>Sous-section</h4>
<h2>Autre section</h2>

<!-- ✅ Bon : monotonique, sans niveaux sautés -->
<h1>Titre de page</h1>
<h2>Section</h2>
<h3>Sous-section</h3>
<h2>Section suivante</h2>

Une cause fréquente est l'utilisation des niveaux de titre pour le style visuel. Ne faites pas ça. Utilisez le niveau correct pour la structure, puis stylisez avec CSS.

8. Éléments interactifs inaccessibles au clavier

WCAG : 2.1.1 Clavier (Niveau A) · Règle axe : keyboard (vérifications manuelles et automatisées)

Chaque élément cliquable doit être accessible et opérable uniquement au clavier. L'échec le plus courant : utiliser <div onclick=...> au lieu de <button>.

<!-- ❌ Mauvais : non focalisable au clavier, non annoncé comme bouton -->
<div class="btn" onclick="doThing()">Cliquez ici</div>

<!-- ✅ Bon : la sémantique native donne clavier + lecteur d'écran gratuitement -->
<button type="button" onclick="doThing()">Cliquez ici</button>

<!-- ✅ Bon : si vous devez absolument utiliser un div, ajoutez tout ceci -->
<div
  role="button"
  tabindex="0"
  onclick="doThing()"
  onkeydown="if(event.key==='Enter'||event.key===' '){doThing()}"
>
  Cliquez ici
</div>

La troisième option est presque toujours mauvaise. Utilisez un <button>. L'élément sémantique gagne sur tous les critères — accessibilité, clavier, styles de focus, annonce par lecteur d'écran, remplissage automatique du navigateur.

9. Modales sans gestion du focus

WCAG : 2.4.3 Ordre du focus (Niveau A), 2.1.2 Pas de piège au clavier (Niveau A) · automatisation partielle, surtout manuelle

Une modale qui ne piège pas le focus est une cause fréquente du problème « j'ai ouvert la modale et je n'ai pas pu en sortir ». Quand une modale s'ouvre, le focus doit y être déplacé ; pendant qu'elle est ouverte, Tab doit cycler à l'intérieur ; à la fermeture, le focus retourne sur l'élément déclencheur.

La bonne façon en 2026 est l'élément natif <dialog> :

<!-- ✅ Bon : dialog natif avec showModal() gère le piège de focus automatiquement -->
<button type="button" onclick="document.getElementById('confirm-dialog').showModal()">
  Supprimer le compte
</button>

<dialog id="confirm-dialog" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Confirmer la suppression</h2>
  <p>Cette action est irréversible.</p>
  <form method="dialog">
    <button value="cancel">Annuler</button>
    <button value="confirm">Supprimer</button>
  </form>
</dialog>

Pour les bibliothèques de composants React/Vue/Svelte, vérifiez que votre composant modale prend en charge aria-modal, le piège de focus et la fermeture par ESC. Les plus populaires (Radix UI, Headless UI, Mantine Modal, MUI Dialog) le font — mais les modales personnalisées ou les widgets tiers plus anciens souvent non.

10. Bandeaux de cookies qui bloquent tout

WCAG : 2.1.1 Clavier (Niveau A), 1.4.13 Contenu au survol ou au focus (Niveau AA), 4.1.2 · automatisation partielle

C'est la violation la plus visible par les utilisateurs sur les sites européens, car le RGPD a imposé des bandeaux de cookies sur chaque site, et la plupart de ces implémentations sont des désastres en matière d'accessibilité :

• L'ordre de tabulation piège l'utilisateur dans le bandeau indéfiniment
• Les boutons sont sans libellé ou avec un texte vague (« Tout accepter » sans contexte)
• Le bandeau superpose le contenu principal mais ne porte pas le rôle approprié / aria-modal
• Les utilisateurs de lecteurs d'écran ne peuvent pas le fermer

Le correctif :

<!-- ✅ Bon : rôle dialog, nom accessible, gestion du focus -->
<div role="dialog" aria-modal="true" aria-labelledby="cookie-title">
  <h2 id="cookie-title">Consentement aux cookies</h2>
  <p>Nous utilisons des cookies pour les analyses. Vous pouvez tout accepter, refuser les non essentiels, ou personnaliser.</p>
  <button>Tout accepter</button>
  <button>Refuser les non essentiels</button>
  <button>Personnaliser</button>
</div>

Si vous utilisez une CMP (Plateforme de gestion du consentement) comme Cookiebot, OneTrust ou Iubenda — vérifiez qu'elles respectent WCAG. La plupart des grandes le font dans leur configuration par défaut ; de nombreux bandeaux auto-construits non. L'un des problèmes les plus fréquents en France fin 2025 concernait précisément des bandeaux de cookies inaccessibles.

Et les 30 % restants ?

Les dix points ci-dessus sont détectables par des outils automatisés. Environ 30 % des manquements WCAG ne peuvent pas être automatisés de manière fiable :

• Si alt="Photo du PDG" est une description pertinente (contre alt="Anna Müller, PDG, souriant à la caméra")
• Si les titres décrivent logiquement leurs sections
• Si l'ordre de lecture est cohérent
• Si le contenu est compréhensible en langage simple
• Si les formulaires récupèrent correctement les erreurs

Ces points nécessitent soit (1) un audit manuel par un spécialiste de l'accessibilité, soit au minimum une passe de test avec un vrai lecteur d'écran (NVDA sur Windows est gratuit et le standard pour la plupart des utilisateurs aveugles en Europe).

Pour la plupart des PME, la bonne approche est : l'automatisation capte l'essentiel, puis une demi-journée avec un lecteur d'écran pour vérifier les parcours critiques (accueil → produit → paiement → compte).

Sur les widgets overlay, encore, avec conviction

Si votre chef de projet ou patron dit « installons AccessiBe », voici la conversation :

• Ils ne corrigent pas le HTML sous-jacent. Les procès et plaintes se fondent sur le code source.
• Ils cassent fréquemment les lecteurs d'écran déjà configurés sur l'appareil de l'utilisateur, car ils superposent un modèle d'interaction concurrent.
• Ils ne sont pas reconnus par les régulateurs de l'UE. Les actions en application françaises ciblaient spécifiquement la conformité au niveau du code source.
• Le principal fournisseur d'overlay a conclu un accord avec la FTC américaine en 2024 pour déclarations trompeuses sur la « conformité WCAG avec une ligne de JavaScript ».

Il n'existe pas de raccourci via overlay qui résiste à une plainte. Corrigez le code source.

Pour une analyse approfondie des couches juridiques, consultez notre guide WCAG vs EN 301 549 vs EAA. Pour les amendes par pays qui motivent ces plaintes, consultez notre guide des amendes EAA.