WCAG : Web Content Accessibility Guidelines expliquées

Que sont les Web Content Accessibility Guidelines (WCAG) ?

Les Web Content Accessibility Guidelines (WCAG, ou « Règles pour l'accessibilité des contenus Web ») sont la norme technique du W3C pour rendre le contenu web utilisable par les personnes en situation de handicap. Elles reposent sur quatre principes, des critères de succès vérifiables et trois niveaux de conformité (A, AA, AAA). La version actuelle est WCAG 2.2, à laquelle renvoient la plupart des règles d'accessibilité et des cahiers des charges.

Les WCAG sont rédigées par le groupe de travail Accessibility Guidelines du W3C, au sein de la Web Accessibility Initiative. Elles couvrent les sites et applications web et décrivent le contenu reçu par l'utilisateur, pas un framework ou un outil particulier.

Les quatre principes : POUR

Chaque critère de succès relève de l'un de quatre principes, connus sous l'acronyme anglais POUR :

• Perceptible : l'information doit être présentée de façon à être perçue, par exemple avec des alternatives textuelles pour les images, des sous-titres pour les vidéos et un contraste de couleurs suffisant.
• Utilisable : toutes les fonctions s'utilisent au clavier, le temps est suffisant, rien ne provoque de crises et la navigation est claire.
• Compréhensible : les textes sont lisibles, les pages se comportent de façon prévisible et les formulaires aident à éviter et corriger les erreurs.
• Robuste : le contenu fonctionne avec les navigateurs et technologies d'assistance actuels et futurs, et expose correctement nom, rôle et valeur.

Niveaux de conformité A, AA et AAA

• Niveau A est le minimum : les images ont une alternative textuelle, les vidéos des sous-titres, tout est accessible au clavier.
• Niveau AA est la cible habituelle. Il inclut un contraste de 4,5:1 pour le texte normal (3:1 pour le grand texte), 3:1 pour les composants d'interface et les graphiques et, nouveauté de la 2.2, des cibles de pointeur d'au moins 24 sur 24 pixels CSS (ou un espacement suffisant autour des plus petites).
• Niveau AAA ajoute des critères plus stricts. Le W3C ne recommande pas de l'exiger pour des sites entiers, car certains critères ne peuvent pas être satisfaits pour tous les contenus.

La conformité s'évalue page par page : une page ne respecte un niveau que si elle satisfait tous les critères de ce niveau et des niveaux inférieurs.

Versions des WCAG : 2.0, 2.1, 2.2 et 3.0

• WCAG 2.0 a été publiée en décembre 2008.
• WCAG 2.1 (juin 2018) a ajouté 17 critères de succès, surtout pour le mobile, la basse vision et les besoins cognitifs.
• WCAG 2.2 est une Recommandation du W3C (mise à jour en décembre 2024). Elle ajoute 9 critères de succès, dont Focus non masqué, Mouvements de glissement, Taille de la cible (minimum), Aide cohérente, Saisie redondante et Authentification accessible, et supprime 4.1.1 Analyse syntaxique, devenu obsolète.
• WCAG 3.0 reste un document de travail (10 septembre 2026 à la rédaction). Le W3C précise qu'elle ne remplace pas WCAG 2 : il faut donc continuer à viser la 2.2.

Le W3C a conçu les versions 2.0, 2.1 et 2.2 pour être rétrocompatibles : un contenu conforme à la 2.2 l'est aussi à la 2.1 et à la 2.0. Le texte complet est disponible dans la Recommandation WCAG 2.2 (en anglais).

Un exemple concret

Un bouton « Acheter maintenant » utilise du texte gris clair (#999999) sur fond blanc. Le rapport de contraste est d'environ 2,8:1 : il échoue au critère 1.4.3 (Contraste minimum) au niveau AA, même s'il paraît correct sur un écran lumineux. Avec #767676, on obtient environ 4,5:1 et c'est validé. Ce même bouton doit aussi avoir un indicateur de focus visible, une cible d'au moins 24 sur 24 pixels CSS et un nom accessible qui correspond à son libellé visible.

Les échecs les plus fréquents

L'analyse WebAIM Million 2026, menée sur un million de pages d'accueil, a détecté des échecs WCAG 2 sur 95,9 % d'entre elles. Les plus courants : texte à faible contraste (83,9 % des pages), images sans texte alternatif (53,1 %), champs de formulaire sans étiquette (51 %), liens vides (46,3 %), boutons vides (30,6 %) et langue du document absente (13,5 %). Ils se corrigent à peu de frais et font un bon premier sprint.

Erreurs courantes

• Traiter l'accessibilité comme une liste de fin de projet. Intégrer contraste, états de focus et HTML sémantique dès le système de design coûte bien moins cher.
• S'en remettre aux seuls scanners automatiques. Les tests automatisés ne détectent que ce qu'une règle peut vérifier, comme un attribut alt manquant. Ils ne jugent pas si un texte alternatif est pertinent ni si l'ordre de lecture a du sens : ajoutez des tests manuels au clavier et avec un lecteur d'écran.
• Utiliser ARIA à la place du HTML natif. Un vrai <button> apporte clavier et prise en charge des lecteurs d'écran. Un <div role="button"> oblige à tout reconstruire.
• Confondre rapport et conformité. Un VPAT ou un rapport de conformité d'accessibilité (ACR) documente seulement ce qui a été testé. Il ne rend pas une page accessible.

Les WCAG dans votre routine de tests

Vérifiez les WCAG en même temps que les performances : ce sont deux régressions à détecter avant vos utilisateurs. Page Speed Monitoring de LoadFocus lance des audits Google Lighthouse planifiés depuis 25 régions cloud, et chaque audit inclut la catégorie Accessibilité de Lighthouse. Vous obtenez ainsi la tendance de la partie automatisable des WCAG. Ce n'est pas un audit d'accessibilité complet et cela ne remplace pas les tests manuels. Pour aller plus loin, lisez sur le blog (en anglais) pourquoi les tests de performance doivent inclure des métriques d'accessibilité.

Questions fréquentes sur les WCAG

Les WCAG sont-elles obligatoires légalement ?

Souvent de façon indirecte. Des textes comme la directive européenne sur l'accessibilité des sites web (secteur public) renvoient aux WCAG via la norme EN 301 549, et l'Acte européen sur l'accessibilité, applicable depuis le 28 juin 2025, couvre des services comme le commerce en ligne et la banque. La version et le niveau de WCAG cités varient selon le pays et le secteur : vérifiez la règle qui vous concerne.

Quelle version des WCAG viser ?

WCAG 2.2 niveau AA. C'est la Recommandation en vigueur et, étant rétrocompatible, la respecter revient à respecter la 2.1 et la 2.0. WCAG 3.0 est un brouillon et ne remplace pas WCAG 2.

Quelle différence entre A, AA et AAA ?

Ce sont des niveaux d'exigence cumulatifs. A est le minimum, AA ajoute des critères comme le contraste de texte de 4,5:1 et constitue la cible légale et contractuelle habituelle, et AAA est le plus strict, généralement appliqué à certains contenus seulement.

Un outil automatique peut-il confirmer que mon site est conforme aux WCAG ?

Non. Des outils comme Lighthouse vérifient les règles détectables dans le code. Un texte alternatif pertinent, un ordre de focus logique ou des messages d'erreur clairs doivent être évalués par une personne avec un clavier et un lecteur d'écran.

Qu'est-ce qui a changé dans WCAG 2.2 ?

Neuf critères de succès ont été ajoutés, dont une taille de cible minimale de 24 sur 24 pixels, la règle selon laquelle un élément ayant le focus ne doit pas être masqué par un en-tête fixe, des alternatives au glissement et l'authentification accessible. Le critère obsolète 4.1.1 Analyse syntaxique a été supprimé.