Design & UX · 23 mars 2026 · 9 min

Accessibilité WCAG 2.2 : guide pratique pour les TPE/PME en 2026

L'accessibilité web n'est plus optionnelle. WCAG 2.2 + Loi du 11 février 2005 + EAA 2025 : ce que les TPE doivent vraiment faire pour être conformes.

ÉC

Équipe CreativeWork

Publié le 23 mars 2026

L’accessibilité web n’est plus une option. Avec l’European Accessibility Act (EAA) entré en vigueur en juin 2025, et la Loi du 11 février 2005 française qui s’élargit progressivement, de plus en plus d’entreprises ont une obligation légale de rendre leur site accessible. Voici ce qu’il faut vraiment savoir.

Ce qui s’applique vraiment en France en 2026

Pour les acteurs publics

La Loi du 11 février 2005 article 47 impose aux services publics et à leurs délégataires de respecter le RGAA (Référentiel Général d’Amélioration de l’Accessibilité). Sanction : jusqu’à 25 000 € d’amende (source officielle).

Pour le privé : EAA depuis juin 2025

L’European Accessibility Act (transposé en France par l’ordonnance 2023-859) impose à certaines entreprises l’accessibilité de leurs services numériques :

Sont concernés : e-commerce, banques, transports, télécoms, audio-livres, ebooks
CA > 2 millions €/an et > 10 salariés : conformité obligatoire au 28 juin 2025
Sanctions possibles : amendes (montants en cours de définition par décret)

Les TPE de moins de 10 salariés / 2 M€

Pas d’obligation légale en 2026, mais :

Obligation morale (15 % de la population française a un handicap)
Obligation commerciale : les marchés publics et les grandes entreprises imposent l’accessibilité dans leurs RFP
Obligation SEO : Google considère l’accessibilité comme un signal de qualité

WCAG 2.2 : les 13 nouveaux critères

Le standard international d’accessibilité, WCAG (Web Content Accessibility Guidelines), publié par le W3C. Trois niveaux : A (basique), AA (référence légale), AAA (idéal).

WCAG 2.2 a été publié en octobre 2023 avec 13 nouveaux critères, dont :

2.4.11 Focus Not Obscured : le focus clavier doit être visible (pas caché par un menu sticky)
2.5.7 Dragging Movements : pas d’action accessible uniquement par drag & drop (toujours offrir un clic alternatif)
2.5.8 Target Size (Minimum) : zones cliquables ≥ 24×24 pixels
3.3.7 Redundant Entry : ne pas redemander une info déjà saisie dans le même flux
3.3.8 Accessible Authentication : ne pas exiger de captcha non-accessible

Les 4 principes WCAG (POUR)

1. Perceptible

Le contenu doit être perceptible par tous les sens disponibles :

Texte alternatif sur les images (alt="...")
Sous-titres sur les vidéos
Contraste suffisant (ratio 4,5:1 pour le texte normal, 3:1 pour le grand texte)
Texte redimensionnable jusqu’à 200 % sans perte

2. Opérable

L’interface doit être utilisable :

Navigation au clavier complète (Tab, Entrée, Échap)
Pas de pièges au clavier (focus qui reste bloqué)
Délais ajustables sur les sessions et les notifications
Pas d’animations clignotantes qui pourraient déclencher des crises d’épilepsie

3. Compréhensible

Le contenu doit être compréhensible :

Langue de la page déclarée (<html lang="fr">)
Navigation cohérente entre pages
Messages d’erreur clairs dans les formulaires
Pas de jargon inutile

4. Robuste

Le code doit être robuste face aux différents navigateurs et technologies d’assistance :

HTML valide (W3C Validator)
Rôles ARIA corrects
Compatibilité avec les lecteurs d’écran (NVDA, JAWS, VoiceOver)

Checklist accessibilité minimale pour une TPE

Si vous n’êtes pas légalement obligé mais voulez bien faire :

Niveau « bon élève » (1-2 jours de boulot pour un site existant)

Niveau « conforme RGAA » (1-3 semaines pour audit + corrections)

Tout ce qui précède + :

Audit complet par expert (ou via outils comme Tanaguru, Asqatasun)
Documentation des rôles ARIA sur les composants interactifs (modales, dropdowns, accordions)
Skip links (« Aller au contenu principal »)
Hiérarchie de titres correcte (un seul H1, pas de saut H2 → H4)
Schéma color-blind (vérifier en Deuteranopia, Protanopia, Tritanopia avec les DevTools)
Tests réels avec lecteur d’écran (NVDA gratuit pour Windows)

Outils pour mesurer

Outils automatisés

WAVE : extension navigateur, gratuite, très visuelle
axe DevTools : extension Chrome/Firefox de référence
Lighthouse : intégré à Chrome, donne un score d’accessibilité
Pa11y : outil CLI pour CI/CD

⚠️ Attention : les outils automatisés détectent 30-40 % des problèmes au mieux. Le reste demande des tests humains.

Outils manuels

Tester au clavier seul : débranchez votre souris, naviguez 5 min sur votre site
Lecteur d’écran : NVDA gratuit pour Windows, VoiceOver natif sur macOS, TalkBack sur Android
Zoom 200 % : Ctrl + plusieurs fois
Mode sombre : la mise en page tient-elle ?

Cas concret : un formulaire de contact accessible

Un formulaire mal codé est inaccessible. Voici la version pro :

<form action="/api/contact" method="POST">
  <div>
    <label for="email">
      Adresse email <span aria-label="obligatoire">*</span>
    </label>
    <input
      id="email"
      name="email"
      type="email"
      required
      autocomplete="email"
      aria-describedby="email-help email-error"
    >
    <div id="email-help" class="help-text">
      Format : nom@example.com
    </div>
    <div id="email-error" class="error" role="alert" hidden>
      <!-- Affichée si erreur -->
    </div>
  </div>
  <button type="submit">Envoyer</button>
</form>

Les éléments clés :

<label for> lié à l’id de l’input
autocomplete pour les utilisateurs avec aides à la saisie
aria-describedby pour lier les messages d’aide et d’erreur
role="alert" pour signaler les erreurs aux lecteurs d’écran
required natif HTML5

Erreurs courantes à éviter

1. Couleur seule pour transmettre une information

❌ « Les champs en rouge sont obligatoires »
✅ « Les champs marqués d’un * sont obligatoires »

2. Suppression du focus visible

/* MAUVAIS */
*:focus { outline: none; }

/* BON */
*:focus-visible { outline: 2px solid currentColor; outline-offset: 2px; }

3. Tooltips uniquement au hover

Les utilisateurs clavier ne peuvent pas hover. Le tooltip doit aussi s’afficher au focus.

4. Vidéos sans transcription

Une vidéo de présentation est inutile pour une personne sourde si elle n’a pas de sous-titres ou de transcription.

5. PDF inaccessibles

Les PDF générés depuis Word sans tagging sont illisibles aux lecteurs d’écran. Préférez le HTML quand possible, sinon utilisez Adobe PDF avec balises ou les outils PAC 2024 pour valider.

Le ROI de l’accessibilité

Au-delà du légal :

15 % de la population française est en situation de handicap (INSEE 2022)
30-50 % de plus d’utilisateurs si on inclut les seniors, les personnes à mobilité réduite temporaire
Bénéfices SEO : un site accessible a souvent une meilleure structure HTML, signal positif pour Google
Bénéfices UX généraux : ce qui aide les personnes handicapées aide tout le monde (mère qui pousse une poussette = main occupée = équivalent fonctionnel d’un handicap moteur léger)

Notre approche chez CreativeWork

Tous nos sites sont livrés avec :

Conformité WCAG 2.2 niveau AA par défaut
Tests automatisés Lighthouse + axe DevTools
Tests manuels clavier
Documentation des composants accessibles

Inclus à partir de 450 € HT pour un site vitrine. Pour la conformité RGAA complète (audit officiel + déclaration), comptez +500 à +2 000 € selon la taille du site.

Sources

Vous voulez auditer l’accessibilité de votre site ? On l’inclut dans nos audits SEO à 150 € HT.

Tags #accessibilité #wcag #rgaa #loi handicap