Accessibilité web (WCAG 2.2) : le guide pratique pour 2026

L'accessibilité web n'est plus une option "nice-to-have" en 2026. C'est une obligation légale pour la plupart des sites commerciaux en Europe, et un levier SEO sérieux (Google pénalise les sites inutilisables au clavier ou aux lecteurs d'écran).

Les 4 principes WCAG (POUR)

1. Perceptible : le contenu doit être perceptible par tous (texte alternatif, sous-titres, contraste)
2. Opérable : toute interaction doit être possible au clavier seul
3. Compréhensible : langage clair, navigation prévisible, erreurs explicites
4. Robuste : HTML valide, compatible avec les technologies d'assistance

Les critères les plus souvent ratés

1. Contraste insuffisant

Règle : 4,5:1 pour texte normal, 3:1 pour texte large. Un gris clair sur fond blanc (#999 sur #fff) = 2,8:1 → non conforme. Vérifiez chaque couleur texte/fond avec WebAIM Contrast Checker.

2. Focus visible absent

Le fameux outline: none; oublié sans remplacement. Chaque élément focusable (liens, boutons, champs) doit afficher un indicateur visible au clavier. Solution : un outline custom avec 3px de contraste minimum.

3. Images sans alt

Chaque image informative doit avoir un alt descriptif. Les images purement décoratives : alt="" (pas d'alt oublié). Les SVG d'icône : aria-label ou aria-hidden="true" si décoratifs.

4. Formulaires mal étiquetés

Chaque <input> doit avoir un <label> associé. Le placeholder ne suffit pas (il disparaît à la saisie). Erreurs de validation : texte explicite + aria-invalid + aria-describedby.

5. Navigation clavier cassée

Testez en débranchant la souris : Tab doit parcourir tous les éléments dans un ordre logique, Entrée active les boutons/liens, Échap ferme les modales. Les pièges à clavier (focus coincé) sont un bloquant.

6. Structure de titres incorrecte

Un seul <h1> par page. Pas de saut de niveau (h1 → h3). Les lecteurs d'écran naviguent de titre en titre : une mauvaise hiérarchie rend le site incompréhensible.

Les nouveautés WCAG 2.2 (vs 2.1)

WCAG 2.2 ajoute 9 critères orientés cognitif et mobile :

• 2.4.11 Focus Not Obscured : le focus ne doit pas être masqué par un élément sticky
• 2.5.7 Dragging Movements : toute action drag doit avoir une alternative sans glisser
• 2.5.8 Target Size : cibles tactiles ≥ 24×24 px (préférer 44×44)
• 3.2.6 Consistent Help : le lien d'aide doit être au même endroit sur toutes les pages
• 3.3.7 Redundant Entry : ne pas demander 2 fois la même info dans un parcours
• 3.3.8 Accessible Authentication : pas d'auth qui exige mémorisation de puzzle

ARIA : à utiliser avec parcimonie

La règle n°1 d'ARIA : "No ARIA is better than bad ARIA". Préférez toujours un élément HTML natif (<button>, <nav>, <dialog>) à un <div> avec rôle ARIA.

ARIA utile dans ces cas :

• aria-label sur un bouton icône sans texte
• aria-expanded sur les accordéons / menus dropdown
• aria-current="page" sur le lien nav actif
• aria-live pour annoncer des changements dynamiques
• role="dialog" + aria-modal="true" sur les modales custom

Tester l'accessibilité

Outils automatiques (20-30 % des problèmes)

• axe DevTools (extension Chrome/Firefox) — le meilleur audit automatique
• Lighthouse Accessibility — intégré DevTools
• WAVE — overlay visuel des problèmes
• Pa11y — ligne de commande, intégrable en CI

Tests manuels (obligatoires)

• Navigation clavier seule (débrancher la souris 5 min)
• Zoom à 200 % sans perte de contenu ni scroll horizontal
• Lecteur d'écran : NVDA (Windows gratuit) ou VoiceOver (Mac)
• Contraste en mode daltonien (DevTools > Rendering > Emulate vision deficiencies)

Déclaration d'accessibilité

Obligatoire en France pour les sites concernés par la loi : page "Accessibilité" listant le niveau de conformité (total / partiel / non conforme), les contenus non accessibles, et le contact pour signaler un problème.

L'accessibilité n'est pas une charge. C'est une discipline qui rend les interfaces meilleures pour tout le monde — y compris les utilisateurs valides, sur mobile, en contexte dégradé, ou âgés.

Intégration dans votre process

L'accessibilité se gère en amont, pas en correction :

• Design : palette validée pour contraste, focus designé, composants accessibles
• Dev : HTML sémantique, tests axe en CI, code review accessibility
• QA : checklist manuelle pré-livraison, audit 2x/an