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

Cadre légal : ce qui change avec l'EAA en 2026

L'European Accessibility Act (directive UE 2019/882, transposée en France par l'ordonnance n° 2023-859) est entrée en application le 28 juin 2025. Beaucoup d'éditeurs pensent encore que la loi ne concerne que les sites publics — c'est l'erreur la plus coûteuse de l'année.

Qui est concerné en pratique

• E-commerce B2C — toute boutique en ligne vendant aux consommateurs européens, sans seuil de chiffre d'affaires côté UE (la France a relevé le seuil français à 2 M€ et 10 salariés, mais le seuil européen prime pour le cross-border)
• Banques, assurances, services financiers — y compris les fintech et néobanques
• Billetterie, transports, hôtellerie — réservation en ligne incluse
• Plateformes de communication — visioconférence, messagerie, e-mail clients
• E-books et liseuses — formats et applications de lecture
• Sites publics — déjà soumis depuis 2019 via la directive (UE) 2016/2102

Exemptions : micro-entreprises de moins de 10 salariés et moins de 2 M€ de CA — mais elles perdent l'exemption dès qu'un seuil est franchi. Les associations à but non lucratif ne sont pas exemptées automatiquement si elles vendent des prestations.

Sanctions effectivement appliquées

La DGCCRF est l'autorité compétente en France. Le barème :

• Mise en demeure publique sur le site de la DGCCRF — l'effet réputationnel est souvent plus pénalisant que l'amende
• Amende administrative jusqu'à 50 000 € par site non conforme
• Amende portée à 250 000 € en cas de récidive
• Suspension d'activité possible pour les manquements graves répétés

Les premières sanctions visibles sont tombées au quatrième trimestre 2025 — quelques e-commerçants français cités publiquement, montants entre 8 000 et 35 000 €. Le pattern : refus de répondre aux mises en demeure ou absence totale de déclaration d'accessibilité.

La déclaration d'accessibilité — contenu obligatoire

Page dédiée, accessible en un clic depuis le footer (lien intitulé "Accessibilité"), contenant a minima :

• Niveau de conformité revendiqué (totalement / partiellement / non conforme) au regard du RGAA 4.1.2
• Date de l'audit RGAA
• Liste des contenus non accessibles et raisons (charge disproportionnée à justifier précisément)
• Adresse e-mail et numéro de téléphone d'un référent accessibilité
• Procédure de saisine du Défenseur des droits en cas de non-réponse sous 30 jours
• Schéma pluriannuel de mise en accessibilité (3 ans glissants) et plan d'actions annuel

WCAG vs RGAA — comparatif pratique

Les deux référentiels sont alignés sur le fond mais divergent côté méthodologie d'audit. Comprendre lequel s'applique évite des audits redondants.

En pratique : pour une entreprise française, viser RGAA 4.1.2 conformité totale couvre automatiquement WCAG 2.2 AA. L'inverse n'est pas vrai — un audit purement WCAG laisse souvent des trous sur les critères RGAA spécifiques (formulaires, tableaux complexes, contenu téléchargeable). Si vous opérez sur plusieurs pays UE, la déclaration WCAG est la lingua franca ; si vous êtes 100 % France, RGAA est juridiquement plus solide.

Cas pratiques — corrections les plus fréquentes

Le bouton-icône sans texte accessible

Erreur récurrente : un bouton hamburger ou un picto loupe sans label. Le lecteur d'écran annonce "bouton" sans contexte.

<!-- Mauvais -->
<button><svg>...</svg></button>

<!-- Bon -->
<button aria-label="Ouvrir le menu de navigation">
  <svg aria-hidden="true">...</svg>
</button>

Note importante : le aria-hidden="true" sur le SVG décoratif évite que le lecteur lise "image SVG" en plus du label.

Le dropdown menu maison qui casse au clavier

Reconstruire un select natif en <div> + JS est presque toujours un piège — les attentes clavier sont complexes (Home/End, Page Up/Down, alphabétique). Si vous tenez à un design custom, partez d'une bibliothèque accessibilité-first : Headless UI, Radix UI, React Aria. Sur un projet récent, remplacer un select custom maison par un Radix Select a corrigé 12 critères RGAA d'un coup et économisé 3 jours d'audit-correction.

Le carousel hero — souvent indéfendable

Les carousels hero échouent à 4 critères RGAA simultanément : mouvement automatique sans pause clavier (2.2.2), focus dans le slide non-actif, ordre de tabulation imprévisible, contenu masqué visuellement mais lu par le lecteur d'écran. Recommandation : remplacer par une grille statique ou un slider à navigation explicite uniquement (pas d'autoplay). C'est aussi meilleur pour le LCP — voir notre guide Core Web Vitals.

Le PDF inaccessible — l'angle mort le plus fréquent

Un PDF mis en téléchargement (CGV, fiches produit, plaquette) doit aussi être conforme. Un PDF scanné en image, sans balisage de structure, échoue à WCAG par construction. Solutions par ordre de coût :

• Coût zéro — proposer une alternative HTML accessible (la version web prime)
• Coût faible — régénérer le PDF depuis Word/InDesign avec export "PDF accessible/balisé"
• Coût élevé — re-balisage manuel dans Acrobat Pro (1 à 4 heures par document)

Méthode d'audit pas-à-pas (4 heures, sans outil payant)

1. 30 min — Analyse automatique. Lancer axe DevTools sur 8-10 pages représentatives (home, catégorie, fiche produit, panier, checkout, page de contenu, formulaire de contact, espace compte). Exporter les rapports.
2. 45 min — Navigation clavier. Débrancher la souris. Parcourir le tunnel de conversion principal du début à la fin. Noter : ordre de tab incohérent, focus invisible, pièges à clavier, raccourcis manquants (Échap pour fermer modales).
3. 30 min — Lecteur d'écran. NVDA sur Windows (gratuit) ou VoiceOver sur Mac (intégré, Cmd+F5). Parcourir la home + une fiche produit. Noter les libellés manquants, les annonces dynamiques absentes (panier mis à jour), les images sans alt.
4. 30 min — Zoom + reflow. Zoom à 200 % puis 400 %. Vérifier qu'aucun contenu ne se perd ni ne provoque un scroll horizontal sur 320px CSS de largeur (critère WCAG 1.4.10).
5. 30 min — Contraste. Outil WebAIM Contrast Checker sur les 6-8 paires couleur récurrentes (texte body, texte sur bouton primaire/secondaire, liens, texte sur image, états hover/focus/disabled).
6. 45 min — Vision et motricité simulées. DevTools > Rendering > Emulate vision deficiencies (deutéranopie, protanopie, achromatopsie). Tester aussi en mode "prefers-reduced-motion: reduce".
7. 30 min — Synthèse. Compiler les findings en 3 catégories : bloquant (critère échec total), à corriger (échec partiel), à surveiller (warning). Prioriser par fréquence de la page concernée × poids du critère.

Ce protocole détecte 70-80 % des non-conformités sans audit externe. Le reste (critères de contenu, alternatives média, formulaires complexes) demande une lecture critère par critère du RGAA, plus longue mais cadrée. Pour intégrer ces vérifications dans une refonte, voir aussi notre offre de migration WordPress vers Next.js qui inclut un livrable accessibilité AA d'office.

Retour terrain — ce qui marche, ce qui ne marche pas

Ce qui marche

• Linter accessibilité en pre-commit. eslint-plugin-jsx-a11y bloque ~30 % des erreurs avant qu'elles n'arrivent en review. Coût d'installation : 15 minutes.
• Storybook avec addon a11y. Chaque composant du design system est testé en isolation. Les régressions sur les composants critiques (Button, Input, Modal) sont quasi éliminées.
• Audit utilisateur réel. Une session de 90 minutes avec une personne malvoyante utilisant son lecteur d'écran habituel révèle des problèmes qu'aucun audit automatique ne trouve — typiquement : ordre de lecture incohérent dans des layouts CSS Grid.

Ce qui ne marche pas

• Overlays d'accessibilité (AccessiBe, UserWay, EqualWeb). Vendus comme la solution clé-en-main, ils sont régulièrement critiqués par les associations d'utilisateurs (FAF, WebAIM) — ils masquent les problèmes sans les corriger, interfèrent avec les lecteurs d'écran réels, et ne tiennent pas devant un audit RGAA officiel. Plusieurs class actions aux États-Unis en 2024 ont visé des sites équipés d'overlays.
• Audit unique à la livraison. Sans process continu, l'accessibilité régresse à chaque mise à jour. Un site livré conforme à J0 redevient non conforme en 6-12 mois.
• Auto-évaluation par le dev qui a écrit le code. Le biais de connaissance fausse les tests clavier — le dev sait où cliquer, il ne voit pas le piège.