L’accessibilité web a basculé d’un sujet de bonne volonté à une obligation réglementaire avec l’European Accessibility Act (EAA) entré en vigueur le 28 juin 2025. En France, le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) cible le niveau AA des WCAG (Web Content Accessibility Guidelines) 2.2. Pour les équipes produit, le piège classique reste le même : auditer en fin de projet, découvrir 200 corrections, repousser la mise en conformité à un sprint qui n’arrive jamais. Cet article cadre les dix règles minimales à appliquer dès le sprint 1, l’outillage 2026 réellement utile, la méthode pour tester avec un lecteur d’écran en 30 minutes, et la checklist d’équipe à coller au mur.

L’obligation a11y en 2026 : ce qui s’applique vraiment

L’a11y (numéronyme pour « accessibility », treize caractères entre le « a » et le « y ») désigne l’ensemble des pratiques rendant un produit numérique utilisable par toutes et tous, y compris en situation de handicap visuel, moteur, auditif ou cognitif. Trois textes structurent l’obligation en 2026.

• European Accessibility Act (directive 2019/882) : applicable depuis juin 2025 pour les e-commerces, plateformes de banque en ligne, billetterie, livre numérique, applications mobiles destinées au grand public. Sanctions financières et obligation de conformité.
• RGAA : déclinaison française pour les acteurs publics et les entreprises de plus de 250 millions d’euros de chiffre d’affaires. Calé sur WCAG 2.2 niveau AA.
• WCAG 2.2 : norme internationale du W3C, publiée en octobre 2023, version de référence en 2026. Niveau AA exigé en pratique, niveau AAA réservé aux applications spécialisées.

Concrètement, si vous shippez un site grand public en Europe en 2026, l’accessibilité web n’est plus négociable. La déclaration de conformité doit être affichée et tenue à jour. La DINUM publie un guide pratique français et la grille d’audit RGAA officielle.

Les 10 règles à appliquer dès le sprint 1

L’erreur stratégique consiste à traiter l’a11y comme une couche cosmétique en fin de projet. Voici les dix règles qui couvrent 80 % de la conformité AA et qui s’intègrent dans les habitudes dev sans coût visible.

Sémantique HTML d’abord

Une <div onclick> n’est pas un bouton. Utilisez <button>, <nav>, <main>, <article>, <header>, <footer> et les niveaux de titres (h1 à h6) selon la hiérarchie réelle. La sémantique correcte règle gratuitement environ un tiers des problèmes d’a11y détectés en audit.

Contraste et tailles minimum

Ratio de contraste 4,5:1 minimum pour le texte normal, 3:1 pour le texte large (≥ 18 pt ou 14 pt gras) et les éléments d’interface. Tailles cibles d’interaction de 24×24 pixels CSS minimum (WCAG 2.2, critère 2.5.8). Les outils WebAIM Contrast Checker et l’extension Chrome DevTools couvrent le besoin.

Navigation au clavier

Tout ce qui se clique doit pouvoir s’atteindre via Tab et s’activer via Enter ou Espace. Pas de piège clavier (impossibilité de quitter une zone), ordre de tabulation cohérent avec l’ordre visuel. Test rapide : naviguez un parcours utilisateur clé sans toucher la souris.

Focus visible et order

Un outline: none sans alternative est une faute. Le focus doit être visible avec un contraste de 3:1 minimum. Privilégiez :focus-visible pour distinguer le focus clavier du focus souris, et stylez un anneau de focus clair sur les composants interactifs.

ARIA seulement quand nécessaire

Première règle d’ARIA : pas d’ARIA. Si un élément HTML natif fait le travail, utilisez-le. ARIA sert à combler ce que HTML ne couvre pas (composants composites comme combobox, tablist, menubar) en suivant les patterns de l’ARIA Authoring Practices Guide. Un aria-label ne sauve jamais une div utilisée comme bouton.

Alternatives textuelles

Toute image porteuse d’information a un alt descriptif. Les images décoratives reçoivent alt="" (vide explicite, pas absent). Les icônes seules portent un aria-label ou un texte visuellement masqué. Les vidéos exigent sous-titres et transcription.

Formulaires labellisés

Chaque champ porte un <label> associé via for/id. Les erreurs sont annoncées via aria-describedby et un message en texte clair. Un placeholder n’est jamais un label. Voici l’avant/après typique.

<!-- Avant : non accessible -->
<input type="email" placeholder="Votre email" />
<span class="error">Email invalide</span>

<!-- Après : accessible -->
<label for="email">Adresse email</label>
<input id="email" type="email" required
       aria-describedby="email-error"
       aria-invalid="true" />
<span id="email-error" role="alert">
  Veuillez saisir une adresse email valide.
</span>

Mouvement et reduced-motion

Les animations parallax, transitions amples ou carrousels automatiques peuvent provoquer des malaises vestibulaires. Respectez la préférence système.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Lecteur d’écran et live regions

Les changements dynamiques (toast, validation, mise à jour de panier) sont annoncés via une live region : aria-live="polite" pour les messages non bloquants, aria-live="assertive" ou role="alert" pour les erreurs critiques. À utiliser avec parcimonie : trop d’annonces noient l’information.

Tests automatisés intégrés à la CI

Un audit a11y manuel ne tient pas dans la durée. Branchez axe-core dans la CI dès le sprint 1, avec un seuil zéro violation critique sur les pages essentielles. Voici un workflow GitHub Actions minimal et opérationnel.

name: a11y
on: [pull_request]

jobs:
  axe:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run build
      - run: npm run preview & npx wait-on http://localhost:4173
      - name: Run axe
        run: npx @axe-core/cli http://localhost:4173 \
              --exit \
              --tags wcag2a,wcag2aa,wcag22aa

Outils 2026 et ce qu’ils détectent vraiment

L’illusion la plus coûteuse en a11y consiste à croire qu’un score 100/100 Lighthouse vaut conformité. Les outils automatiques détectent au mieux 30 à 40 % des problèmes WCAG, selon les études Deque. Le reste est obligatoirement manuel.

Outil	Type	Détecte	Ne détecte pas
axe-core / axe DevTools	Auto	Contrastes, ARIA invalide, labels manquants	Logique d’usage, pertinence des alt
Pa11y	Auto (CLI)	WCAG basique en CI	Idem axe
Lighthouse	Auto	Subset axe + perf croisée	Faux positifs sur SPA
NVDA (Windows) / VoiceOver (Mac)	Manuel	Vraie expérience lecteur d’écran	Rien, c’est la vérité terrain
Audit RGAA expert	Manuel	Tout, conformément au référentiel	Coûte du temps

Le bon mix : axe-core en CI, audit Lighthouse en suivi, test lecteur d’écran à chaque feature significative, audit RGAA expert annuel pour la déclaration de conformité.

Tester avec un lecteur d’écran en 30 minutes

Aucun outil automatique ne remplace un parcours réel au lecteur d’écran. Trente minutes par sprint suffisent à attraper les régressions évidentes.

1. Sur Mac : activez VoiceOver via Cmd+F5. Sur Windows : installez NVDA, gratuit, et lancez-le.
2. Choisissez un parcours critique : signup, ajout au panier, soumission de formulaire principal.
3. Naviguez uniquement au clavier : Tab pour avancer, Maj+Tab pour reculer, Entrée pour activer.
4. Notez chaque message confus, chaque champ non annoncé, chaque bouton qui ne dit pas ce qu’il fait.
5. Créez un ticket par anomalie, tagué a11y, avec gravité (bloquant, gênant, mineur).

Au bout de trois sprints, l’équipe développe une intuition fiable et les régressions tombent à zéro. Le test devient une habitude, pas une corvée.

La checklist d’équipe à coller au mur

Imprimez, collez en salle, ouvrez à chaque revue de PR.

• HTML sémantique partout, zéro div onclick.
• Contraste vérifié, ratio 4,5:1 minimum sur le texte courant.
• Tab navigue tout le parcours, pas de piège clavier.
• :focus-visible stylé sur tous les composants interactifs.
• Images avec alt approprié (descriptif ou vide explicite).
• Formulaires avec label + erreurs annoncées.
• prefers-reduced-motion respecté côté CSS.
• Live regions sur les changements dynamiques importants.
• axe-core en CI, zéro violation critique.
• Test lecteur d’écran sur les nouveautés majeures.

Cette checklist se branche directement sur la stack DevOps : voyez nos recommandations pour intégrer l’a11y dans la CI. Sur le choix d’architecture, certains frameworks rendent l’accessibilité plus ou moins coûteuse — détails dans choisir un framework JS adapté. Et un site accessible est aussi presque toujours un site rapide : voir le pilier Core Web Vitals 2026 (pilier perf). La référence officielle reste WCAG 2.2, à garder en favori.

Questions fréquentes

Qu’est-ce que l’European Accessibility Act ?

L’EAA est la directive européenne 2019/882, applicable depuis le 28 juin 2025, qui rend obligatoire l’accessibilité numérique des produits et services destinés au grand public : e-commerce, banque en ligne, billetterie, livre numérique, applications mobiles. Le texte cible le niveau AA des WCAG 2.1 minimum, et prévoit des sanctions en cas de non-conformité avérée.

Quelles sont les obligations RGAA en 2026 ?

Le RGAA s’applique aux acteurs publics français et aux entreprises privées dépassant 250 millions d’euros de chiffre d’affaires. Il exige le niveau AA des WCAG 2.2, la publication d’une déclaration de conformité, d’un schéma pluriannuel d’accessibilité, et un audit régulier. Pour les autres entreprises grand public, l’EAA prend le relais.

Quel niveau WCAG cibler en 2026 (A, AA, AAA) ?

Niveau AA. Le niveau A est insuffisant pour la conformité légale française et européenne. Le niveau AAA reste réservé aux applications spécialisées (services dédiés au handicap, secteur public renforcé) car certains critères y sont incompatibles avec une expérience utilisateur grand public moderne. Visez WCAG 2.2 niveau AA, c’est la cible standard 2026.

Quels outils d’audit a11y utiliser en 2026 ?

axe-core de Deque reste la référence en automatique, branché en CI. Lighthouse complète sur le rapport global, Pa11y sert pour les scans CLI sur plusieurs URL. Côté manuel, NVDA gratuit sur Windows ou VoiceOver natif sur Mac suffisent à 95 % des tests de lecture d’écran. Pour la déclaration de conformité officielle, un audit RGAA expert reste obligatoire.

Comment tester son site avec un lecteur d’écran ?

Activez VoiceOver (Cmd+F5 sur Mac) ou installez NVDA (gratuit sur Windows), puis naviguez votre parcours critique uniquement au clavier. Tab pour avancer, Maj+Tab pour reculer, Entrée pour activer. Notez chaque champ non annoncé, chaque bouton sans intitulé clair, chaque message confus. Trente minutes par sprint suffisent à maintenir la qualité d’a11y sur un produit en évolution.

Audit accessibilité de votre site en 1 jour, conformité EAA cadrée en 1 sprint : c’est la formule que nous proposons aux équipes pressées par l’échéance. Présentez-nous votre cas via le formulaire de contact.