Problèmes d'accessibilité courants à éviter

Pourquoi les mêmes problèmes d’accessibilité reviennent sans cesse

La plupart des barrières d’accessibilité n’ont rien d’exotique. Année après année, les audits automatisés et manuels font ressortir la même courte liste d’erreurs : texte alternatif manquant, contraste insuffisant, champs de formulaire non étiquetés, pièges au clavier et structure défaillante. Elles reviennent parce qu’elles sont introduites en silence — un développeur livre un nouveau composant, un responsable marketing téléverse une image, un designer choisit une couleur de marque — et rien dans le flux de travail habituel ne signale le problème. Le résultat visuel paraît correct à une personne qui utilise une souris et une bonne vue, alors la barrière part en production.

Ce catalogue parcourt les échecs WCAG 2.2 les plus fréquents que nous rencontrons lors d’audits réels. Pour chacun, vous trouverez pourquoi il compte, qui il affecte, le critère de succès concerné et une correction concrète avant/après. Ensemble, ces problèmes représentent l’écrasante majorité des barrières qui bloquent les personnes handicapées — et l’écrasante majorité des plaintes juridiques déposées au titre de l’European Accessibility Act, de l’ADA et de la Section 508.

Une chose à clarifier avant la liste : les outils automatisés ne peuvent pas détecter tous ces problèmes. Des recherches indépendantes montrent systématiquement que même les meilleurs scanners ne détectent de façon fiable que 30 à 40 % des problèmes WCAG. Ils excellent à repérer les attributs alt manquants, les échecs de contraste programmatiques et l’absence d’étiquettes de formulaire, mais ils ne peuvent pas juger si un texte alternatif est exact, si l’ordre de focus est logique, ou si un widget personnalisé fonctionne réellement avec un lecteur d’écran. C’est pourquoi tout programme crédible associe l’analyse à une revue manuelle. Notre logiciel d’analyse d’accessibilité gère la couche automatisable ; les audits manuels et les audits réalisés par des personnes handicapées couvrent le reste.

Une manière rapide de trouver votre propre point de départ avant d’aller plus loin : affichez la page avec les images désactivées, lisez chaque mot comme un seul paragraphe sans structure, et essayez d’accomplir chaque tâche en utilisant uniquement le clavier. Partout où l’expérience s’effondre, vous avez trouvé une barrière.

Perceptible : contenu que les gens ne peuvent ni voir ni lire

Texte alternatif manquant ou inexact pour les images

Qui est affecté : les personnes aveugles ou malvoyantes qui utilisent des lecteurs d’écran ; toute personne sur une connexion lente où les images ne se chargent pas.

Critère WCAG : 1.1.1 Contenu non textuel (niveau A).

Les images sans attribut alt sont invisibles pour les technologies d’assistance — l’utilisateur peut même ignorer que l’image existe. Pire qu’un attribut manquant, un attribut inexact : des noms de fichiers comme IMG_4821.jpg, des mots génériques comme « image », ou des chaînes bourrées de mots-clés trompent activement l’auditeur.

La règle est simple mais dépend du contexte. Les images informatives ont besoin d’une description concise de leur sens, pas de leur apparence. Les images décoratives qui n’apportent rien doivent porter un alt="" vide pour que les lecteurs d’écran les ignorent. Les images fonctionnelles — une icône qui fait office de bouton — doivent décrire l’action, pas l’image. Les visuels complexes comme les graphiques ont besoin d’un alt court accompagné d’un équivalent textuel plus long à proximité.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Les outils automatisés détectent instantanément l’absence de texte alternatif. Ils ne peuvent pas vous dire si le texte est correct — cela demande qu’un humain lise la page dans son contexte.

Contraste de couleurs insuffisant

Qui est affecté : les personnes malvoyantes, daltoniennes ou présentant une perte de vue liée à l’âge ; toute personne qui utilise un écran en plein soleil.

Critère WCAG : 1.4.3 Contraste (minimum), niveau AA ; ainsi que 1.4.11 Contraste du contenu non textuel pour les composants d’interface.

WCAG 2.2 exige un ratio de contraste d’au moins 4,5:1 pour le texte normal et 3:1 pour le texte de grande taille (environ 18 pt, ou 14 pt en gras). Les composants d’interface et les graphiques porteurs de sens — bordures de champs, indicateurs de focus, icônes qui transmettent un état — doivent atteindre 3:1 par rapport à leur environnement. Les échecs de contraste figurent parmi les problèmes les plus courants relevés dans tout audit à grande échelle, et ils sont presque toujours introduits dès l’étape de conception.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Testez toute la palette, pas seulement le corps de texte : le texte des champs (placeholder), les états désactivés qui doivent rester lisibles, les messages d’erreur et le texte posé sur des photos sont des fautifs fréquents. Ne vous appuyez jamais sur la couleur seule pour transmettre du sens (1.4.1) — une bordure rouge sur un champ invalide doit être accompagnée d’un texte ou d’une icône.

Médias et mouvements en lecture automatique

Qui est affecté : les personnes atteintes de troubles vestibulaires, de troubles de l’attention ou cognitifs, les utilisateurs de lecteurs d’écran dont la sortie audio est couverte, et toute personne dans un espace partagé silencieux.

Critères WCAG : 1.4.2 Contrôle du son (niveau A), 2.2.2 Mettre en pause, arrêter, masquer (niveau A), 2.3.1 Pas plus de trois flashs (niveau A), et 2.3.3 Animation à partir d’interactions (niveau AAA).

Tout audio ou vidéo qui se lance automatiquement pendant plus de trois secondes doit offrir un moyen évident de le mettre en pause ou de le couper. Le contenu qui bouge, clignote ou se met à jour automatiquement pendant plus de cinq secondes — carrousels, bannières animées, défilements — a besoin d’un contrôle de pause accessible. Le contenu qui clignote plus de trois fois par seconde peut déclencher des crises et doit être totalement évité. Respectez le réglage prefers-reduced-motion de l’utilisateur pour atténuer les animations non essentielles.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Utilisable : ce que les gens ne peuvent pas utiliser

Inaccessibilité au clavier et pièges au clavier

Qui est affecté : les personnes à mobilité réduite qui ne peuvent pas utiliser de souris, les utilisateurs de lecteurs d’écran (qui naviguent au clavier), et les personnes qui utilisent un dispositif de contacteur ou la commande vocale.

Critères WCAG : 2.1.1 Clavier (niveau A) et 2.1.2 Pas de piège au clavier (niveau A).

Chaque interaction — liens, boutons, champs de formulaire, menus, fenêtres modales, sélecteurs de date, glisser-déposer — doit être entièrement utilisable au clavier seul. La variante la plus dommageable est le piège au clavier : le focus entre dans un composant (souvent une fenêtre modale ou un widget intégré) et ne peut plus en sortir, laissant l’utilisateur bloqué sur la page. Les widgets personnalisés sont les coupables habituels, car les éléments natifs comme <button> et <a> sont utilisables au clavier par défaut, tandis que les imitations à base de <div> ne le sont pas.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Parcourez vos parcours clés en utilisant uniquement Tab, Maj+Tab, les flèches, Entrée, Espace et Échap. Vérifiez que le focus peut toujours avancer et ressortir de chaque composant, qu’Échap ferme les superpositions, et que rien n’exige un pointeur. Notre service d’évaluation par lecteur d’écran teste précisément ces parcours tels que les vivent les véritables utilisateurs de technologies d’assistance.

Indicateurs de focus manquants ou invisibles et ordre de focus illogique

Qui est affecté : les utilisateurs voyants au clavier, les personnes malvoyantes, et toute personne qui a perdu le fil de sa position sur la page.

Critères WCAG : 2.4.7 Visibilité du focus (niveau A) et 2.4.3 Ordre de focus (niveau A) ; 2.4.11 Focus non masqué (niveau AA) dans WCAG 2.2.

Une erreur de « propreté » fréquente consiste à supprimer l’anneau de focus par défaut du navigateur avec outline: none sans jamais le remplacer. Les utilisateurs au clavier n’ont plus aucune idée de l’élément actif. Tout aussi nuisible est un ordre de focus qui ne suit pas l’ordre de lecture visuel et logique — généralement causé par des valeurs tabindex positives ou par un ordre du DOM qui diverge de la mise en page rendue.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 ajoute 2.4.11 : lorsqu’un élément reçoit le focus, il ne doit pas être complètement caché derrière des en-têtes collants, des bannières de cookies ou des widgets de chat. Ouvrez une fenêtre modale, parcourez-la au clavier, et confirmez que l’élément focalisé n’est jamais enseveli.

Liens et boutons non descriptifs

Qui est affecté : les utilisateurs de lecteurs d’écran qui affichent la liste de tous les liens pour parcourir une page, et les personnes ayant des troubles cognitifs.

Critères WCAG : 2.4.4 Fonction du lien (selon le contexte), niveau A ; 2.5.3 Étiquette dans le nom, niveau A.

Les utilisateurs de lecteurs d’écran naviguent souvent en sautant de lien en lien hors contexte. Une page remplie de liens « cliquez ici », « en savoir plus » et « lire la suite » devient dénuée de sens lorsqu’elle est lue sous forme de liste. Le texte d’un lien doit décrire sa destination à lui seul. Il en va de même pour les boutons composés uniquement d’une icône, qui ont besoin d’un nom accessible.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Qui est affecté : les utilisateurs de lecteurs d’écran, les utilisateurs au clavier, et les personnes ayant des troubles cognitifs.

Critère WCAG : 2.4.1 Contourner des blocs (niveau A).

Un méga-menu comportant des dizaines de liens force les utilisateurs de lecteurs d’écran et du clavier à traverser toute la liste sur chaque page avant d’atteindre le contenu. Un lien « Aller au contenu principal » placé comme premier élément focalisable leur permet de sauter directement par-dessus les blocs répétés. Regroupez les éléments connexes, gardez les menus légers, et assurez-vous que le lien d’évitement devient visible au focus.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Compréhensible : un contenu qui désoriente

Champs de formulaire non étiquetés ou mal associés

Qui est affecté : les utilisateurs de lecteurs d’écran, les personnes ayant des troubles cognitifs, et les utilisateurs de commande vocale qui désignent les champs par leur nom.

Critères WCAG : 1.3.1 Information et relations, 3.3.2 Étiquettes ou instructions, et 4.1.2 Nom, rôle et valeur (tous de niveau A).

Les champs de saisie sans <label> associé par programmation sont annoncés comme « zone d’édition, vide » — l’utilisateur n’a aucune idée de ce qu’il doit saisir. Le texte d’invite (placeholder) n’est pas un substitut : il disparaît à la saisie et échoue généralement au contraste. Les champs obligatoires, les règles de format et les erreurs de validation doivent eux aussi être transmis par du texte, et non par la couleur ou la position seules.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Reliez les messages d’erreur à leur champ avec aria-describedby, marquez les champs invalides avec aria-invalid, et assurez-vous que l’envoi d’un formulaire incomplet déplace le focus vers la première erreur.

Langue de la page manquante

Qui est affecté : les utilisateurs de lecteurs d’écran — une mauvaise langue fait que le synthétiseur prononce tout de travers.

Critères WCAG : 3.1.1 Langue de la page (niveau A) et 3.1.2 Langue d’un passage (niveau AA).

Un seul attribut manquant casse la prononciation de toute une page. Déclarez la langue principale sur l’élément racine, et marquez les passages dans une autre langue avec leur propre lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Hiérarchie de titres incorrecte et repères manquants

Qui est affecté : les utilisateurs de lecteurs d’écran qui naviguent par titres et par régions, et toute personne qui s’appuie sur la structure du document.

Critère WCAG : 1.3.1 Information et relations (niveau A).

Les titres constituent le plan de la page. Les utilisateurs de lecteurs d’écran sautent de titre en titre pour trouver rapidement le contenu ; lorsque des niveaux sont sautés, utilisés uniquement pour la taille de police, ou absents, cette navigation s’effondre. Chaque page doit avoir un seul <h1> et une suite logique et ininterrompue de <h2>, <h3>, et ainsi de suite. Tout aussi importantes sont les régions de repère — <header>, <nav>, <main>, <footer> — qui permettent aux utilisateurs de sauter entre les grandes zones. Une page entièrement construite à partir d’éléments <div> n’offre aucune carte de ce genre.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robuste : du code que les technologies d’assistance ne peuvent pas interpréter

Widgets personnalisés inaccessibles et ARIA mal utilisé

Qui est affecté : les utilisateurs de lecteurs d’écran avant tout, et toute technologie d’assistance qui s’appuie sur un arbre d’accessibilité correct.

Critère WCAG : 4.1.2 Nom, rôle et valeur (niveau A).

Les listes déroulantes, onglets, accordéons, zones de liste combinées, fenêtres modales et infobulles personnalisés, construits à partir de <div> et <span>, n’ont aucun rôle, état ni comportement clavier intrinsèque. Les développeurs se tournent vers ARIA pour combler ce manque, mais ARIA ne fait que décrire — il n’ajoute aucun comportement, et un ARIA incorrect est pire que rien. La première règle d’ARIA est de préférer un élément HTML natif dès qu’il en existe un. Lorsque vous devez construire un widget personnalisé, implémentez toute l’interaction clavier que spécifient les modèles de conception ARIA et maintenez aria-expanded, aria-selected et les états similaires synchronisés avec la réalité.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Ce sont précisément les problèmes que les scanners automatisés manquent le plus souvent. Un scanner voit un attribut aria-expanded et le valide ; seul un humain (ou un testeur utilisant un lecteur d’écran) peut confirmer que la valeur bascule réellement à l’ouverture du menu. Consultez notre guide de test avec lecteur d’écran pour savoir comment vérifier le comportement d’un widget de bout en bout.

Une note sur les widgets de superposition (overlays)

Il est tentant d’installer un « widget d’accessibilité » d’une seule ligne ou une superposition qui promet une conformité instantanée. Ces outils ne corrigent pas les problèmes ci-dessus — le texte alternatif manque toujours dans la source, le contraste échoue toujours, le widget personnalisé reste cassé. Les superpositions ne peuvent pas remédier au code qui crée les barrières, elles interfèrent fréquemment avec les propres technologies d’assistance des utilisateurs, et elles figurent dans un nombre croissant de poursuites liées à l’accessibilité. La véritable accessibilité numérique vient de la correction du HTML, du CSS et du comportement sous-jacents, et non de leur dissimulation.

Empêchez ces problèmes de revenir

Corriger une liste de bugs une fois est nécessaire mais pas suffisant ; les mêmes problèmes réapparaissent à la prochaine livraison à moins de changer la façon dont les choses partent en production. La correction durable consiste à intégrer l’accessibilité dans le flux de travail :

Détectez tôt les 30 à 40 % automatisables en intégrant les analyses dans votre pipeline. L’intégration de l’accessibilité dans le CI/CD fait échouer la build lorsqu’une régression est introduite, avant qu’elle n’atteigne la production.
Couvrez le reste avec des personnes. Planifiez des audits d’accessibilité manuels et des audits par des personnes handicapées, qui font émerger des barrières qu’aucun outil ne peut détecter.
Donnez aux équipes les bons instruments. La boîte à outils d’accessibilité QualiBooth et Agora aident designers et développeurs à tester au fil de leur travail.
Faites-en un processus, pas un projet. Un conseil en accessibilité continu et l’amélioration des processus d’accessibilité ancrent les habitudes pour que la qualité se maintienne dans le temps.

Pour une feuille de route de remédiation étape par étape, commencez par notre guide sur comment rendre votre site web conforme aux WCAG.

Par où commencer aujourd’hui

Avec plus de 1,3 milliard de personnes dans le monde vivant avec une forme de handicap, l’argument commercial en faveur de l’accessibilité est clair — et depuis juin 2025, l’argument juridique au titre de l’European Accessibility Act l’est aussi. Les problèmes de ce catalogue sont les premiers examinés dans toute plainte ou tout audit.

Le moyen le plus rapide de savoir où vous en êtes est de lancer une analyse d’URL gratuite — sans configuration, sans engagement. Lorsque vous serez prêt à aller au-delà de ce que l’automatisation peut atteindre, demandez une démo et nous vous montrerons comment un programme combinant l’automatisation et le manuel comble l’écart restant.