Les WCAG expliquées simplement

Quiconque s’intéresse à l’accessibilité web finit par croiser quatre lettres : WCAG. Un webdesigner affirme que le site « respecte les WCAG 2.1 AA », une loi y renvoie, un appel d’offres l’exige, un rapport liste des manquements. Les WCAG peuvent ressembler à un épais règlement technique réservé aux spécialistes. En pratique, elles décrivent des choses ordinaires : des images décrites, un texte lisible, des formulaires qu’on remplit au clavier, des pages qui se comportent comme on s’y attend. Cet article explique ce que sont les WCAG, quelle version et quel niveau comptent, ce qui a changé récemment et comment vous en servir sans lire tout le document.

Que sont les WCAG ?

WCAG signifie Web Content Accessibility Guidelines, en français règles pour l’accessibilité des contenus web. Elles sont publiées par le W3C, l’organisation internationale qui élabore les standards du web, au sein de sa Web Accessibility Initiative (présentation du W3C). Elles sont gratuites à lire et à utiliser.

Les WCAG sont organisées en couches :

Quatre principes au sommet : le contenu doit être perceptible, utilisable, compréhensible et robuste. Nous y revenons plus bas.
Des règles sous chaque principe, comme « rendre le texte lisible » ou « laisser suffisamment de temps ».
Des critères de succès sous chaque règle. Ce sont les exigences proprement dites, rédigées pour pouvoir être testées : une page les respecte ou non. Chacun porte un numéro, comme 1.1.1, et un nom court, comme « Contenu non textuel ».

Les WCAG ne dépendent d’aucune technologie particulière. Elles décrivent des résultats, comme « chaque champ de formulaire a une étiquette qui dit à quoi il sert », et non la façon de les obtenir. C’est pourquoi elles s’appliquent aussi bien à un site codé à la main qu’à un thème WordPress ou à une page créée avec un outil d’IA. La version 2.2 est aussi une norme internationale, ISO/IEC 40500:2025 (annonce du W3C).

Les versions : 2.0, 2.1 et 2.2

Les WCAG ont évolué pas à pas, et chaque version complète la précédente.

Les WCAG 2.0 (2008) ont posé les bases.
Les WCAG 2.1 (2018) ont ajouté des exigences pour les appareils mobiles, les personnes malvoyantes et les personnes ayant un handicap cognitif ou des troubles de l’apprentissage. Par exemple : un contenu utilisable en mode portrait comme en mode paysage, et un texte qui reste lisible quand on augmente l’espacement.
Les WCAG 2.2 (octobre 2023) ont ajouté neuf nouveaux critères de succès, surtout sur le focus clavier, les cibles tactiles, la connexion et l’aide. Un ancien critère sur la syntaxe du code, « Analyse syntaxique » (Parsing), a été retiré parce que les navigateurs modernes l’ont rendu inutile (nouveautés des WCAG 2.2).

Comme les versions s’empilent, le W3C les a conçues pour qu’un site conforme aux WCAG 2.2 le soit aussi aux versions 2.1 et 2.0. Si vous démarrez maintenant, visez la 2.2.

Vous entendrez peut-être parler des WCAG 3. Il s’agit d’une refonte complète que le W3C est encore en train de rédiger. C’est un brouillon de travail, pas un standard terminé, et il faudra des années avant que les lois y renvoient (introduction aux WCAG 3). Pour l’instant, ce sont les WCAG 2 qui comptent.

Les niveaux A, AA et AAA

Chaque critère de succès a un niveau.

Le niveau A couvre l’essentiel. Sans lui, certaines personnes ne peuvent pas utiliser la page du tout. Exemples : les images ont une alternative textuelle, tout fonctionne au clavier, il n’y a pas de piège au clavier (un endroit que l’on ne peut plus quitter avec le clavier) et les vidéos ont des sous-titres.
Le niveau AA ajoute ce qui rend un site confortable pour beaucoup plus de monde. Exemples : le texte est assez contrasté par rapport au fond, les pages fonctionnent encore avec un zoom à 200 %, le focus clavier est visible, et les titres et étiquettes décrivent leur sujet.
Le niveau AAA est le plus exigeant. Exemples : un contraste encore plus élevé, la langue des signes pour les vidéos et un texte compréhensible avec un niveau de lecture de fin de collège.

Les niveaux s’additionnent. Pour atteindre le niveau AA, une page doit respecter tous les critères A et tous les critères AA. Dans les WCAG 2.2, cela fait 55 critères. Le niveau AAA est une bonne source d’idées supplémentaires, mais le W3C lui-même déconseille de l’exiger pour des sites entiers, car certains contenus ne peuvent tout simplement pas satisfaire chaque critère AAA.

Quand on parle de « WCAG AA », on désigne les niveaux A et AA ensemble. C’est le niveau que demandent presque toutes les lois et tous les contrats.

Les quatre principes, avec des exemples du quotidien

Chacun des quatre principes répond à une question simple sur vos visiteurs.

Perceptible : les gens peuvent-ils percevoir le contenu ?

L’information doit atteindre les gens par au moins un sens qu’ils peuvent utiliser. Un visiteur aveugle entend un lecteur d’écran (un logiciel qui lit l’écran à voix haute) : les photos ont donc besoin d’une courte description, appelée texte alternatif. Un visiteur sourd a besoin de sous-titres sur votre vidéo. Une personne malvoyante a besoin d’un texte bien contrasté et d’une page qui ne se casse pas quand le texte est agrandi. Et la couleur seule ne suffit pas : un formulaire qui signale les erreurs uniquement par une bordure rouge ne dit rien à un visiteur daltonien.

Utilisable : les gens peuvent-ils s’en servir ?

Chaque fonction doit pouvoir s’utiliser de plus d’une façon. Une personne qui ne peut pas utiliser de souris parcourt votre site avec la touche Tab : chaque lien, bouton et menu doit être atteignable et montrer où se trouve le clavier. Les personnes qui lisent lentement ont besoin de temps : une session ne doit pas expirer sans prévenir. Un contenu ne doit pas clignoter plus de trois fois par seconde, car les flashs peuvent déclencher des crises d’épilepsie. Et des titres de page et de section clairs aident tout le monde à s’orienter.

Compréhensible : les gens s’y retrouvent-ils ?

La page doit parler la langue du visiteur, au sens propre (la langue de la page est indiquée, pour qu’un lecteur d’écran prononce correctement les mots) comme au sens figuré (des mots clairs, des phrases courtes). Les pages se comportent de façon prévisible : un menu reste au même endroit, choisir une option ne vous envoie pas soudain vers une autre page. Les formulaires disent ce qu’ils attendent et, en cas d’erreur, expliquent quoi corriger et comment : « Saisissez une date comme 14/03/2026 » aide, « Saisie invalide » non.

Robuste : cela fonctionne-t-il avec les outils des gens ?

Votre site doit fonctionner avec les navigateurs et les aides techniques, aujourd’hui comme demain. En pratique, cela veut dire utiliser de vrais boutons, de vrais liens et de vrais champs de formulaire, avec des noms que les logiciels peuvent lire. Un « bouton » qui n’est qu’une boîte colorée réagissant au clic de souris a l’air correct, mais un lecteur d’écran ne l’annonce pas et le clavier ne l’atteint pas.

Quel niveau la loi exige-t-elle ?

Dans l’Union européenne, deux textes comptent surtout pour les sites web. La directive sur l’accessibilité des sites web du secteur public couvre les sites et applications des organismes publics. L’acte européen sur l’accessibilité (European Accessibility Act), applicable depuis le 28 juin 2025, couvre de nombreux services privés, comme les boutiques en ligne, la banque, les transports et les livres numériques. Tous deux passent par une norme européenne, l’EN 301 549. Pour les sites web, cette norme reprend les critères de succès des WCAG aux niveaux A et AA.

La version utilisée aujourd’hui, l’EN 301 549 V3.2.1, renvoie aux WCAG 2.1 niveau AA. Une nouvelle version, la V4.1.1, a été publiée en septembre 2026. Elle est alignée sur les WCAG 2.2 niveau AA et comporte une partie rédigée spécialement pour l’acte européen sur l’accessibilité. Elle deviendra la référence juridique une fois citée par la Commission européenne au Journal officiel de l’UE, ce qui est attendu vers la fin de 2026 (Level Access).

Les lois nationales s’appuient sur ce socle. En Belgique, la loi du 5 novembre 2023 transpose l’acte européen sur l’accessibilité, sous le contrôle du SPF Economie. En France, l’obligation d’accessibilité découle notamment de la loi de 2005, et le RGAA (référentiel général d’amélioration de l’accessibilité) traduit ces exigences en critères concrets. Sa version en vigueur, le RGAA 4.1, repose sur les WCAG 2.1, et une version 5 fondée sur les WCAG 2.2 a été annoncée.

Alors, que viser pour une petite entreprise ou un organisme public ? Les WCAG 2.1 AA correspondent à ce que la loi demande aujourd’hui. Les WCAG 2.2 AA reprennent tout le contenu des 2.1 AA (hormis le critère retiré sur l’analyse syntaxique) et ajoutent six nouveaux critères : c’est la direction que prend la loi. Si vous créez ou refaites un site, visez les 2.2 AA pour ne pas devoir y revenir de sitôt.

Ce qui change avec les WCAG 2.2 pour les petits sites

Six des nouveaux critères sont de niveau A ou AA. Chacun règle un problème que les gens rencontrent tous les jours.

Focus non masqué. Quand on parcourt une page au clavier, l’élément sur lequel on se trouve ne doit pas disparaître entièrement derrière un en-tête fixe, un bouton de discussion ou un bandeau de cookies.
Taille de la cible. Les boutons et liens sur lesquels on appuie mesurent au moins 24 pixels sur 24, ou disposent d’assez d’espace autour, pour que les personnes dont la main tremble ne touchent pas le mauvais. Les liens au milieu d’une phrase font exception.
Mouvements de glissement. Tout ce qui demande de faire glisser, comme un curseur, une carte ou le réordonnancement d’éléments, doit aussi fonctionner par simples clics ou appuis.
Aide cohérente. Si vous proposez de l’aide, comme un numéro de téléphone, un lien de contact ou une discussion en ligne, placez-la au même endroit sur chaque page.
Saisie redondante. Ne demandez pas de saisir deux fois la même chose dans un même processus. Si un client a saisi son adresse à l’étape un, remplissez-la à l’étape trois ou proposez-la, par exemple avec une case « Identique à l’adresse de livraison ».
Authentification accessible. La connexion ne doit pas dépendre de la mémorisation ou de la recopie d’une information sans aide, ni de la résolution d’une énigme. Autorisez le copier-coller et les gestionnaires de mots de passe, ou proposez un lien de connexion par e-mail. Les énigmes de reconnaissance d’images et les contenus personnels sont des exceptions admises au niveau AA, mais des options plus simples sont plus aimables.

Deux d’entre eux se règlent souvent avec quelques lignes de CSS (le code qui définit l’apparence d’un site) :

/* Garder l’élément qui a le focus visible sous un en-tête fixe de 80px */
html {
  scroll-padding-top: 80px;
}

/* Donner aux petits boutons-icônes une zone d’appui confortable */
.icon-button {
  min-width: 44px;
  min-height: 44px;
}

Et le problème de connexion le plus courant est un champ de mot de passe qui bloque le collage :

<!-- À éviter : bloque les gestionnaires de mots de passe et le collage -->
<input type="password" onpaste="return false" />

<!-- Mieux : laisse les gestionnaires de mots de passe remplir le champ -->
<input type="password" autocomplete="current-password" />

Utiliser les WCAG sans tout lire

Inutile de lire la norme en entier. Quelques habitudes vous mènent déjà loin.

Partez des tâches principales de vos visiteurs. Trouver une information, réserver, payer, vous contacter. Vérifiez que chaque tâche aboutit, plutôt que de cocher chaque critère dans l’abstrait.
Utilisez la référence rapide du W3C. How to Meet WCAG présente chaque critère avec de courtes explications et des exemples, et permet de filtrer par niveau. Filtrez sur A et AA et masquez le reste.
Corrigez d’abord les problèmes les plus fréquents. Dans l’analyse 2026 de WebAIM portant sur un million de pages d’accueil, les manquements les plus fréquents étaient le texte trop peu contrasté, les images sans description, les champs de formulaire sans étiquette, les liens vides, les boutons vides et l’absence de langue de la page (WebAIM Million). Nos guides de correction couvrent chacun d’eux.
En cas de doute, lisez la page « Understanding ». Chaque critère a une page qui explique son objectif, à qui il profite, avec des exemples. Votre développeur y trouvera aussi les techniques.
Mettez-le par écrit. Quand vous faites appel à un designer, un développeur ou une agence, ou choisissez un thème, demandez explicitement « WCAG 2.2 niveau AA » et demandez comment ce sera testé.
Consignez-le dans une déclaration. Une déclaration d’accessibilité indique quel référentiel vous suivez, ce que vous avez vérifié et ce qui reste à faire. Notre guide de la déclaration d’accessibilité explique comment faire.

Le lien entre vérifications automatiques et WCAG

Les outils de vérification automatique, dont ibin, testent les pages sur les critères de succès des WCAG qu’un logiciel peut évaluer de façon fiable. Y a-t-il une alternative textuelle ? Le texte est-il assez contrasté ? Chaque champ a-t-il une étiquette ? La langue de la page est-elle indiquée ? Ces vérifications sont rapides et reproductibles, et elles repèrent beaucoup des manquements les plus courants.

Mais de nombreux critères demandent un regard humain. Un logiciel voit qu’une image a un texte alternatif, mais pas si « photo123 » ou « image » la décrit. Il peut vérifier qu’une page a des titres, mais pas s’ils décrivent le contenu. Il ne peut pas dire si vos consignes sont claires ni si un menu fonctionne vraiment au clavier. Les vérifications automatiques trouvent environ un tiers à la moitié des problèmes ; des personnes doivent vérifier le reste.

Une bonne routine combine les deux. Lancez une vérification automatique, corrigez ce qu’elle trouve, puis faites le test clavier en dix minutes et relisez vos descriptions d’images et vos textes de liens avec un œil neuf. Le second regard optionnel de l’IA dans ibin note notamment les descriptions d’images, les textes de liens et l’utilisation au clavier, pour que vous sachiez où regarder en premier. Ce sont des pistes, pas des verdicts. Et aucun outil ne peut certifier qu’un site respecte les WCAG : il faut pour cela un examen complet mené par des personnes.

Vérifiez une page sur l’essentiel

Vérifiez gratuitement une page avec ibin pour voir quels problèmes WCAG les vérifications automatiques détectent, expliqués en langage simple, avec une image de l’endroit où se trouve chaque problème et un guide pour le corriger. Commencez par votre page d’accueil ou votre formulaire le plus important, corrigez d’abord les problèmes critiques et vérifiez à nouveau.

Voyez où en est votre site

Vérifiez gratuitement une page, sans compte. Vous recevez une liste claire de ce qu’il faut corriger en premier, avec des images de l’endroit où se trouve chaque problème.