Accessibilité chatbot RGAA : le guide de conformité

Pourquoi l'accessibilité d'un chatbot est un enjeu de conformité

Un chatbot IA ajoute une couche d'interaction supplémentaire sur un site déjà soumis à des obligations d'accessibilité. Si cette couche n'est pas conçue pour être utilisable au clavier, compatible avec un lecteur d'écran et suffisamment contrastée, elle peut rendre l'ensemble du site non conforme, même si le reste des pages respecte le RGAA.

L'accessibilité numérique repose sur un référentiel international : les WCAG (Web Content Accessibility Guidelines), publiées par le W3C. Le RGAA est la déclinaison française de ces règles, et la norme européenne EN 301 549 en constitue la traduction réglementaire pour l'ensemble de l'Union européenne. Concrètement, un chatbot conforme au RGAA respecte de facto les exigences de l'EAA sur son périmètre numérique.

La méthode technique du RGAA version 4.1.2 (mise à jour en avril 2023 par la DINUM, la direction interministérielle du numérique) vérifie la conformité aux 50 critères de succès des niveaux A et AA de la norme WCAG 2.1 retenus comme niveau d'exigence légal en Europe, répartis en 106 critères de contrôle. Le RGAA a fait disparaître la distinction entre niveau A et AA : toutes ces règles sont désormais considérées comme obligatoires.

Concrètement, cette exigence ne vise pas un profil unique d'utilisateur. Elle couvre les personnes qui naviguent avec un lecteur d'écran (cécité, malvoyance sévère), celles qui utilisent un agrandisseur d'écran ou un affichage à fort contraste, celles qui pilotent leur navigateur au clavier ou par commande vocale (handicap moteur), et celles qui ont besoin d'un langage simplifié (troubles cognitifs, dyslexie, illettrisme numérique). Un chatbot mal conçu peut cumuler plusieurs de ces obstacles en une seule interface : c'est ce qui en fait un point de vigilance disproportionné par rapport à sa taille sur la page.

Source : accessibilite.numerique.gouv.fr — RGAA, DINUM

European Accessibility Act : ce qui change depuis juin 2025

L'European Accessibility Act (EAA, directive UE 2019/882) est entré en application le 28 juin 2025. Contrairement au RGAA, qui visait historiquement le secteur public et certains grands acteurs privés en France, l'EAA élargit les obligations d'accessibilité numérique à un ensemble de secteurs privés B2C dans toute l'Union européenne.

En France, la transposition s'est faite via la loi n° 2023-171 du 9 mars 2023, puis par le décret n° 2023-931 et l'arrêté du 9 octobre 2023, qui fixent les exigences d'accessibilité applicables aux produits et services. La conformité technique s'apprécie via la norme EN 301 549, elle-même alignée sur la méthode RGAA 4.1.2 pour la partie web.

Une période transitoire jusqu'en 2030 pour l'existant

Les services déjà commercialisés avant le 28 juin 2025 bénéficient d'une période transitoire jusqu'au 28 juin 2030. En revanche, tout service ou contenu numérique mis en ligne après le 28 juin 2025 doit être conforme dès sa publication. Un chatbot déployé aujourd'hui sur un site e-commerce ou bancaire entre directement dans le périmètre applicable, sans délai de grâce.

Des sanctions qui visent directement le service numérique

En cas de non-conformité constatée, la DGCCRF (Direction générale de la concurrence, de la consommation et de la répression des fraudes) peut prononcer des sanctions pouvant atteindre 50 000 € par service non conforme. Les contrôles ont débuté à l'entrée en vigueur du texte, notamment sur la base de signalements.

Sources : economie.gouv.fr — DGCCRF, obligations de la directive Accessibilité et EUR-Lex — directive (UE) 2019/882.

Pour la dimension réglementaire IA plus large qui s'ajoute à ces obligations d'accessibilité, voir notre article sur l'AI Act et la conformité chatbot : les deux textes se recoupent, notamment sur l'obligation d'informer clairement l'utilisateur qu'il échange avec une IA.

RGAA et WCAG 2.1 AA : les critères concrets pour un widget de chat

Un widget de chatbot n'est pas une simple fenêtre de texte : c'est un composant interactif complexe, avec un bouton d'ouverture, une zone de conversation dynamique, un champ de saisie et parfois des boutons de suggestion. Chacun de ces éléments doit répondre à des critères précis du RGAA et des WCAG 2.1 AA.

Avant de publier un widget, il est recommandé de le tester avec des outils d'audit automatisés comme axe DevTools ou WAVE, qui détectent une partie des non-conformités (contrastes, attributs manquants, structure de titres). Ces outils ne remplacent toutefois pas un test manuel avec un vrai lecteur d'écran et une navigation 100 % clavier : une bonne partie des critères RGAA (cohérence de l'ordre de lecture, pertinence des annonces vocales, logique du parcours) ne peut être vérifiée que par un test humain.

Navigation au clavier

Un utilisateur qui ne peut pas utiliser de souris (handicap moteur, mais aussi utilisateurs avancés) doit pouvoir ouvrir le widget, écrire un message, l'envoyer et fermer la fenêtre uniquement au clavier, avec les touches Tab, Entrée et Échap. Aucune action ne doit être accessible uniquement à la souris (survol, glisser-déposer). L'ordre de tabulation doit suivre l'ordre logique de lecture.

Lecteurs d'écran et attributs ARIA

Pour un utilisateur non-voyant ou malvoyant naviguant avec un lecteur d'écran (JAWS, NVDA, VoiceOver), le widget doit exposer une structure sémantique claire : rôle role="log" ou aria-live="polite" sur la zone de conversation pour que les nouveaux messages soient annoncés automatiquement, aria-label explicite sur le bouton d'ouverture et le champ de saisie, et un focus qui se déplace logiquement à l'ouverture du widget vers le premier élément interactif.

Contrastes et visibilité du focus

Le RGAA exige un ratio de contraste minimal de 4,5:1 entre le texte et son arrière-plan (3:1 pour les grands textes), conformément au critère WCAG 1.4.3. Chaque élément interactif du widget — bouton d'envoi, bulles de message, liens dans les réponses — doit également afficher un indicateur de focus visible (contour, surlignage) lorsqu'il est atteint au clavier, pour que l'utilisateur sache toujours où il se trouve dans l'interface.

Qui est concerné et quels sont les risques de non-conformité

Le secteur public : une obligation déjà ancienne

Les sites, applications et services numériques du secteur public sont soumis au RGAA depuis l'article 47 de la loi du 11 février 2005. Cela inclut les collectivités territoriales, comme le détaille notre article sur le chatbot IA pour mairie et collectivité : un widget déployé sur le site d'une commune doit être accessible au même titre que le reste du site, avec un schéma pluriannuel de mise en accessibilité et un plan d'action annuel. Les établissements publics, universités et organismes de sécurité sociale relèvent du même régime.

L'e-commerce, la banque et les grandes entreprises : le nouveau périmètre EAA

L'EAA cible en priorité les entreprises de plus de 10 salariés et 2 millions d'euros de chiffre d'affaires qui fournissent un service B2C dans un secteur couvert : e-commerce, services bancaires, transport de voyageurs, communications électroniques, livres numériques, médias audiovisuels. Les micro-entreprises (moins de 10 salariés ET moins de 2 M€ de chiffre d'affaires) en sont exemptées, mais toute entreprise au-delà de ce seuil dans un secteur couvert doit s'y conformer. Un chatbot de service client ou de qualification de leads sur un site e-commerce entre directement dans ce périmètre, y compris lorsqu'il est fourni par un prestataire externe : la responsabilité de la conformité reste celle de l'entreprise qui l'expose à ses clients.

Les risques concrets d'un chatbot non accessible

Au-delà de la sanction financière (jusqu'à 50 000 € par service non conforme côté EAA), le risque est aussi opérationnel : un utilisateur qui ne peut pas interagir avec le chatbot se retrouve privé du canal de support le plus rapide du site, ce qui dégrade son expérience et peut constituer une discrimination indirecte au sens du droit. S'y ajoute un risque d'image : un signalement d'inaccessibilité relayé publiquement, ou une non-conformité constatée lors d'un contrôle DGCCRF, touche directement la réputation de la marque auprès d'un public de plus en plus attentif à l'inclusion numérique.

Pour les acteurs qui traitent déjà des données sensibles via leur chatbot, ce risque s'ajoute aux obligations décrites dans notre guide de conformité RGPD chatbot et dans notre article sur la sécurité des données chatbot IA : accessibilité, RGPD et sécurité forment un socle de conformité qui s'évalue ensemble, pas séparément. Un audit de conformité gagne à traiter ces trois volets dans la même démarche plutôt qu'en silos successifs.

Comment un chatbot IA bien conçu améliore l'inclusion

L'accessibilité n'est pas qu'une contrainte technique à cocher : un chatbot IA bien conçu peut au contraire élargir l'accès au service pour des publics souvent mal servis par les interfaces classiques.

Un langage clair, sans jargon

Contrairement à un formulaire multi-champs ou à une arborescence de menus, un chatbot permet de poser une question en langage naturel. Pour les personnes ayant des difficultés de lecture, une déficience cognitive légère ou simplement peu à l'aise avec le numérique, cela réduit la charge mentale par rapport à la navigation dans des pages complexes. Un chatbot bien paramétré répond avec des phrases courtes, sans jargon technique, ce qui rejoint directement les exigences de clarté du RGAA (critère 8 sur la structuration de l'information).

Un canal multimodal et complémentaire

Un chatbot texte n'est jamais le seul canal : il doit rester une option parmi d'autres (téléphone, email, accueil physique), et non un substitut imposé. En revanche, associé à des synthèses vocales de navigateur ou à des lecteurs d'écran correctement supportés, il offre une alternative utile à une navigation par clic pour les personnes malvoyantes ou à mobilité réduite. C'est un principe déjà appliqué dans le secteur public, où le chatbot doit rester un canal numérique complémentaire, jamais un remplacement de l'accueil humain.

Une disponibilité qui réduit les frictions

Un chatbot disponible 24/7 réduit aussi une friction indirecte : les personnes en situation de handicap ont parfois besoin de plus de temps pour formuler une demande, ou dépendent d'un tiers pour être disponibles à des horaires précis. Un canal asynchrone, accessible à tout moment, supprime cette contrainte temporelle — à condition que l'interface elle-même reste utilisable sans souris ni perception fine des couleurs.

Enfin, un chatbot IA basé sur une base de connaissances (RAG) évite un écueil fréquent des FAQ classiques : obliger l'utilisateur à parcourir une longue page ou un PDF pour trouver l'information exacte dont il a besoin. Pour une personne malvoyante utilisant un agrandisseur d'écran, ou pour une personne ayant des difficultés de concentration, poser directement la question et recevoir une réponse ciblée représente un gain d'autonomie réel — à condition, encore une fois, que le widget lui-même reste pleinement accessible.

Checklist accessibilité pour votre chatbot IA

Pour les organisations qui déploient un chatbot en interne ou en support client, cette checklist s'ajoute naturellement aux vérifications de sécurité et de conformité RGPD à mener avant toute mise en production. Découvrez comment Heeya permet de déployer un chatbot conforme sans développement sur mesure.

FAQ — accessibilité chatbot RGAA

Pour aller plus loin

Pour creuser la référence technique complète, consultez la référence rapide WCAG 2.1 du W3C, qui détaille chacun des critères de succès repris par le RGAA. Sur le volet réglementaire, l'accessibilité n'est qu'un des chantiers de conformité à mener autour d'un chatbot IA : RGPD, sécurité des données et AI Act s'évaluent ensemble pour une mise en production sereine.