Quand on développe un site ou une application en France en 2026, la question de l'accessibilité numérique ne relève plus du simple « bon réflexe » : selon le type d'organisme, elle repose sur des textes précis. Le RGAA (Référentiel général d'amélioration de l'accessibilité) encadre le secteur public et les très grandes entreprises, tandis que l'acte européen sur l'accessibilité, entré en application le 28 juin 2025, étend certaines obligations à des services privés comme le commerce en ligne. Bonne nouvelle pour un développeur : dans les deux cas, les mêmes bases techniques (HTML sémantique, contrastes, clavier, formulaires) couvrent l'essentiel du terrain. Ce guide distingue ce qui est une obligation de ce qui est une bonne pratique, puis donne une méthode de vérification réalisable seul.
L'accessibilité numérique consiste à rendre un site, une application ou un document utilisable par le plus grand nombre, y compris par des personnes aveugles, malvoyantes, sourdes, avec une mobilité réduite, une déficience cognitive, ou simplement dans une situation difficile (soleil sur l'écran, souris en panne, connexion lente). Les référentiels s'organisent autour de quatre principes, résumés par le sigle anglais POUR : un contenu doit être perceptible, utilisable, compréhensible et robuste.
Ces principes sont déclinés par les WCAG (Web Content Accessibility Guidelines), publiées par le W3C. La version 2.2 est une recommandation du W3C ; elle compte trois niveaux de conformité (A, AA, AAA) et ajoute neuf critères de succès par rapport à la version 2.1. Un contenu conforme à WCAG 2.2 est aussi conforme aux versions 2.1 et 2.0, ce qui simplifie la vie des équipes : viser la version la plus récente ne ferme aucune porte.
Le niveau AA est celui que visent presque tous les textes réglementaires. Il ne demande pas la perfection, mais un socle solide : alternatives textuelles, contrastes suffisants, navigation au clavier, formulaires étiquetés, structure de titres cohérente.
Le RGAA est le référentiel technique français. Sa version en vigueur est la 4.1.2, qui s'appuie sur les WCAG 2.1 au niveau AA. Il se compose de 106 critères répartis en 13 thématiques : images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration de l'information, présentation de l'information, formulaires, navigation et consultation. Selon le site officiel consacré à l'accessibilité numérique, une version 5 est en préparation, avec une publication attendue d'ici la fin de 2026 : à surveiller si vous démarrez un chantier long.
Le champ d'application est précis. Les obligations s'appliquent aux services de communication au public en ligne de plusieurs catégories d'organismes :
Autrement dit, le RGAA ne s'impose pas à tout site privé : un blog personnel, un forum associatif ou la boutique d'une petite entreprise ne figurent pas, en tant que tels, dans cette liste. Le référentiel reste néanmoins une excellente grille de contrôle, parce qu'il traduit les WCAG en critères testables, avec une méthode de vérification pour chacun.
Les organismes concernés doivent aussi publier une déclaration d'accessibilité et un affichage clair du niveau de conformité. Pour le détail des modalités (contenu de la déclaration, schéma pluriannuel), reportez-vous aux pages officielles de l'accessibilité numérique plutôt qu'à un résumé : les exigences évoluent et dépendent du statut de l'organisme.
La directive (UE) 2019/882, souvent appelée « acte européen sur l'accessibilité » (European Accessibility Act), s'applique depuis le 28 juin 2025 aux produits mis sur le marché et aux services concernés. Elle vise des produits et services du quotidien jugés essentiels pour les personnes handicapées. Parmi les catégories couvertes figurent notamment :
| Catégorie | Exemples |
|---|---|
| Produits | ordinateurs et systèmes d'exploitation, smartphones, terminaux en libre-service (distributeurs de billets, bornes de billetterie et d'enregistrement), équipements pour la télévision numérique |
| Services de communication | services de téléphonie, accès aux services de médias audiovisuels |
| Services de transport de voyageurs | sites web, applications mobiles, billetterie électronique |
| Services bancaires | services bancaires destinés aux consommateurs |
| Commerce électronique | boutiques et plateformes de vente en ligne, livres numériques |
Une exemption importante concerne les microentreprises prestataires de services : celles qui emploient moins de 10 personnes et dont le chiffre d'affaires annuel reste inférieur à 2 millions d'euros ne sont pas visées pour leurs services. Pour les produits, l'exemption est plus limitée. Si vous développez pour un client, la première question à poser n'est donc pas « quel est le niveau technique ? » mais « le service est-il dans le périmètre, et le client dépasse-t-il le seuil de microentreprise ? ».
Un point de vigilance : ces textes décrivent ce que dit la réglementation à un instant donné, pas un avis juridique. Pour un projet à enjeu (boutique en ligne, service bancaire, billetterie), faites valider le périmètre par un juriste ou par le correspondant accessibilité du client.
La bonne nouvelle, c'est que la majorité des défauts viennent d'un petit nombre de mauvaises habitudes de développement. En voici cinq, avec la correction associée.
Un div cliquable n'est ni atteignable au clavier, ni annoncé comme bouton par un lecteur d'écran. Utilisez button pour une action, a pour une navigation, input, select et textarea pour les saisies. Les éléments natifs apportent gratuitement le comportement clavier, le focus et le rôle.
<!-- À éviter -->
<div class="btn" onclick="envoyer()">Envoyer</div>
<!– À privilégier –>
<button type="button" onclick="envoyer()">Envoyer</button>
Chaque image porteuse d'information a besoin d'un attribut alt qui décrit son rôle. Une image purement décorative reçoit un alt vide (alt=""), pour que les technologies d'assistance l'ignorent. Un alt absent est la pire option : certains lecteurs d'écran lisent alors le nom du fichier.
Un placeholder n'est pas une étiquette : il disparaît à la saisie et n'est pas toujours annoncé. Associez chaque champ à un label avec l'attribut for, ou enveloppez le champ dans le label. Les messages d'erreur doivent être liés au champ concerné et formulés clairement (« Saisissez une adresse e-mail valide » plutôt qu'une simple bordure rouge).
Le critère de contraste minimum des WCAG demande un rapport d'au moins 4,5:1 pour le texte courant et 3:1 pour le grand texte. Un gris clair sur fond blanc, très répandu dans les maquettes, échoue souvent. Un vérificateur de contraste intégré aux outils de développement du navigateur suffit pour tester vos couleurs avant de les figer dans le CSS.
Quand on supprime le contour de focus avec outline: none sans le remplacer, l'utilisateur qui navigue avec la touche Tab ne sait plus où il se trouve. Gardez un indicateur visible et testez l'ordre de tabulation : il doit suivre l'ordre logique de la page. WCAG 2.2 ajoute d'ailleurs des exigences sur le focus non masqué (par exemple par un bandeau fixe) et sur la taille minimale des cibles tactiles : au niveau AA, 24 × 24 pixels CSS au minimum, avec des exceptions prévues par le critère.
Les neuf critères ajoutés par WCAG 2.2 touchent surtout les interfaces d'aujourd'hui : composants interactifs, mobile, authentification. Ils portent notamment sur :
Pour un développeur, l'essentiel à retenir est que ces critères sont de l'ordre du design d'interface autant que du code : ils se traitent dès la conception, pas en fin de projet. Le choix de la pile technique compte aussi : les frameworks modernes facilitent certaines choses (titres, routage, gestion du focus) à condition de les configurer avec soin, comme on le voit dans notre comparatif Vite ou Next.js pour démarrer un projet React.
Un audit complet relève d'un spécialiste, mais vous pouvez détecter les défauts majeurs seul, avec une routine simple.
alt, contraste, labels manquants) : un score élevé ne prouve pas la conformité.h1, que les niveaux de titres ne sautent pas, et que la langue de la page est déclarée (<html lang="fr">).Si vous développez avec React, les bibliothèques de test qui interrogent l'interface par rôles (boutons, champs étiquetés) incitent naturellement à écrire un HTML accessible : c'est un des bénéfices de l'approche décrite dans notre guide sur le test d'une application React avec Vitest, Testing Library et Playwright.
Les interfaces modernes mettent en défaut les réflexes de l'époque des pages statiques. Trois situations reviennent sans cesse.
dialog simplifie une partie de ce travail.aria-live bien placée répond à ce besoin, à condition de ne pas inonder l'utilisateur de notifications.Le principe général : n'ajoutez des attributs ARIA que pour combler un manque que le HTML natif ne couvre pas. Un mauvais usage d'ARIA est souvent pire que pas d'ARIA du tout, parce qu'il promet à l'utilisateur un comportement que l'interface ne fournit pas.
Sur un forum, une partie du contenu n'est pas écrite par l'éditeur : messages, images jointes, liens, parfois vidéos. Les exigences techniques portent d'abord sur le gabarit que vous maîtrisez : structure des fils de discussion (titres, listes de messages), formulaire de réponse étiqueté, boutons de modération atteignables au clavier, pagination claire, messages d'erreur lisibles. Côté contenu, vous pouvez faciliter le travail des contributeurs : un champ pour décrire une image jointe, une aide à la rédaction rappelant de ne pas écrire un message entier en majuscules ou de ne pas utiliser une image pour porter un texte, un éditeur qui produit des listes et des titres réels plutôt que du texte mis en forme à la main. Ces choix relèvent de la conception de la plateforme, et ils se prennent bien avant la première ligne de CSS. Pour le contexte général de ce type de projet, voir notre guide pour créer et animer un forum en ligne.
Corriger après coup coûte toujours plus cher que bien faire dès le départ. Quelques pratiques d'équipe, éprouvées, limitent les retours en arrière :
div cliquables, les images sans alt, les champs sans label.Les bonnes pratiques générales de qualité, comme les tests et le contrôle de version, forment un socle commun : nous les détaillons dans les bonnes pratiques du développeur débutant (Git, tests, debug).
Si vous faites appel à une agence ou à un freelance pour un site soumis à des obligations, demandez des éléments concrets plutôt qu'une promesse de « conformité ». Une déclaration d'accessibilité honnête mentionne les écarts connus ; un rapport d'audit précise les critères testés et la méthode ; un engagement contractuel précise le niveau visé (par exemple WCAG 2.1 ou 2.2 niveau AA) et les modalités de correction. Des conseils pour choisir un prestataire web conforme sur le volet protection des données montrent la même logique de vérification, applicable à l'accessibilité.
Enfin, gardez en tête que l'accessibilité n'est pas réservée aux sites publics ou aux grands comptes : un formulaire de contact lisible au clavier, des images décrites et des contrastes soignés améliorent l'expérience de tous les visiteurs, y compris sur mobile en plein soleil, et facilitent aussi le travail des moteurs de recherche qui lisent votre structure HTML.
Retenez deux idées. D'abord, le périmètre réglementaire dépend du type d'organisme : le RGAA vise le secteur public, certains organismes privés et les entreprises au-delà de 250 millions d'euros de chiffre d'affaires en France, tandis que l'acte européen, applicable depuis le 28 juin 2025, concerne des produits et services privés précis, avec une exemption pour les microentreprises de services. Ensuite, le socle technique est commun et à la portée de tout développeur : éléments HTML natifs, alternatives textuelles, étiquettes de formulaire, contrastes, clavier, focus. Commencez par un test clavier et un contrôle de contraste sur vos trois pages les plus visitées : en une heure, vous saurez où vous en êtes.
Le RGAA s'applique aux organismes publics, à certains organismes privés chargés d'une mission d'intérêt général et aux entreprises dont le chiffre d'affaires atteint 250 millions d'euros en France (moyenne des trois derniers exercices). Un blog personnel ou le site d'une petite entreprise n'y figure pas en tant que tel, mais le référentiel reste une bonne grille de contrôle.
La directive (UE) 2019/882 s'applique depuis cette date aux produits mis sur le marché et aux services qu'elle couvre, comme le commerce électronique, les services bancaires pour les consommateurs ou les services de transport de voyageurs. Les microentreprises prestataires de services, avec moins de 10 personnes et un chiffre d'affaires annuel inférieur à 2 millions d'euros, en sont exemptées.
Les WCAG sont les règles internationales du W3C pour l'accessibilité des contenus web. Le RGAA est le référentiel technique français qui les traduit en critères testables, avec une méthode de vérification. La version 4.1.2 du RGAA s'appuie sur les WCAG 2.1 au niveau AA.
Non. Les outils automatiques détectent une partie des défauts, comme un alt manquant, un contraste insuffisant ou un label absent. Ils ne peuvent pas juger la pertinence d'un texte alternatif ni l'ordre logique de navigation : un test au clavier et au lecteur d'écran reste nécessaire.
Commencez par le HTML sémantique : boutons et liens natifs, titres hiérarchisés, labels sur les champs, alt sur les images. Ajoutez ensuite un contrôle de contraste et un test à la touche Tab sur vos pages principales, avant d'approfondir avec un lecteur d'écran.