Comment corriger les 6 erreurs WCAG les plus courantes sur n’importe quel site web

Ouvrez n’importe lequel des un million de sites web les plus visités en ce moment et il y a 96 chances sur 100 que vous trouviez une violation des WCAG qu’un scanner automatisé peut détecter en quelques secondes. Sur un million de pages d’accueil, 56 114 377 erreurs d’accessibilité distinctes ont été détectées — soit une moyenne de 56,1 erreurs par page. Ce qui rend cela particulièrement frappant, c’est que 96% de toutes les erreurs détectées se répartissent en seulement six catégories, et ces six types d’erreurs les plus courants sont restés les mêmes au cours des sept dernières années. Cela signifie que corriger une poignée de problèmes bien compris améliorerait considérablement l’accessibilité de l’ensemble du web — et cela commence par votre site.

Pourquoi les mêmes six échecs continuent d’apparaître

Vous pouvez vous demander comment, à une époque d’outils de développement sophistiqués et d’un contrôle juridique croissant, les mêmes erreurs persistent à grande échelle année après année. La réponse est systémique. Cette densité d’erreurs reflète à quel point l’inaccessibilité a été intégrée en profondeur dans les pratiques de développement web. Les problèmes de gabarits se multiplient sur chaque page. Les défaillances de composants se répètent sur l’ensemble des sites. Sans attention délibérée portée à l’accessibilité, les flux de travail de développement standard produisent systématiquement des résultats inaccessibles.

Il existe également un faux sentiment de progrès alimenté par l’automatisation. Les tests automatisés ne détectent que 30–40% des échecs potentiels de conformité aux WCAG. Les sites qui réussissent les tests automatisés peuvent encore présenter des problèmes significatifs de navigation au clavier, de lecteur d’écran ou d’accessibilité cognitive. Cela signifie que même le faible pourcentage de sites qui semblent conformes sur le papier sont probablement insuffisants en pratique.

Les enjeux juridiques sont réels et en hausse. Selon Seyfarth Shaw, 8 800 poursuites fédérales au titre du Title III de l’ADA ont été intentées en 2024, dont environ 2 452 visant spécifiquement l’accessibilité web. Les sites d’e-commerce font face à un risque disproportionné — 77% des poursuites liées à l’accessibilité web ciblent le commerce en ligne. La conformité n’est plus un simple avantage. C’est une question de continuité d’activité.

Le revers encourageant ? Cette concentration a des implications pratiques. Les organisations peuvent traiter la majorité de leurs problèmes d’accessibilité en se concentrant sur une poignée de types de problèmes. Une conformité complète aux WCAG exige une attention à l’ensemble des 78 critères, mais les améliorations à plus fort impact viennent de la correction de ces échecs courants. Passons donc en revue chacun d’eux, avec des correctifs pratiques que vous pouvez mettre en œuvre dès aujourd’hui.

Échec n°1 — Texte à faible contraste (WCAG 1.4.3)

Le texte à faible contraste — du texte qui n’a pas une différenciation de couleur suffisante par rapport à son arrière-plan — apparaît sur 83,6% des pages d’accueil étudiées. C’est l’échec WCAG le plus courant, affectant plus de quatre sites sur cinq. La WCAG 1.4.3 (Contraste minimum) est d’une brutalité désarmante : le texte normal doit atteindre un ratio de contraste d’au moins 4,5:1 avec son arrière-plan, et le texte de grande taille (18pt ou 14pt en gras) doit atteindre au moins 3:1.

Les échecs de contraste proviennent souvent de décisions de design qui privilégient l’esthétique au détriment de la lisibilité. Du texte gris clair sur un fond blanc paraît sophistiqué aux designers ayant une vision parfaite. Pour les personnes malvoyantes, les personnes âgées ou toute personne lisant sur un écran avec des reflets, il est illisible. Les libellés secondaires, les placeholders de formulaires, le texte de pied de page et les états de boutons désactivés sont les coupables habituels — ils sont stylés pour paraître subtils et finissent par être invisibles pour une part significative de votre audience.

La correction est presque toujours un ajustement CSS. Passez vos paires de couleurs dans un vérificateur de contraste comme l’outil de contraste de WebAIM ou le panneau d’accessibilité des DevTools du navigateur, puis ajustez légèrement la valeur de premier plan ou d’arrière-plan jusqu’à ce que cela passe. Voici un schéma courant qui échoue et comment le corriger :

/* Échec — ratio d’environ 2,3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Conforme — ratio d’environ 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

Pour le texte de placeholder, rappelez-vous que les WCAG le considèrent comme du vrai texte — pas comme un indice décoratif — il doit donc également respecter le seuil de 4,5:1. Évitez de vous reposer uniquement sur le placeholder pour transmettre des instructions ; associez-le toujours à un élément <label> visible. Si vous utilisez des images de texte, vous ne pouvez pas corriger le contraste avec du CSS — vous devez régénérer ces images, ce qui est une raison de plus de préférer du texte HTML vivant à du texte intégré dans des graphiques.

Échec n°2 — Texte alternatif d’image manquant (WCAG 1.1.1)

Des images sans texte alternatif apparaissent sur 58,2% des pages d’accueil. Lorsque les images n’ont pas de texte alternatif, les utilisateurs de lecteurs d’écran rencontrent soit le silence, soit des noms de fichiers dénués de sens là où un contenu significatif devrait se trouver. Ce problème n’est pas nouveau. Le texte alternatif est une exigence fondamentale en matière d’accessibilité depuis la WCAG 1.0 en 1999. Vingt-cinq ans plus tard, la plupart des sites web ne l’implémentent toujours pas de manière cohérente.

La raison de sa persistance est un problème de flux de travail, pas de connaissance. Ce taux d’échec pointe vers des lacunes systématiques dans les flux de travail de contenu. Les rédacteurs et éditeurs ne savent souvent pas qu’un texte alternatif est nécessaire. Les systèmes de gestion de contenu ne le demandent pas toujours. L’assurance qualité ne détecte pas son absence. La correction comporte donc deux couches : une technique et une liée au processus.

Sur le plan technique, chaque image significative a besoin d’un attribut alt qui transmet la même information que l’image. Les images décoratives — des éléments purement visuels qui n’ajoutent aucune information — doivent recevoir un alt="" vide afin que les lecteurs d’écran les ignorent complètement. Bien distinguer ces cas est tout aussi important que d’ajouter l’attribut en lui-même. Un large pourcentage d’images ont un texte alternatif manquant ou inexact. Certaines images significatives n’ont aucune description, tandis que des images décoratives sont souvent traitées comme du contenu significatif. Ces deux problèmes rompent la conformité aux WCAG pour le contenu perceptible.

<!-- Image significative : décrire ce qu’elle transmet -->
<img src='team-photo.jpg' alt='L’équipe d’ingénierie d’Accsible lors de son séminaire 2024 à Lisbonne' />

<!-- Image décorative : alt vide, aucun rôle nécessaire -->
<img src='wave-divider.svg' alt='' />

<!-- Image cliquable : décrire la destination, pas l’image -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='Voir les formules tarifaires' />
</a>

Sur le plan du processus, mettez à jour les gabarits de votre CMS pour rendre le champ alt obligatoire pour les images de contenu, et formez toute personne qui téléverse des ressources. Des outils automatisés comme Accsible peuvent détecter, à l’échelle du site, les images dont le texte alternatif est manquant ou vide, fournissant à votre équipe une liste vérifiable à traiter de manière systématique.

Échec n°3 — Libellés de champs de formulaire manquants (WCAG 1.3.1, 3.3.2)

48,6% des sites web ont des libellés de champs de formulaire manquants. Cet échec est particulièrement dommageable car les formulaires sont l’endroit où les utilisateurs agissent réellement — s’inscrire, payer, prendre contact, soumettre des demandes de support. De nombreux formulaires n’ont pas de libellés accessibles, se reposent uniquement sur des placeholders, n’exposent pas les instructions et messages d’erreur, ou ne prennent pas en charge une utilisation uniquement au clavier. Comme les formulaires sont essentiels à la plupart des expériences numériques, ces échecs créent de sérieux obstacles d’utilisabilité.

L’erreur la plus courante est d’utiliser le texte de placeholder comme substitut à un <label>. Les placeholders disparaissent dès qu’un utilisateur commence à saisir, laissant toute personne ayant un trouble de la mémoire à court terme — ou simplement quelqu’un qui est distrait en cours de formulaire — sans aucun rappel de la fonction du champ. Les lecteurs d’écran varient dans la façon dont ils gèrent les placeholders, et aucune approche n’est aussi fiable qu’une association correcte avec un libellé.

Le schéma correct consiste à utiliser un élément <label> lié à son champ via des attributs for et id correspondants. Si un libellé visible n’est pas possible pour des raisons de design, utilisez aria-label ou aria-labelledby — mais ne recourez pas à ARIA lorsque vous pouvez simplement utiliser un <label>.

<!-- Correct : association explicite du libellé -->
<label for='email'>Adresse e-mail</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Incorrect : placeholder uniquement -->
<input type='email' placeholder='Adresse e-mail' />

<!-- Acceptable lorsque le libellé doit être visuellement masqué -->
<label for='search' class='visually-hidden'>Rechercher sur le site</label>
<input type='search' id='search' name='q' />

Les messages d’erreur doivent également être associés de manière programmatique. Lorsqu’un formulaire est validé et qu’une erreur est trouvée, le message doit être lié au champ à l’aide de aria-describedby, et idéalement le focus doit être déplacé vers le premier champ invalide. Les erreurs de validation de formulaire doivent être efficaces, intuitives et accessibles — l’erreur doit être clairement identifiée, un accès rapide à l’élément problématique doit être fourni, et l’utilisateur doit pouvoir corriger facilement l’erreur et soumettre à nouveau le formulaire.

Échec n°4 — Liens et boutons vides (WCAG 2.4.4, 4.1.2)

44,6% des sites web ont des hyperliens vides. Des boutons vides ont été trouvés sur presque 30% des pages, et ce nombre a augmenté par rapport à l’année précédente. Cela signifie que les personnes aveugles ou malvoyantes ne comprendront pas la fonction de boutons tels que envoyer, réinitialiser, filtrer ou rechercher. Ensemble, les liens et boutons vides représentent l’une des expériences les plus frustrantes pour les utilisateurs de lecteurs d’écran — rencontrer des éléments interactifs sans nom revient à appuyer sur une poignée de porte sans étiquette et sans aucune idée de l’endroit où elle mène.

Les liens vides surviennent le plus souvent lorsqu’une icône ou une image est l’unique enfant d’une balise <a>, sans texte alternatif fourni. Les boutons vides apparaissent lorsque des boutons composés uniquement d’icônes — menus hamburger, icônes de fermeture, boutons de partage social — n’ont aucun nom accessible. Les deux sont simples à corriger.

<!-- Lien vide — échec -->
<a href='/dashboard'><svg>...</svg></a>

<!-- Corrigé avec aria-label -->
<a href='/dashboard' aria-label='Aller au tableau de bord'><svg aria-hidden='true'>...</svg></a>

<!-- Bouton vide — échec -->
<button><svg>...</svg></button>

<!-- Corrigé avec du texte visuellement masqué -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Fermer le menu</span>
</button>

Notez l’attribut aria-hidden='true' sur le SVG dans chaque exemple corrigé. Lorsque vous fournissez une alternative textuelle via aria-label ou du texte visuellement masqué, vous voulez supprimer le SVG de l’arbre d’accessibilité — sinon les lecteurs d’écran peuvent annoncer à la fois le libellé et le titre ou la description propres au SVG, créant une double annonce déroutante. Un texte de lien ambigu — des expressions comme « cliquez ici », « lire la suite » ou « en savoir plus » — est un échec apparenté. D’autres problèmes d’hyperliens, tels que le texte de lien ambigu, ont été trouvés sur presque 14% des pages d’accueil, une augmentation par rapport à l’année précédente. Des hyperliens avec un texte approprié sont importants pour que les utilisateurs sachent où un lien les mènera. Le nom accessible de chaque lien doit avoir du sens hors contexte, car les utilisateurs de lecteurs d’écran naviguent fréquemment en affichant une liste de tous les liens d’une page.

Échec n°5 — Langue du document manquante (WCAG 3.1.1)

Cela peut sembler mineur comparé au contraste ou au texte alternatif, mais environ 16% des pages n’ont pas de langue de document définie — et l’impact sur les utilisateurs de lecteurs d’écran est immédiat et déstabilisant. Si un utilisateur de lecteur d’écran a installé le pack linguistique spécifique, le contenu sera vocalisé correctement. Sinon, il sonnera comme un mauvais accent et pourra être incompréhensible.

La correction tient en un seul attribut HTML — littéralement une ligne de code — et il n’y a aucune excuse pour l’omettre. Ajoutez l’attribut lang à votre élément <html> avec l’étiquette de langue BCP 47 appropriée. Si des sections de votre page sont dans une langue différente de celle de la page dans son ensemble, ajoutez également un attribut lang à ces éléments spécifiques.

<!-- Manquant : aucun attribut lang -->
<html>

<!-- Correct : page en anglais -->
<html lang='en'>

<!-- Correct : page en français -->
<html lang='fr'>

<!-- Changement de langue en ligne dans une page -->
<p>L’expression française <span lang='fr'>joie de vivre</span> signifie une réjouissance de la vie.</p>

Si vous utilisez un CMS ou un générateur de site statique, l’attribut lang doit être défini dans votre gabarit de base. Vérifiez votre gabarit une fois, corrigez-le une fois, et chaque page de votre site est immédiatement corrigée. C’est probablement la correction au meilleur retour sur effort de toute cette liste — un seul changement de gabarit élimine le problème sur l’ensemble de votre domaine.

Échec n°6 — Navigation au clavier et gestion du focus inaccessibles (WCAG 2.1.1, 2.4.7)

L’accessibilité clavier est l’endroit où l’écart entre les tests automatisés et l’utilisabilité réelle est le plus grand. Les outils automatisés peuvent détecter certains échecs liés au clavier — comme des éléments interactifs construits à partir de balises non sémantiques — mais ils ne peuvent pas simuler l’ordre de tabulation, les pièges de focus ou l’expérience de navigation dans un menu déroulant uniquement avec les touches fléchées. Les sites suppriment fréquemment les indicateurs de focus par défaut sans fournir d’alternatives, rendant la navigation au clavier presque impossible. Cela affecte non seulement les personnes ayant un handicap moteur, mais aussi toute personne qui préfère la navigation au clavier, les utilisateurs avancés et les personnes utilisant des dispositifs de commande par contacteur.

Les échecs clavier les plus courants sont : des composants interactifs personnalisés construits à partir de balises <div> ou <span> qui ne reçoivent jamais le focus ; des règles CSS qui suppriment l’anneau de focus par défaut du navigateur avec outline: none ou outline: 0 sans le remplacer par quelque chose d’aussi visible ; des boîtes de dialogue modales qui ne piègent pas le focus (de sorte que les utilisateurs au clavier peuvent tabuler derrière la superposition) ; et des carrousels ou accordéons qui ne peuvent pas être utilisés sans souris.

<!-- Bouton personnalisé inaccessible au clavier — échec -->
<div class='btn' onclick='doSomething()'>Envoyer</div>

<!-- Correct : utiliser un vrai bouton -->
<button type='button' onclick='doSomething()'>Envoyer</button>

<!-- Suppression des styles de focus — échec WCAG 2.4.7 -->
* {
  outline: none; /* ne faites jamais cela globalement */
}

<!-- Mieux : styliser le focus de manière visible tout en préservant l’esthétique -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

La pseudo-classe :focus-visible est ici votre meilleure alliée. Elle affiche les styles de focus lorsqu’un utilisateur navigue au clavier, mais les supprime pour les clics de souris — vous offrant une esthétique soignée sans sacrifier l’accessibilité. Pour les modales et tiroirs, utilisez un utilitaire de piégeage du focus qui limite la navigation par tabulation à l’intérieur de la boîte de dialogue lorsqu’elle est ouverte, et renvoie le focus à l’élément déclencheur lorsqu’elle se ferme. Les pop-ups apparaissent souvent sans gestion correcte du focus, sans libellés ou sans prise en charge de la navigation au clavier. Cela provoque des perturbations significatives, en particulier dans des parcours utilisateurs critiques comme l’inscription, la connexion et le paiement.

Au-delà des composants individuels, envisagez d’ajouter un lien de contournement de navigation — un lien visuellement masqué qui devient visible au focus et permet aux utilisateurs au clavier de passer la navigation répétitive pour aller directement au contenu principal. Les liens de contournement permettant aux utilisateurs de passer la navigation répétitive sont absents de la majorité des sites. C’est trois lignes de HTML et un petit extrait CSS, et cela fait une différence profonde pour toute personne naviguant une page riche en contenu au clavier.

<!-- Placez ceci comme tout premier élément à l’intérieur de <body> -->
<a href='#main-content' class='skip-link'>Aller au contenu principal</a>

<!-- Puis dans votre CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

Note sur ARIA : à utiliser avec précaution

De nombreuses équipes se tournent vers les attributs ARIA (Accessible Rich Internet Applications) comme solution rapide aux lacunes d’accessibilité. Les données suggèrent que cela se retourne plus souvent contre elles que cela n’aide. Environ 79% des pages d’accueil évaluées utilisaient ARIA, une augmentation par rapport à l’année précédente. Les pages d’accueil avec ARIA présentaient plus de deux fois plus d’erreurs que les pages sans ARIA. ARIA en soi n’est pas le problème — ce sont généralement les usages abusifs ou incorrects d’ARIA. De nombreux développeurs bien intentionnés pensent rendre le contenu plus accessible en ajoutant ARIA, alors qu’en réalité ils le rendent souvent moins accessible.

Le principe directeur est simple : utilisez d’abord le HTML sémantique. Un <button> est meilleur qu’un <div role='button'>. Un <nav> est meilleur qu’un <div role='navigation'>. Les éléments HTML natifs sont livrés avec un comportement clavier intégré, une gestion du focus et des rôles ARIA implicites que le balisage personnalisé vous oblige à reproduire manuellement — et c’est dans cette reproduction manuelle que les erreurs s’insinuent. Réservez ARIA aux cas où le HTML ne peut véritablement pas exprimer la sémantique dont vous avez besoin, comme les régions dynamiques, les widgets composites complexes ou les changements d’état dynamiques.

Intégrer l’accessibilité dans votre flux de travail

Corriger les violations existantes est nécessaire, mais empêcher l’apparition de nouvelles violations est ce qui distingue les programmes d’accessibilité matures des sprints de conformité ponctuels. L’accessibilité n’est pas une correction ponctuelle. Chaque mise à jour de contenu, changement de design ou déploiement de code peut introduire de nouveaux problèmes. Les six catégories d’échecs couvertes dans ce guide ont tendance à être des problèmes au niveau des gabarits — corrigez l’en-tête, le pied de page et les composants partagés et vous éliminez le problème sur des centaines de pages simultanément.

Intégrez l’analyse automatisée dans votre pipeline CI/CD afin que les violations soient détectées avant d’atteindre la production. Des outils comme axe-core peuvent être intégrés dans les tests unitaires et les suites de tests de bout en bout. Associez cela à des parcours manuels périodiques au clavier et à des tests avec lecteur d’écran — VoiceOver sur macOS et iOS, NVDA sur Windows — car les tests automatisés peuvent détecter des erreurs d’accessibilité courantes, mais les tests manuels aident à combler les lacunes. Pour les équipes qui ont besoin d’une montée en puissance plus rapide, un widget de surcouche d’accessibilité comme Accsible peut mettre en évidence et corriger une classe significative de problèmes au niveau du rendu, tandis que des correctifs plus durables au niveau du code sont planifiés et déployés.

Enfin, attaquez-vous au point de levier le plus important de votre base de code : vos gabarits. La plupart des sites web utilisent des gabarits — un en-tête, un pied de page, une navigation et une mise en page qui se répètent sur chaque page. Les problèmes dans ces gabarits se multiplient sur l’ensemble de votre site. Corrigez-les en premier pour un impact maximal. Un seul gabarit de base corrigé peut transformer 10 000 échecs WCAG en zéro en un seul déploiement.

Points clés à retenir

• Six types de problèmes dominent le paysage. Le texte à faible contraste, le texte alternatif manquant, les champs de formulaire sans libellé, les liens et boutons vides, la langue du document manquante et la navigation clavier défaillante représentent la grande majorité des échecs WCAG. Corriger ces six catégories produit des résultats disproportionnés par rapport à l’effort.
• La plupart des correctifs sont des changements CSS ou des lignes HTML uniques. Ajouter lang='en' à votre balise <html>, remplacer outline: none par des styles :focus-visible et associer des libellés aux champs sont des travaux de quelques heures, pas de plusieurs mois — et pourtant ils éliminent des échecs qui affectent chaque utilisateur en situation de handicap qui visite votre site.
• Les gabarits sont l’endroit de correction au plus fort levier. Les bugs d’accessibilité dans les composants partagés et les gabarits de page se répliquent sur l’ensemble de votre site. Auditez d’abord votre en-tête, votre pied de page, votre navigation et vos formulaires — les corriger là revient à les corriger partout.
• ARIA est un outil de dernier recours, pas une première réponse. Les sites qui s’appuient fortement sur ARIA sans une base solide en HTML sémantique ont tendance à présenter significativement plus d’erreurs d’accessibilité, pas moins. Préférez les éléments HTML natifs chaque fois que possible.
• Les analyses automatisées détectent moins de la moitié des problèmes réels. Complétez vos outils par des parcours manuels au clavier et des tests avec lecteur d’écran pour trouver les échecs qu’aucun scanner ne mettra en évidence, notamment les pièges de focus, les problèmes d’ordre logique de tabulation et le contenu dynamique qui n’annonce pas les changements.