Les Web Content Accessibility Guidelines (WCAG) sont la norme internationale pour les contenus web accessibles, publiée par la Web Accessibility Initiative (WAI) du W3C. La version actuelle, WCAG 2.2, est devenue une recommandation officielle du W3C le 5 octobre 2023. Elle contient 86 critères de succès vérifiables, organisés en 4 principes et 13 règles, et chaque critère est rattaché à l'un des trois niveaux de conformité : A, AA ou AAA. Le niveau AA est l'objectif qui compte en pratique, car les législations du monde entier y adossent leurs exigences. Dans l'Union européenne, la norme harmonisée EN 301 549 renvoie aux WCAG 2.1 niveau AA, ce qui en fait la référence technique de l'European Accessibility Act et du BFSG allemand. Les WCAG 2.2 ajoutent neuf nouveaux critères de succès par rapport à la version 2.1, qui portent notamment sur les tailles minimales de cible, le focus clavier visible et la connexion sans énigme cognitive, et suppriment le critère de parsing 4.1.1, devenu obsolète.
Qui publie les Web Content Accessibility Guidelines ?
Les WCAG proviennent du World Wide Web Consortium (W3C), l'organisation qui normalise également HTML et CSS, à travers sa Web Accessibility Initiative. Les règles ont une longue histoire : les WCAG 1.0 sont parues en 1999, les WCAG 2.0 ont suivi en 2008 et sont restées la référence pendant une décennie entière, les WCAG 2.1 sont arrivées en 2018 en mettant l'accent sur les usages mobiles et la basse vision, et les WCAG 2.2 ont été publiées en octobre 2023.
Les versions 2.x sont rétrocompatibles par conception. Une page conforme aux WCAG 2.2 AA l'est aussi aux 2.1 AA et aux 2.0 AA. Cela compte, car les lois accusent souvent un retard sur la version la plus récente, et développer selon la 2.2 vous met à l'abri sur les deux tableaux.
Les quatre principes WCAG : perceptible, utilisable, compréhensible, robuste
Chaque critère de succès se rattache à l'un des quatre principes, que l'on retient par l'acronyme POUR :
- Perceptible : les utilisateurs doivent pouvoir percevoir le contenu. Exemples : alternatives textuelles pour les images, sous-titres pour les vidéos, contraste de couleur suffisant.
- Utilisable : les utilisateurs doivent pouvoir manipuler l'interface. Exemples : tout fonctionne au clavier, les utilisateurs disposent d'assez de temps, rien ne clignote de façon susceptible de provoquer des crises, les cibles sont assez grandes pour être atteintes.
- Compréhensible : le contenu et le fonctionnement doivent être compréhensibles. Exemples : langue lisible, navigation prévisible, messages d'erreur utiles dans les formulaires.
- Robuste : le contenu doit fonctionner de manière fiable avec les agents utilisateurs actuels et futurs, lecteurs d'écran compris. Exemple : des messages d'état que les technologies d'assistance peuvent annoncer.
Les principes sont volontairement neutres sur le plan technologique. Ils s'appliquent à un blog WordPress tout autant qu'à une application React ou à un PDF.
Comparaison des niveaux de conformité WCAG A, AA et AAA
| Niveau | Critères dans les WCAG 2.2 | Signification | Exemples typiques |
|---|---|---|---|
| A | 31 | Minimum absolu. Ne pas les respecter exclut des groupes entiers d'utilisateurs. | Texte alternatif des images, utilisation au clavier, absence de pièges au clavier |
| AA | 24 | L'objectif standard, celui auquel renvoient les lois dans le monde entier. | Contraste 4,5:1, focus visible, navigation cohérente, suggestions après erreur |
| AAA | 31 | Niveau le plus élevé, un idéal pour la plupart des sites. | Contraste 7:1, langue des signes pour les vidéos, exigences de niveau de lecture |
La conformité est cumulative : AA signifie que vous respectez tous les critères de niveau A et tous ceux de niveau AA. Le W3C lui-même indique qu'une conformité AAA complète ne devrait pas être exigée comme politique générale, car certains critères AAA ne peuvent tout simplement pas être satisfaits pour tous les types de contenu. Personne n'attend une interprétation en langue des signes sur le site d'une boulangerie. Certains critères AAA méritent tout de même d'être adoptés là où ils s'y prêtent, le rapport de contraste renforcé étant l'un des plus populaires.
Combien de critères de succès comptent les WCAG 2.2 ?
Les WCAG 2.2 comportent 86 critères de succès : 31 au niveau A, 24 au niveau AA et 31 au niveau AAA. À titre de comparaison, les WCAG 2.1 en comptaient 78. Le calcul tombe juste parce que la version 2.2 ajoute neuf critères et en supprime un : le 4.1.1 Parsing, vestige de l'époque où un HTML mal formé pouvait réellement faire planter un lecteur d'écran. Les navigateurs et les technologies d'assistance modernes analysent le HTML de la même manière, si bien que ce critère était devenu obsolète.
Quelles sont les nouveautés des WCAG 2.2 ? Les neuf nouveaux critères de succès
Les ajouts de la version 2.2 se concentrent sur les utilisateurs présentant des limitations motrices et cognitives et, honnêtement, la plupart relèvent simplement d'une bonne UX :
- 2.4.11 Focus Not Obscured (Minimum), AA : l'élément qui a le focus ne doit pas être entièrement masqué par un en-tête fixe, une bannière de cookies ou un widget de chat.
- 2.4.12 Focus Not Obscured (Enhanced), AAA : l'élément qui a le focus ne doit pas être masqué du tout, pas même partiellement.
- 2.4.13 Focus Appearance, AAA : l'indicateur de focus doit respecter des exigences minimales de taille et de contraste.
- 2.5.7 Dragging Movements, AA : tout ce qui repose sur le glisser-déposer doit disposer d'une alternative utilisable par simple clic ou appui.
- 2.5.8 Target Size (Minimum), AA : les cibles de clic et de toucher doivent mesurer au moins 24 sur 24 pixels CSS ou disposer d'un espacement suffisant autour d'elles.
- 3.2.6 Consistent Help, A : les options d'aide telles que les liens de contact ou le chat doivent apparaître au même endroit sur chaque page.
- 3.3.7 Redundant Entry, A : n'obligez pas les utilisateurs à saisir deux fois la même information au sein d'un même processus. « Adresse de livraison identique à l'adresse de facturation » doit être une case à cocher, pas un second formulaire.
- 3.3.8 Accessible Authentication (Minimum), AA : la connexion ne doit pas dépendre d'une énigme cognitive. Recopier des caractères déformés ou résoudre un jeu de mémoire est exclu, et les gestionnaires de mots de passe ainsi que le collage doivent fonctionner.
- 3.3.9 Accessible Authentication (Enhanced), AAA : la même règle, sans les exceptions que le 3.3.8 tolère encore.
Quel niveau WCAG la loi exige-t-elle ?
Dans l'Union européenne, la norme harmonisée EN 301 549 définit les exigences techniques à la fois pour les règles du secteur public et pour l'European Accessibility Act, et elle renvoie actuellement aux WCAG 2.1 niveau AA. Cela fait des WCAG 2.1 AA la référence légale formelle pour le BFSG allemand et la BITV 2.0. Une mise à jour de l'EN 301 549 vers les WCAG 2.2 est attendue, ce qui explique précisément pourquoi développer dès aujourd'hui selon la 2.2 est le choix pragmatique : vous satisfaites en même temps à l'exigence actuelle et à celle qui se profile.
Le tableau est comparable ailleurs. Aux États-Unis, le ministère de la Justice a finalisé en 2024 une règle imposant aux administrations locales et fédérées de respecter les WCAG 2.1 AA au titre de l'ADA Title II, et les tribunaux utilisent régulièrement les WCAG comme référence dans les procès ADA entre parties privées. Si vous ne retenez qu'une chose de cette section, retenez celle-ci : le niveau WCAG AA est celui que la loi vise lorsqu'elle dit « accessible ».
À quoi ressemblent les critères de succès WCAG en pratique ?
Trois exemples montrent à quel point les critères sont concrets. Le critère 1.4.3 Contrast (Minimum) exige un rapport de contraste d'au moins 4,5:1 entre un texte normal et son arrière-plan, et de 3:1 pour les grands textes. Ce texte de pied de page gris sur blanc en #999999 sur #ffffff ? Il échoue à 2,85:1. Le critère 2.1.1 Keyboard impose que toutes les fonctionnalités soient utilisables sans souris, et c'est là que la plupart des menus déroulants et carrousels d'images sur mesure cassent discrètement. Quant au critère 1.1.1 Non-text Content, c'est la règle classique du texte alternatif :
<!-- Image informative : décrire ce qu'elle montre -->
<img src="warehouse.jpg" alt="Employé scannant des colis dans l'entrepôt">
<!-- Image décorative : alt vide pour que les lecteurs d'écran l'ignorent -->
<img src="divider.svg" alt="">Chaque critère du document officiel renvoie à des techniques et à des exemples d'échec, et la référence rapide des WCAG permet de filtrer les 86 critères par niveau et par technologie, ce qui est bien plus praticable que de lire la spécification de bout en bout.
Comment tester la conformité aux WCAG 2.2 ?
Commencez par les outils automatisés : WAVE, axe DevTools, Lighthouse ou les contrôles d'accessibilité intégrés à InspectWP détectent en quelques secondes les attributs alt manquants, les défauts de contraste, les étiquettes absentes et les problèmes de structure. Gardez toutefois leurs limites en tête. Les contrôles automatisés repèrent de façon fiable entre un tiers et la moitié des manquements aux WCAG, car de nombreux critères demandent un jugement humain. Une machine voit qu'une image possède un texte alternatif, mais pas si ce texte décrit réellement l'image.
Complétez donc le tableau manuellement : débranchez votre souris et parcourez tout le site au clavier, menez une session avec un lecteur d'écran comme NVDA (gratuit) ou VoiceOver, zoomez la page à 200 pour cent, et déroulez votre parcours utilisateur le plus important, en général la commande ou la prise de contact, du début à la fin. Si vous le pouvez, associez des personnes en situation de handicap aux tests. Elles trouveront en dix minutes des problèmes qu'aucune liste de contrôle d'audit ne fait remonter.
Que se passera-t-il après les WCAG 2.2 ? Un rapide coup d'œil aux WCAG 3.0
Le W3C travaille sur les WCAG 3.0, une réécriture complète assortie d'un nouveau modèle de notation qui s'éloigne de la logique binaire réussite ou échec. Le texte est à l'état de brouillon depuis des années et le restera encore des années, et le W3C indique explicitement qu'il ne remplacera pas la version 2.2 avant longtemps. Pour vos arbitrages : l'objectif reste les WCAG 2.2 AA, et rien de ce qui concerne la 3.0 ne devrait modifier votre feuille de route aujourd'hui.
Comment InspectWP contrôle-t-il les critères WCAG ?
InspectWP intègre des contrôles d'accessibilité automatisés à ses rapports de site web et rattache les manquements courants aux critères WCAG sous-jacents : textes alternatifs manquants, contraste de couleur insuffisant, champs de formulaire sans étiquette, langue du document absente et hiérarchie de titres cassée, entre autres. Chaque constat est assorti d'un niveau de gravité, ce qui vous permet de corriger d'abord les blocages de niveau A puis de progresser vers le niveau AA. Associé à des rapports planifiés, cela transforme l'accessibilité d'un audit ponctuel en un sujet que vous suivez réellement, ce que l'European Accessibility Act attend de toute façon de vous.