Accessibilité web : rendre les sites utilisables par tous

L'accessibilité web consiste à concevoir des sites et des applications utilisables par toutes les personnes, quels que soient leur handicap, leur matériel ou leur environnement. En France, 12 millions de personnes sont en situation de handicap. Pourtant, 95 % des sites web français ne respectent pas les normes d'accessibilité. Depuis juin 2025, l'European Accessibility Act étend les obligations au secteur privé, et les sanctions financières sont désormais appliquées.

L'accessibilité n'est pas un frein au design ou à la performance — au contraire. Un site accessible est un site mieux structuré, plus rapide, mieux référencé et plus facile à maintenir. Ces pratiques s'appliquent aussi bien aux boutiques PrestaShop qu'aux applications Symfony ou aux sites WordPress.

Le cadre légal en France en 2026

L'European Accessibility Act (EAA)

Entrée en vigueur le 28 juin 2025, la directive européenne sur l'accessibilité (EAA) impose des obligations à toutes les entreprises de plus de 10 salariés ou 2 millions d'euros de chiffre d'affaires qui fournissent des services numériques : e-commerce, banque en ligne, télécommunications, transport, audiovisuel.

L'EAA a une portée extraterritoriale : toute entreprise qui sert des clients européens est potentiellement concernée, quel que soit son siège.

Les sanctions

• 50 000 euros d'amende pour non-respect des obligations d'accessibilité, renouvelable tous les 6 mois tant que le site reste non conforme.
• 25 000 euros supplémentaires en cas de défaut de publication d'une déclaration d'accessibilité ou d'un schéma pluriannuel.
• Pénalités journalières de 3 000 euros (dans la limite de 300 000 euros) appliquées par la DGCCRF via le Code de la consommation.

L'Arcom vise 2 000 contrôles par an dès 2026. Les premières sanctions sont déjà tombées depuis juin 2025.

La loi REEN (2021)

La loi visant à Réduire l'Empreinte Environnementale du Numérique impose aux communes de plus de 50 000 habitants une stratégie numérique responsable. L'accessibilité et l'éco-conception convergent naturellement : un code propre, un DOM léger et des contenus bien structurés servent les deux objectifs.

Le RGAA : le référentiel français

Le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) est le document officiel publié par la DINUM. Dans sa version actuelle (4.1.2), il définit 106 critères répartis en 13 thématiques, basés sur les WCAG 2.1 niveau AA.

Les 13 thématiques du RGAA

1. Images — Textes alternatifs pertinents, images décoratives masquées
2. Cadres — Titres de frames, iframes accessibles
3. Couleurs — Contrastes suffisants, information non véhiculée uniquement par la couleur
4. Multimédia — Sous-titres, audiodescription, contrôles accessibles
5. Tableaux — En-têtes, légendes, association données/en-têtes
6. Liens — Intitulés explicites, distinction visuelle
7. Scripts — Composants JavaScript accessibles au clavier
8. Éléments obligatoires — Langue, titre de page, validité du code
9. Structuration — Hiérarchie des titres, landmarks ARIA, listes
10. Présentation — Pas de perte d'information sans CSS, contenu lisible à 200 %
11. Formulaires — Labels associés, messages d'erreur explicites, aide à la saisie
12. Navigation — Liens d'évitement, plan du site, fil d'Ariane
13. Consultation — Pas de piège au clavier, contenu contrôlable par l'utilisateur

Le RGAA 5 : ce qui change

La version 5 du RGAA, prévue fin 2026, intégrera les WCAG 2.2 et élargira la couverture aux applications mobiles et aux documents bureautiques. Les principaux ajouts :

• Taille minimale des cibles tactiles (24×24 pixels CSS) — WCAG 2.5.8
• Authentification accessible — Pas de test cognitif (puzzle, mémorisation) comme unique moyen d'authentification — WCAG 3.3.8
• Aide cohérente — Les mécanismes d'aide (FAQ, contact) doivent apparaître au même endroit sur toutes les pages — WCAG 3.2.6
• Pas de ressaisie — Les données déjà saisies dans un processus multi-étapes ne doivent pas être redemandées — WCAG 3.3.7
• Focus visible — L'élément focalisé ne doit pas être masqué par des éléments sticky — WCAG 2.4.11
• Alternatives au glisser-déposer — WCAG 2.5.7

Les déclarations d'accessibilité publiées sous RGAA 4.1.2 restent valides jusqu'à mi-2028. La transition vers le RGAA 5 peut être planifiée progressivement.

Les WCAG 2.2 : la norme internationale

Les WCAG 2.2 (Web Content Accessibility Guidelines), publiées en octobre 2023 par le W3C, comptent 87 critères de succès organisés en 3 niveaux : A (minimum), AA (recommandé, exigé par la loi), et AAA (excellence).

Les WCAG s'articulent autour de 4 principes fondamentaux (POUR) :

• Perceptible — L'information doit être présentée de manière perceptible (textes alternatifs, sous-titres, contrastes)
• Opérable — L'interface doit être utilisable au clavier, avec des cibles tactiles suffisantes et sans piège
• Understandable (Compréhensible) — Le contenu et le fonctionnement doivent être prévisibles et compréhensibles
• Robuste — Le contenu doit être compatible avec les technologies d'assistance (lecteurs d'écran, plages braille)

Bonnes pratiques pour les développeurs

HTML sémantique

La base de l'accessibilité est un HTML bien structuré. Utiliser les bonnes balises sémantiques réduit la dépendance aux attributs ARIA et rend le code plus léger :

• <main>, <nav>, <header>, <footer>, <article>, <section> — Landmarks natifs, pas besoin de role="main"
• <button> au lieu de <div onclick> — Focusable et activable au clavier nativement
• <label for="id"> sur chaque champ de formulaire — Les lecteurs d'écran annoncent le libellé
• Hiérarchie de titres H1 → H6 cohérente — Pas de saut de niveau (H1 puis H3)

Navigation au clavier

• Lien d'évitement — Un lien "Aller au contenu" en début de page permet de sauter la navigation
• Ordre de tabulation logique — Suivre l'ordre visuel, ne pas utiliser tabindex positif
• Focus visible — Ne jamais supprimer outline sans fournir un style alternatif
• Pas de piège au clavier — L'utilisateur doit pouvoir quitter tout composant avec Tab ou Échap

Images et médias

• Texte alternatif — Chaque image informative a un alt descriptif. Les images décoratives ont alt=""
• SVG accessibles — role="img", aria-label, <title> et <desc>
• Vidéos — Sous-titres pour les sourds, audiodescription pour les aveugles, contrôles accessibles au clavier

Formulaires

• Labels visibles — Chaque champ a un <label> associé. Le placeholder ne remplace pas le label
• Messages d'erreur explicites — Indiquer quel champ est en erreur et comment corriger
• Autocomplétion — Utiliser autocomplete pour les champs courants (nom, email, adresse)
• Pas de captcha cognitif — Les WCAG 2.2 (critère 3.3.8) déconseillent les tests de mémorisation ou de reconnaissance. Préférer les honeypots ou les solutions invisibles

Couleurs et contrastes

• Ratio de contraste minimal — 4.5:1 pour le texte normal, 3:1 pour le texte large (≥18.5px bold ou ≥24px)
• Ne pas véhiculer l'information par la couleur seule — Ajouter un underline sur les liens, une icône sur les erreurs
• Dark mode — Respecter prefers-color-scheme et vérifier les contrastes dans les deux modes

Accessibilité et éco-conception : deux démarches convergentes

L'accessibilité et l'éco-conception web partagent les mêmes fondamentaux techniques :

• HTML sémantique — Moins de <div> inutiles = DOM plus léger (EcoIndex) et meilleure accessibilité
• Pas de dépendance au JavaScript — Un site accessible fonctionne sans JS pour la navigation de base. Moins de JS = moins de poids et de CPU
• Images optimisées avec alt — Rédiger des alt pertinents pousse à se demander si l'image est vraiment nécessaire
• Performances — Un site rapide est un site utilisable par les personnes avec des appareils anciens ou des connexions lentes

Les outils pour auditer l'accessibilité

• WAVE — Extension navigateur qui identifie les erreurs d'accessibilité et les contrastes insuffisants directement sur la page
• Lighthouse (Google) — Intégré à Chrome DevTools, score accessibilité basé sur axe-core
• axe DevTools (Deque) — Extension Chrome/Firefox, référence pour les tests automatisés d'accessibilité
• HeadingsMap — Extension qui affiche la hiérarchie des titres H1-H6 de la page en temps réel
• Ara (DINUM) — Application web officielle pour piloter les audits RGAA et générer les déclarations d'accessibilité obligatoires
• ARC Toolkit (TPGi) — Analyse des composants ARIA et widgets JavaScript (React, Vue, Angular)

Les outils automatiques ne détectent que 25 à 30 % des erreurs. Un audit RGAA complet nécessite des tests manuels : navigation au clavier, utilisation d'un lecteur d'écran (NVDA, VoiceOver), vérification des parcours utilisateurs.

Ressources officielles

• RGAA officiel — Le référentiel complet avec les 106 critères (DINUM)
• Guide développeur RGAA — 8 fiches pratiques + mémo dev (info.gouv.fr)
• WCAG 2.2 — La norme internationale (W3C)
• DesignGouv — Ressources d'accessibilité de la DINUM
• Ara — Outil d'audit RGAA officiel

Questions fréquentes

Qu'est-ce que le RGAA ?

Le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) est le référentiel français officiel publié par la DINUM. Il traduit les normes internationales WCAG en 106 critères techniques répartis en 13 thématiques (images, couleurs, formulaires, navigation, etc.). Le niveau AA est exigé par la loi.

Mon site doit-il être accessible en 2026 ?

Depuis juin 2025, l'European Accessibility Act (EAA) impose l'accessibilité aux entreprises de plus de 10 salariés ou 2 millions d'euros de chiffre d'affaires qui fournissent des services numériques. Les organismes publics sont concernés depuis 2012. Les sanctions vont de 25 000 à 50 000 euros, renouvelables tous les 6 mois.

Quelle est la différence entre RGAA et WCAG ?

Les WCAG (Web Content Accessibility Guidelines) sont les normes internationales publiées par le W3C. Le RGAA est la transposition française des WCAG, adaptée au cadre juridique national. Concrètement, un site conforme au RGAA est conforme aux WCAG. Le RGAA 4.1.2 actuel s'appuie sur les WCAG 2.1, le futur RGAA 5 intégrera les WCAG 2.2.

Les outils automatiques suffisent-ils pour un audit d'accessibilité ?

Non. Les outils automatiques (Lighthouse, axe, Wave) ne détectent que 25 à 30 % des erreurs d'accessibilité. La pertinence d'un texte alternatif, la logique d'un parcours utilisateur ou la clarté d'un message d'erreur nécessitent une analyse humaine. Un audit RGAA complet combine outils automatiques et tests manuels.