Les WCAG 2.2 expliquées simplement

Les WCAG sont la référence mondiale pour des sites web accessibles – et le fondement de ce que le BFSG et l'EAA exigent de vous. Découvrez ici comment le standard est structuré et ce que la version 2.2 apporte de nouveau.

Que sont les WCAG – et qui les publie ?

Les Web Content Accessibility Guidelines (WCAG) sont le standard internationalement reconnu pour des contenus web accessibles. Elles sont publiées par le World Wide Web Consortium (W3C), plus précisément par sa Web Accessibility Initiative (WAI) – l'organisation qui standardise aussi HTML et CSS. La version actuelle, WCAG 2.2, est parue en octobre 2023 et s'appuie sur les WCAG 2.1 : tout ce qui valait avant reste valable, seules de nouvelles exigences se sont ajoutées (et une a été supprimée, nous y reviendrons).

Important à comprendre : les WCAG elles-mêmes ne sont pas une loi, mais une directive technique. Elles tirent leur portée juridique du fait que des lois du monde entier y renvoient – en Europe via la norme EN 301 549, sur laquelle reposent les exigences de l'European Accessibility Act (EAA) et de la loi allemande sur l'accessibilité, le Barrierefreiheitsstärkungsgesetz (BFSG).

Les quatre principes : POUR

Toutes les exigences des WCAG se rattachent à quatre principes, abrégés en anglais par POUR : Perceivable, Operable, Understandable, Robust. Qui a compris ces quatre idées comprend la logique de tout le standard.

1. Perceptible

Tous les contenus doivent être accessibles à tous les sens – au besoin par un canal de substitution. Exemples :

• Les images ont besoin de textes alternatifs pour que les lecteurs d'écran puissent les décrire (plus de détails dans l'article Bien rédiger les textes alternatifs).
• Les vidéos ont besoin de sous-titres pour les personnes qui n'entendent pas (ou mal).
• Le texte a besoin d'un contraste suffisant avec l'arrière-plan – gris clair sur blanc est tout simplement illisible pour beaucoup.

2. Utilisable

Chaque fonction doit être atteignable sans souris et ne doit mettre personne sous pression temporelle. Exemples :

• Le site entier peut être utilisé au clavier – avec Tab, Entrée et les touches fléchées.
• L'élément actuellement sélectionné est mis en évidence de façon visible, pour que l'on sache où l'on se trouve.
• Les boutons et les liens sont assez grands pour être atteints même avec des mains tremblantes ou sur un smartphone.

3. Compréhensible

Les contenus et le fonctionnement doivent être intelligibles. Exemples :

• Les formulaires expliquent les erreurs concrètement : « Veuillez saisir votre date de naissance au format JJ/MM/AAAA » plutôt que « Saisie invalide ».
• La navigation fonctionne de la même manière sur chaque page et les éléments se comportent de façon prévisible.
• Les textes sont formulés clairement – le jargon est expliqué ou évité.

4. Robuste

Les contenus doivent fonctionner avec le plus grand nombre possible de navigateurs et de technologies d'assistance. Exemples :

• Un HTML propre et sémantique : un bouton est un button, pas une boîte div cliquable.
• Les messages d'état (par exemple « Le produit a été ajouté au panier ») sont balisés de manière à ce que les lecteurs d'écran les perçoivent aussi.

Niveaux de conformité : A, AA et AAA

Chaque critère de succès des WCAG est rattaché à l'un des trois niveaux :

• A – le minimum absolu. S'il n'est pas atteint, des contenus sont complètement inaccessibles pour certains groupes.
• AA – le standard établi. C'est le niveau qu'exigent pratiquement toutes les lois dans le monde, y compris l'EAA et le BFSG via l'EN 301 549.
• AAA – le niveau le plus élevé, par exemple des vidéos en langue des signes pour tous les contenus audio. Comme objectif global pour des sites entiers, il est rarement réaliste et n'est pas non plus exigé juridiquement.

Nouveautés des WCAG 2.2 : neuf critères de succès

Les WCAG 2.2 ajoutent neuf nouveaux critères de succès. Ils visent avant tout les personnes avec des limitations motrices, avec des troubles cognitifs, et l'usage mobile :

En parallèle, un ancien critère a été supprimé : 4.1.1 Analyse syntaxique (syntaxe sans erreur) disparaît dans les WCAG 2.2, parce que les navigateurs et technologies d'assistance modernes sont devenus suffisamment tolérants aux erreurs et que le critère n'avait plus d'utilité propre.

WCAG, EN 301 549 et BFSG/EAA : quel rapport ?

La chaîne est plus simple qu'elle n'en a l'air : l'EAA est la directive européenne, le BFSG sa transposition allemande – chaque État membre de l'UE a la sienne. Tous deux exigent l'accessibilité selon la norme européenne harmonisée EN 301 549 – et celle-ci reprend pour les contenus web, en son cœur, les WCAG au niveau AA. Actuellement, l'EN 301 549 renvoie encore aux WCAG 2.1 ; la mise à jour vers la 2.2 est en cours. Qui vise aujourd'hui directement les WCAG 2.2 AA est donc du côté sûr : toutes les exigences 2.1 sont couvertes, et les prochaines aussi.

Pour savoir qui est concerné par le BFSG et l'EAA, quelles échéances s'appliquent et quelles amendes menacent, lisez l'article BFSG et EAA : qui doit être accessible, et pour quand ?

Malentendus fréquents

• « Un widget d'overlay rend mon site conforme. » Non. Les aides à l'utilisation comme les commutateurs de contraste ou les fonctions de lecture à voix haute sont un complément judicieux, mais elles ne peuvent pas corriger les problèmes de fond dans le code – textes alternatifs manquants, utilisation au clavier cassée, formulaires sans étiquettes. L'accessibilité se construit dans les fondations, pas comme une couche rapportée.
• « L'accessibilité ne concerne que les personnes aveugles. » Les WCAG couvrent aussi les limitations motrices, auditives et cognitives – et aident au passage tout le monde : de meilleurs contrastes en plein soleil, des boutons plus grands sur smartphone, des formulaires plus clairs pour chacun.
• « Un test automatique suffit. » L'expérience montre que les outils automatiques ne trouvent qu'une partie des problèmes. Savoir si un texte alternatif est pertinent ou si un piège clavier existe, seul un test manuel le révèle.

Commencer de façon pragmatique

Vous n'avez pas à traiter tous les critères d'un coup. Un démarrage réaliste :

1. État des lieux : vérifiez les pages et parcours les plus importants (accueil, contact, paiement) avec un outil automatique et au clavier. Vous trouverez un mode d'emploi dans Tester l'accessibilité de votre site.
2. Les gains rapides d'abord : contrastes, textes alternatifs, étiquettes de formulaire et focus visible se corrigent souvent avec peu d'effort – et couvrent de nombreux critères AA.
3. Prévoir les nouveaux critères 2.2 : vérifiez les tailles de cibles, les alternatives au glisser-déposer et votre processus de connexion.
4. Persévérer : ancrez l'accessibilité dans vos processus éditoriaux et de développement, pour que les nouveaux contenus ne créent pas de nouvelles barrières.