Les 10 erreurs d'accessibilité web les plus courantes

Chaque année, les analyses d'accessibilité web révèlent les mêmes constats : une poignée d'erreurs récurrentes concentrent la majorité des problèmes de conformité. Selon le WebAIM Million Report, 96,3 % des pages d'accueil des sites les plus visités présentent au moins une erreur d'accessibilité détectable automatiquement. La bonne nouvelle ? Ces erreurs sont généralement simples à corriger une fois identifiées. Voici les 10 erreurs les plus courantes, leurs impacts, les critères RGAA concernés et les solutions concrètes pour y remédier.

1. Absence de textes alternatifs sur les images

Le problème

Lorsqu'une image ne possède pas d'attribut alt, les lecteurs d'écran ne peuvent pas la décrire aux utilisateurs non voyants. Ils annoncent alors le nom du fichier (IMG_3847.jpg) ou rien du tout, privant l'utilisateur d'une information potentiellement essentielle.

Critères RGAA concernés

• Critère 1.1 : Chaque image porteuse d'information a-t-elle une alternative textuelle ?
• Critère 1.2 : Chaque image de décoration est-elle correctement ignorée par les technologies d'assistance ?

Comment corriger

Image porteuse d'information :

<!-- Mauvais -->
<img src="graphique-ventes-2026.png">

<!-- Bon -->
<img src="graphique-ventes-2026.png"
     alt="Graphique des ventes 2026 : hausse de 15 % au premier trimestre">

Image décorative :

<!-- Mauvais -->
<img src="decoration-florale.png">

<!-- Bon -->
<img src="decoration-florale.png" alt="">

Le texte alternatif doit être concis et informatif. Il décrit la fonction ou l'information véhiculée par l'image, pas son apparence détaillée. Pour les images décoratives (purement esthétiques), un alt="" vide indique aux technologies d'assistance de les ignorer.

2. Contrastes insuffisants

Le problème

Un contraste trop faible entre le texte et son arrière-plan rend la lecture difficile voire impossible pour les personnes malvoyantes, les personnes âgées, ou tout utilisateur dans des conditions d'éclairage défavorables. C'est l'erreur la plus répandue : elle touche plus de 80 % des sites analysés.

Critères RGAA concernés

• Critère 3.2 : Dans chaque page, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé ?
• Critère 3.3 : Dans chaque page, les couleurs utilisées dans les composants d'interface ou les éléments graphiques porteurs d'informations sont-elles suffisamment contrastées ?

Comment corriger

Les ratios minimaux selon les WCAG 2.1 (repris par le RGAA) sont :

• 4.5:1 pour le texte de taille normale (< 24px ou < 18.5px en gras)
• 3:1 pour les grands textes (>= 24px ou >= 18.5px en gras)
• 3:1 pour les composants d'interface et les éléments graphiques

/* Mauvais : contraste de 2.5:1 */
.text-light {
  color: #999999;
  background-color: #ffffff;
}

/* Bon : contraste de 7:1 */
.text-accessible {
  color: #595959;
  background-color: #ffffff;
}

Utilisez notre calculateur de contraste pour vérifier vos combinaisons de couleurs. Le simulateur de daltonisme vous permet également de voir comment vos couleurs sont perçues par les personnes daltoniennes.

3. Labels manquants sur les formulaires

Le problème

Un champ de formulaire sans label associé est inutilisable pour les utilisateurs de lecteurs d'écran. Le lecteur annonce simplement "champ de saisie" sans indiquer ce qu'il faut y entrer. Les attributs placeholder ne sont pas des substituts acceptables : ils disparaissent à la saisie et ne sont pas systématiquement lus par les technologies d'assistance.

Critères RGAA concernés

• Critère 11.1 : Chaque champ de formulaire a-t-il une étiquette ?
• Critère 11.2 : Chaque étiquette associée à un champ de formulaire est-elle pertinente ?

Comment corriger

<!-- Mauvais : pas de label -->
<input type="email" placeholder="Votre e-mail">

<!-- Bon : label explicite -->
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email">

<!-- Alternative : label implicite (enveloppant) -->
<label>
  Adresse e-mail
  <input type="email" name="email">
</label>

<!-- Cas particulier : label visible non souhaité -->
<label for="search" class="sr-only">Rechercher sur le site</label>
<input type="search" id="search" name="q" placeholder="Rechercher...">

La classe sr-only (screen reader only) cache visuellement le label tout en le rendant accessible aux technologies d'assistance. C'est une solution acceptable quand le contexte visuel rend le label évident pour les utilisateurs voyants.

4. Hiérarchie des titres incohérente

Le problème

Les titres (h1 à h6) structurent le contenu pour les lecteurs d'écran, qui proposent une navigation par titres. Une hiérarchie incohérente (sauter du h1 au h4, utiliser des titres pour le style plutôt que la structure) désoriente les utilisateurs et rend la navigation laborieuse.

Critères RGAA concernés

• Critère 9.1 : Dans chaque page, l'information est-elle structurée par l'utilisation appropriée de titres ?

Comment corriger

<!-- Mauvais : sauts de niveaux, titres décoratifs -->
<h1>Mon site</h1>
<h4>Bienvenue</h4> <!-- Saut de h1 à h4 -->
<h2>Services</h2>
<h2>À propos</h2>
<h5>Notre équipe</h5> <!-- Saut de h2 à h5 -->

<!-- Bon : hiérarchie logique et continue -->
<h1>Mon site</h1>
  <h2>Bienvenue</h2>
  <h2>Services</h2>
    <h3>Développement web</h3>
    <h3>Design</h3>
  <h2>À propos</h2>
    <h3>Notre équipe</h3>
    <h3>Notre histoire</h3>

Règles essentielles :

• Un seul h1 par page (le titre principal)
• Pas de saut de niveau : un h3 doit être précédé d'un h2
• Utilisez les titres pour la structure, pas pour le style (utilisez CSS pour le style)
• Chaque section de contenu significative doit avoir un titre

Notre validateur de titres peut vous aider à visualiser et corriger la hiérarchie de vos pages.

5. Pièges clavier

Le problème

Un piège clavier (keyboard trap) se produit lorsqu'un utilisateur naviguant au clavier ne peut plus sortir d'un composant avec les touches standard (Tab, Échap). L'utilisateur se retrouve bloqué, incapable d'accéder au reste de la page. C'est l'un des problèmes les plus bloquants en accessibilité.

Critères RGAA concernés

• Critère 12.8 : Dans chaque page, l'ordre de tabulation est-il cohérent ?
• Critère 12.9 : Dans chaque page, la navigation ne doit pas contenir de piège au clavier

Comment corriger

Les situations les plus fréquentes :

Modale qui ne se ferme pas avec Échap :

// Bon : gestion du clavier dans une modale
dialog.addEventListener('keydown', (event) => {
  if (event.key === 'Escape') {
    closeDialog();
    triggerButton.focus(); // Retour du focus sur l'élément déclencheur
  }
});

Widget personnalisé sans gestion du focus :

// Bon : le composant permet de sortir avec Tab
customWidget.addEventListener('keydown', (event) => {
  if (event.key === 'Tab' && isLastFocusableElement(event.target)) {
    // Laisser le comportement par défaut de Tab
    // pour sortir du composant
  }
});

Pour des conseils approfondis sur la gestion du clavier, consultez notre article dédié à la navigation clavier.

6. Absence de liens d'évitement

Le problème

Les liens d'évitement (skip links) permettent aux utilisateurs de clavier et de lecteurs d'écran de sauter directement au contenu principal, sans devoir parcourir toute la navigation à chaque changement de page. Sans eux, un utilisateur au clavier doit effectuer des dizaines de tabulations avant d'atteindre le contenu.

Critères RGAA concernés

• Critère 12.7 : Dans chaque page, un lien d'évitement ou d'accès rapide à la zone de contenu principal est-il présent ?

Comment corriger

<body>
  <!-- Lien d'évitement en tout premier élément du body -->
  <a href="#main-content" class="skip-link">
    Aller au contenu principal
  </a>

  <header>
    <nav><!-- Navigation principale --></nav>
  </header>

  <main id="main-content" tabindex="-1">
    <!-- Contenu principal -->
  </main>
</body>

.skip-link {
  position: absolute;
  top: -100%;
  left: 0;
  z-index: 100;
  padding: 0.75rem 1.5rem;
  background: #000;
  color: #fff;
}

/* Visible au focus (quand l'utilisateur appuie sur Tab) */
.skip-link:focus {
  top: 0;
}

Le tabindex="-1" sur le <main> permet au lien d'évitement de transférer le focus correctement, même dans les navigateurs qui ne gèrent pas nativement le focus sur les éléments non interactifs. Consultez notre générateur de liens d'évitement pour obtenir un code prêt à l'emploi.

7. Médias en lecture automatique

Le problème

Les contenus audio ou vidéo qui démarrent automatiquement posent plusieurs problèmes :

• Ils interfèrent avec les lecteurs d'écran (le son du média couvre la voix de synthèse)
• Ils désorientent les utilisateurs ayant des troubles cognitifs
• Ils peuvent déclencher des réactions chez les personnes ayant des troubles vestibulaires (animations)

Critères RGAA concernés

• Critère 4.10 : Chaque son déclenché automatiquement est-il contrôlable par l'utilisateur ?
• Critère 13.8 : Dans chaque page, chaque contenu en mouvement ou clignotant est-il contrôlable par l'utilisateur ?

Comment corriger

<!-- Mauvais -->
<video autoplay src="promo.mp4"></video>

<!-- Bon : pas d'autoplay, contrôles visibles -->
<video controls src="promo.mp4">
  <track kind="captions" src="promo-fr.vtt" srclang="fr" label="Français">
</video>

<!-- Si autoplay est indispensable : muet + contrôle d'arrêt -->
<video autoplay muted loop id="bg-video" src="ambiance.mp4"></video>
<button onclick="toggleVideo()" aria-label="Mettre en pause la vidéo d'arrière-plan">
  Pause
</button>

Règle d'or : si un média démarre automatiquement, il doit être muet par défaut et l'utilisateur doit pouvoir le mettre en pause ou l'arrêter facilement.

8. Indicateurs de focus insuffisants

Le problème

Lorsqu'un utilisateur navigue au clavier avec Tab, un indicateur de focus (outline) lui montre quel élément est actuellement sélectionné. Supprimer cet indicateur (avec outline: none) est l'équivalent visuel de masquer le curseur de la souris. L'utilisateur au clavier ne sait plus où il se trouve dans la page.

Critères RGAA concernés

• Critère 10.7 : Dans chaque page, pour chaque élément recevant le focus, la prise de focus est-elle visible ?

Comment corriger

/* Mauvais : suppression de l'outline sans alternative */
*:focus {
  outline: none;
}

/* Bon : style de focus personnalisé et visible */
*:focus-visible {
  outline: 3px solid #4A90D9;
  outline-offset: 2px;
}

/* Alternative : ombre portée comme indicateur de focus */
.button:focus-visible {
  outline: none;
  box-shadow: 0 0 0 3px #ffffff, 0 0 0 5px #4A90D9;
}

Le sélecteur :focus-visible est la meilleure approche moderne : il n'affiche l'indicateur de focus que lors de la navigation au clavier, pas lors d'un clic souris. Cela satisfait à la fois l'accessibilité et les exigences esthétiques.

L'indicateur de focus doit avoir un contraste suffisant (ratio de 3:1 minimum) par rapport à l'arrière-plan adjacent.

9. Liens non descriptifs

Le problème

Les liens intitulés "cliquez ici", "en savoir plus" ou "lire la suite" ne transmettent aucune information hors contexte. Un utilisateur de lecteur d'écran qui parcourt la liste des liens de la page (fonctionnalité courante) voit une succession de "en savoir plus" sans savoir à quoi ils se rapportent.

Critères RGAA concernés

• Critère 6.1 : Chaque lien est-il explicite ?
• Critère 6.2 : Dans chaque page, chaque lien a-t-il un intitulé ?

Comment corriger

<!-- Mauvais -->
<p>Découvrez nos services. <a href="/services">Cliquez ici</a></p>

<!-- Bon : lien explicite -->
<p><a href="/services">Découvrir nos services d'audit accessibilité</a></p>

<!-- Alternative avec aria-label si le contexte visuel est suffisant -->
<article>
  <h3>Audit RGAA complet</h3>
  <p>Un audit exhaustif des 106 critères...</p>
  <a href="/services/audit" aria-label="En savoir plus sur l'audit RGAA complet">
    En savoir plus
  </a>
</article>

<!-- Alternative avec aria-labelledby -->
<article>
  <h3 id="audit-title">Audit RGAA complet</h3>
  <p>Un audit exhaustif des 106 critères...</p>
  <a href="/services/audit" aria-labelledby="audit-title">En savoir plus</a>
</article>

Le RGAA accepte que le contexte du lien (titre de section, phrase englobante, cellule d'en-tête de tableau) contribue à rendre le lien explicite. Mais l'idéal reste un intitulé intrinsèquement descriptif.

10. Attribut lang manquant ou incorrect

Le problème

L'attribut lang sur la balise <html> indique aux technologies d'assistance dans quelle langue le contenu est rédigé. Sans cet attribut, le lecteur d'écran utilise sa langue par défaut (souvent l'anglais), ce qui produit une prononciation incompréhensible pour un contenu français.

Critères RGAA concernés

• Critère 8.3 : Dans chaque page, la langue par défaut est-elle présente ?
• Critère 8.4 : Pour chaque page ayant une langue par défaut, le code de langue est-il pertinent ?
• Critère 8.7 : Dans chaque page, chaque changement de langue est-il indiqué dans le code source ?

Comment corriger

<!-- Mauvais : pas d'attribut lang -->
<html>
  <head>...</head>

<!-- Bon : langue déclarée -->
<html lang="fr">
  <head>...</head>

<!-- Changement de langue dans le contenu -->
<p>
  Cette technique est connue sous le nom de
  <span lang="en">progressive enhancement</span>.
</p>

Chaque passage dans une langue différente de la langue principale doit être balisé avec l'attribut lang approprié (sauf pour les noms propres et les mots passés dans l'usage courant).

Comment identifier ces erreurs sur votre site

La plupart de ces 10 erreurs sont détectables par des outils automatisés. Lancez un scan de votre site pour obtenir un diagnostic immédiat. Le rapport identifiera les problèmes de contrastes, d'attributs alt, de labels, de hiérarchie de titres et d'attribut lang.

Pour les erreurs nécessitant un test manuel (pièges clavier, pertinence des alternatives, qualité du focus), suivez la méthodologie décrite dans notre guide sur l'audit RGAA.

Prioriser les corrections

Toutes les erreurs n'ont pas le même impact. Voici un ordre de priorité suggéré :

1. Pièges clavier (bloquant) : empêchent totalement l'utilisation du site
2. Liens d'évitement (critique) : fortement impactant pour les utilisateurs quotidiens
3. Labels de formulaires (critique) : rendent les formulaires inutilisables
4. Textes alternatifs (important) : perte d'information significative
5. Contrastes (important) : impact sur un large public
6. Hiérarchie des titres (modéré) : dégrade la navigation par titres
7. Focus visible (modéré) : impacte la navigation clavier
8. Liens non descriptifs (modéré) : dégrade l'expérience de navigation
9. Attribut lang (faible impact unitaire) : correction rapide et systématique
10. Médias en autoplay (contextuel) : dépend de la présence de médias sur le site

Corriger ces 10 erreurs vous permettra de résoudre la grande majorité des problèmes d'accessibilité automatiquement détectables et de poser des bases solides pour une conformité RGAA plus complète.