Accessibilité de site web : un guide pratique WCAG 2.2
Comment lire les WCAG 2.2 pour votre propre site, les corrections qui couvrent la plupart des échecs réels, un test manuel de 30 minutes que tout le monde peut faire, et comment accessibilité et utilisabilité se chevauchent.
Questions fréquentes
Que signifie qu'un site web soit conforme WCAG ?
Cela signifie que le site répond aux critères de succès des Web Content Accessibility Guidelines à un niveau choisi, généralement WCAG 2.1 ou 2.2 niveau AA. Le niveau AA inclut chaque critère de niveau A et AA. La plupart des lois et politiques d'achat qui référencent les WCAG demandent le niveau AA.
Comment devrais-je interpréter les directives WCAG pour mon site ?
Commencez par le guide rapide « How to Meet WCAG » du W3C, filtrez aux niveaux A et AA, et pour chaque critère lisez la page « Understanding », qui explique l'intention en langage simple. Puis testez vos modèles clés (accueil, une page de contenu, un formulaire, le paiement) plutôt que chaque page individuellement.
Une surcouche ou un plugin d'accessibilité peut-il rendre mon site conforme ?
Aucun outil ne peut rendre un site conforme à lui seul. Les surcouches qui ajoutent une barre d'outils ne corrigent pas le code sous-jacent, et de nombreux utilisateurs handicapés et spécialistes de l'accessibilité rapportent qu'elles gênent. Corrigez directement le HTML, le contraste, les étiquettes et le support clavier.
Quelle est la différence entre utilisabilité et accessibilité ?
L'accessibilité signifie que les personnes handicapées peuvent percevoir, comprendre, naviguer et interagir avec le site. L'utilisabilité signifie que le site est facile et efficace pour tout le monde. Elles se chevauchent énormément : des étiquettes claires, un bon contraste et une navigation prévisible aident tous les visiteurs, pas seulement ceux en situation de handicap.
Les vérificateurs automatisés trouvent-ils tous les problèmes d'accessibilité ?
Non. Des outils comme WAVE, axe et Lighthouse détectent des problèmes comme le texte alternatif manquant, le faible contraste et les étiquettes manquantes, mais de nombreux critères, comme si le texte alternatif est pertinent ou si l'ordre de focus a du sens, ont besoin d'un humain pour vérifier.
Un site web conforme WCAG répond aux Web Content Accessibility Guidelines à un niveau choisi, et pour presque toute entreprise cela signifie WCAG 2.2 niveau AA. En pratique, la plupart des sites échouent sur la même poignée de problèmes : faible contraste de couleur, texte alternatif d'image manquant, champs de formulaire sans étiquette, liens et boutons vides, et des choses que vous ne pouvez pas atteindre au clavier. Corrigez cela et testez avec un clavier et un lecteur d'écran, et vous aurez couvert une grande part de ce à quoi se heurtent les vrais utilisateurs.
Ce guide explique comment lire les WCAG sans se perdre, les corrections les plus importantes, et un test de 30 minutes que vous pouvez faire vous-même.
Comment les WCAG sont structurées
Les WCAG sont publiées par le W3C. Elles sont organisées en couches :
Quatre principes, connus sous POUR : le contenu doit être Perceptible, Opérable, Utilisable et Robuste (POUR en anglais, ou PECR).
Des directives sous chaque principe (par exemple, « Alternatives textuelles » ou « Accessible au clavier »).
Des critères de succès sous chaque directive. Ce sont les règles testables, chacune numérotée (comme 1.4.3 Contraste) et dotée d'un niveau : A, AA ou AAA.
Le niveau A est le minimum. Le niveau AA est la cible courante pour les exigences légales et d'achat. Le niveau AAA est plus strict et généralement pas requis pour des sites entiers.
WCAG 2.2 est devenu une Recommandation du W3C en octobre 2023. Il a ajouté des critères comme la taille minimale de cible, le focus non obscurci, et l'authentification accessible, et il a retiré 4.1.1 Analyse syntaxique comme obsolète.
Comment interpréter les WCAG pour votre propre site
La spécification se lit comme une norme, parce que c'en est une. Un moyen pratique de la parcourir :
Ouvrez le « How to Meet WCAG (Quick Reference) » du W3C.
Filtrez-le aux niveaux A et AA seulement.
Pour chaque critère, lisez la page « Understanding » liée. Elle explique l'intention en langage simple, avec des exemples de réussite et d'échec.
Au lieu de tester chaque page, testez vos modèles : page d'accueil, une page de contenu standard, un article de blog, un formulaire, une page produit ou de paiement. Corriger un modèle corrige chaque page construite dessus.
Enregistrez chaque problème avec le numéro du critère, la page, et à quoi ressemble une correction.
Les corrections qui couvrent la plupart des échecs réels
1. Contraste de couleur (1.4.3 et 1.4.11)
Texte normal : au moins 4.5:1 contre son arrière-plan.
Grand texte (environ 24px normal, ou 18,66px gras et plus) : au moins 3:1.
Composants d'interface et graphiques significatifs (bordures de boutons, contours de champs, icônes qui transmettent une information) : au moins 3:1.
Le texte de substitution gris clair et le texte blanc sur des couleurs de marque pâles sont les coupables habituels. Vérifiez avec le vérificateur de contraste de WebAIM ou les outils de développement de votre navigateur.
2. Alternatives textuelles pour les images (1.1.1)
Les images informatives reçoivent un texte alternatif décrivant ce qui compte : alt="Technicien remplaçant un filtre de chaudière".
Les images décoratives reçoivent un alt vide : alt="", pour que les lecteurs d'écran les sautent.
Les images de texte (une capture d'écran de flyer, un menu en JPG) ont besoin du même texte disponible en vrai texte.
Les images liées, comme un logo qui ramène à l'accueil, décrivent la destination : alt="Accueil Acme Plomberie".
3. Étiquettes de formulaire et erreurs (1.3.1, 3.3.1, 3.3.2)
Chaque champ a besoin d'une <label> visible qui lui est liée. Le texte de substitution n'est pas une étiquette : il disparaît quand vous tapez.
Les messages d'erreur disent ce qui a mal tourné et comment le corriger (« Entrez un numéro de téléphone avec l'indicatif »), en texte, pas seulement une bordure rouge.
Les champs requis sont marqués en texte ou avec un indicateur accessible, pas seulement par la couleur.
4. Accès clavier (2.1.1, 2.4.3, 2.4.7)
Chaque lien, bouton, menu et contrôle de formulaire doit fonctionner avec Tab, Maj+Tab, Entrée et Espace.
L'ordre de focus suit l'ordre visuel.
Un indicateur de focus visible montre où vous êtes. Retirer le contour du navigateur avec outline: none sans remplacement est un échec courant.
Les menus déroulants et modales doivent s'ouvrir, fonctionner et se fermer au clavier, et les modales devraient garder le focus à l'intérieur jusqu'à leur fermeture.
5. Liens et boutons avec des noms (2.4.4, 4.1.2)
Les boutons icône seule (un menu hamburger, une loupe de recherche, des icônes sociales) ont besoin d'un nom accessible, via un texte visible, aria-label ou du texte caché.
Évitez une page pleine de liens « Cliquez ici » et « Lire la suite ». Faites en sorte que le texte du lien décrive la destination, ou donnez à chacun un nom accessible distinct.
6. Structure et titres (1.3.1, 2.4.6)
Un seul <h1> par page décrivant la page.
Des titres dans un ordre logique (h2 pour les sections, h3 à l'intérieur), pas choisis pour la taille de police.
Utilisez de vraies listes, des tableaux avec des cellules d'en-tête, et des points de repère (<header>, <nav>, <main>, <footer>).
Définissez la langue de la page : <html lang="fr">.
7. Nouveauté dans WCAG 2.2, à connaître
2.5.8 Taille de cible (minimum), AA : cibles cliquables d'au moins 24 par 24 pixels CSS, ou assez d'espacement autour des plus petites.
2.4.11 Focus non obscurci (minimum), AA : les en-têtes collants, bannières de cookies et widgets de chat ne doivent pas complètement cacher l'élément avec le focus.
3.3.8 Authentification accessible (minimum), AA : n'exigez pas de résoudre des énigmes ou de mémoriser des informations pour se connecter sans alternative ; autorisez les gestionnaires de mots de passe et le collage.
3.3.7 Saisie redondante, A : ne faites pas retaper aux gens des informations qu'ils ont déjà données dans le même processus.
8. Médias et mouvement
Les vidéos ont besoin de sous-titres (1.2.2) ; la vidéo préenregistrée a besoin d'une audiodescription ou d'une alternative textuelle pour le contenu visuel important.
Tout ce qui bouge automatiquement pendant plus de cinq secondes a besoin d'un moyen de le mettre en pause (2.2.2).
Respectez le paramètre prefers-reduced-motion pour les grandes animations.
Un test manuel de 30 minutes
Les outils automatisés ne capturent qu'une partie du tableau. Ajoutez cette routine pour chaque modèle clé.
Minutes 0 à 5 : scan automatisé. Lancez WAVE (extension navigateur) ou axe DevTools, ou la section accessibilité de Lighthouse. Corrigez les erreurs évidentes comme l'alt manquant, les étiquettes manquantes et les échecs de contraste.
Minutes 5 à 15 : clavier seulement. Rangez la souris. Naviguez au Tab dans la page depuis le haut.
Pouvez-vous voir où est le focus à tout moment ?
Pouvez-vous ouvrir et fermer le menu, utiliser chaque champ de formulaire et soumettre ?
Y a-t-il un lien « Aller au contenu », et fonctionne-t-il ?
Le focus disparaît-il jamais derrière un en-tête collant ou une bannière ?
Minutes 15 à 25 : lecteur d'écran. Utilisez VoiceOver (intégré à macOS et iOS) ou NVDA (gratuit sur Windows).
Écoutez la liste des titres. Décrit-elle la page ?
Passez au Tab sur les images et boutons. Ont-ils du sens hors contexte ?
Remplissez le formulaire. Chaque champ est-il annoncé avec son étiquette ? Les erreurs sont-elles annoncées ?
Minutes 25 à 30 : zoom et reflow. Zoomez le navigateur à 200 % puis 400 %. À 400 %, le contenu devrait se réorganiser en une colonne sans défilement horizontal (1.4.10 Reflow), et rien ne devrait être coupé.
Utilisabilité et accessibilité se chevauchent
Les gens qui cherchent « utilisabilité accessibilité web » ont raison de les regrouper. Presque chaque correction d'accessibilité est une correction d'utilisabilité :
Correction d'accessibilité
Qui d'autre ça aide
Fort contraste
Tout le monde sur téléphone en plein soleil
Étiquettes visibles
Tout le monde qui remplit un formulaire à la hâte
Sous-titres
Les gens qui regardent sans le son
Support clavier
Utilisateurs avancés, gens avec un trackpad cassé
Cibles tactiles plus grandes
Tout le monde sur mobile
Messages d'erreur clairs
Tout le monde qui fait une faute de frappe
Surcouches, déclarations et la loi
Surcouches : les widgets qui promettent une conformité en une ligne ne changent pas votre code sous-jacent. Corrigez le site lui-même.
Déclaration d'accessibilité : publiez une courte page disant quelle norme vous ciblez, les problèmes connus, et comment vous contacter pour de l'aide ou des formats alternatifs.
Contexte légal : les exigences varient selon le pays. L'European Accessibility Act s'applique à de nombreux produits et services dans l'UE depuis juin 2025 ; aux États-Unis, l'ADA est fréquemment appliquée aux sites web ; les organismes du secteur public ont souvent des règles spécifiques. Obtenez un conseil juridique pour votre situation.
Checklist
[ ] Contraste : 4.5:1 texte, 3:1 grand texte et éléments d'interface
[ ] Texte alternatif sur les images informatives, alt vide sur les décoratives
[ ] Chaque champ a une étiquette visible et liée
[ ] Le site entier fonctionne au clavier avec un focus visible
[ ] Les boutons icône ont des noms accessibles
[ ] Titres et points de repère logiques, langue de la page définie
[ ] Cibles tactiles d'au moins 24 par 24 pixels CSS
[ ] Sous-titres sur vidéo, contrôle de pause sur le mouvement
[ ] Se réorganise à 400 % de zoom
[ ] Déclaration d'accessibilité publiée
L'accessibilité soutient aussi la recherche : titres, texte alternatif et liens descriptifs sont aussi des bases SEO on-page, couvertes dans notre checklist SEO on-page.
We.Inc génère des sites en HTML, CSS et code React standard que vous pouvez modifier directement, donc vous pouvez corriger vous-même les étiquettes, le texte alternatif et le contraste ou demander les changements en conversation. Faites toujours les vérifications manuelles ci-dessus sur ce que vous publiez.