2026-02-11 · Rédaction Baduno · 8 blog.readMin · Blog & Savoir
Loi sur le renforcement de l'accessibilité : ce que les sites Web doivent désormais respecter
Depuis juin 2025, le BFSG est en vigueur – et de nombreux sites d'entreprise sont concernés. Les obligations, classées de manière compréhensible, sans panique.
Qui est concerné
La loi couvre les services électroniques orientés consommateurs – notamment les boutiques en ligne et de nombreux parcours de réservation et de contact. Les offres purement B2B et les micro-entreprises sont partiellement exemptées ; la classification doit être vérifiée juridiquement en cas de doute.
Ce qui est exigé
En pratique, les exigences s'alignent sur les WCAG : perceptible (contrastes, textes alternatifs), utilisable (clavier, focus), compréhensible (langage clair, messages d'erreur) et robuste (HTML propre pour les technologies d'assistance).
La bonne nouvelle
Les sites Web accessibles sont presque toujours aussi plus rapides, mieux structurés et plus favorables aux moteurs de recherche. L'obligation contribue à une qualité qui est de toute façon rentable – et ouvre un large groupe d'utilisateurs souvent ignoré.
Démarrer de manière pragmatique
D'abord vérifier (automatisé plus manuel), puis prioriser selon l'impact : contrastes, textes alternatifs, formulaires et navigation au clavier résolvent la majorité des obstacles quotidiens. Une déclaration d'accessibilité documente honnêtement l'état.
Hreflang et accessibilité : une interaction souvent négligée
Les sites Web multilingues sont confrontés à un défi supplémentaire : les exigences d'accessibilité s'appliquent séparément à chaque version linguistique. L'attribut hreflang, qui indique aux moteurs de recherche l'affectation de la langue et de la région, doit être implémenté de manière à ce que les lecteurs d'écran et autres technologies d'assistance reconnaissent correctement les changements de langue. Si hreflang est mal défini ou absent, cela peut considérablement compliquer la navigation pour les utilisateurs malvoyants – par exemple, lorsqu'une page est soudainement chargée dans une autre langue sans que l'utilisateur s'y attende. Concrètement, cela signifie que chaque variante linguistique doit offrir non seulement des traductions, mais aussi des structures entièrement accessibles. Cela inclut des déclarations de langue correctes dans le HTML (attribut lang) et des textes alternatifs cohérents dans toutes les langues. La configuration hreflang doit donc être incluse dès le départ dans le contrôle d'accessibilité.
Outils de test automatisés : forces et limites
Des outils comme axe, Wave ou Lighthouse peuvent détecter automatiquement de nombreuses barrières techniques, par exemple des textes alternatifs manquants, des contrastes insuffisants ou des attributs ARIA incorrects. Cependant, ils ne remplacent pas un contrôle manuel, car des éléments comme la compréhensibilité des textes, l'ordre logique du contenu ou l'utilisabilité des formulaires avec des technologies d'assistance ne peuvent être évalués que par des tests utilisateurs réels. Les contrôles automatisés fournissent une première analyse rapide des erreurs et sont bien adaptés aux tests continus dans les pipelines CI/CD. Cependant, les résultats doivent toujours être évalués par un humain, car les outils produisent à la fois des faux positifs et des faux négatifs. Un workflow pragmatique : d'abord des tests automatisés, puis un échantillon manuel avec un lecteur d'écran et un clavier, et enfin un test d'utilisabilité final avec les personnes concernées.
Conséquences juridiques et délais de transition
Le BFSG prévoit des amendes et des avertissements si les sites web ne répondent pas aux exigences. Pour les produits mis en service avant le 28 juin 2025, une période de transition est accordée jusqu'au 28 juin 2030 – mais uniquement pour ceux qui étaient déjà accessibles avant cette date ou pour lesquels il est prouvé que des travaux sont en cours. Quiconque lance un nouveau site web ou une refonte après le 28 juin 2025 doit immédiatement satisfaire à toutes les exigences. Attention : la loi s'applique à tous les contenus nouvellement créés ; les contenus plus anciens (par exemple les pages d'archives) peuvent éventuellement nécessiter des adaptations plus complexes. Dans la pratique, il est recommandé de documenter par écrit les progrès réalisés afin de pouvoir prouver, en cas de contestation, que l'accessibilité est mise en œuvre progressivement. Une déclaration d'accessibilité sur le site web est de toute façon obligatoire.
Depuis juin 2025, le BFSG est en vigueur – et de nombreux sites d'entreprise sont concernés. Les obligations, classées de manière compréhensible, sans panique.
L'accessibilité comme partie de la stratégie SEO internationale
Les sites web accessibles ne remplissent pas seulement les exigences légales, mais aussi de nombreux critères que les moteurs de recherche évaluent positivement : structure HTML sémantique, hiérarchies de titres claires, textes alternatifs pertinents et temps de chargement rapides. Ces facteurs sont pertinents pour le SEO dans toutes les langues. De plus, les moteurs de recherche peuvent explicitement pénaliser les barrières telles que les boutons non étiquetés ou les titres manquants, car elles compliquent l'indexation. Rendre son site web accessible à tous les utilisateurs améliore automatiquement l'expérience utilisateur et, par conséquent, les signaux de classement. En particulier pour les sites multilingues, il est intéressant d'intégrer l'accessibilité dès le départ dans les workflows de localisation – par exemple via des listes de contrôle pour les traducteurs afin de créer des textes alternatifs accessibles.
Tests avec des utilisateurs réels : pourquoi ils sont indispensables
Les outils automatisés ne détectent qu'une partie des obstacles. Ce n'est qu'en testant avec des personnes qui dépendent réellement de technologies d'assistance que vous saurez si votre site web fonctionne au quotidien. Les utilisateurs aveugles utilisent les lecteurs d'écran différemment de ce que simulent les tests automatisés ; les utilisateurs sourds ont des exigences différentes pour les vidéos en langue des signes ; les personnes à mobilité réduite naviguent sans souris. Un test structuré avec trois à cinq participants issus de différents groupes de handicap révèle des problèmes qu'aucun outil ne trouve – comme des ordres de focus illogiques, des informations contextuelles manquantes dans les étiquettes ARIA ou des messages d'erreur incompréhensibles. Idéalement, planifiez ces tests pendant la phase de développement, pas juste avant la mise en ligne. Documentez les résultats dans la déclaration d'accessibilité dans le cadre de votre assurance qualité. N'oubliez pas : les tests doivent être effectués séparément pour chaque version linguistique, car les traductions peuvent créer de nouveaux obstacles – par exemple si les textes alternatifs ne correspondent pas à la langue cible ou si les indications des formulaires sont grammaticalement incorrectes.
Systèmes de gestion de contenu et accessibilité : pièges liés aux plugins
De nombreux sites web reposent sur des CMS comme WordPress, TYPO3 ou Drupal. Ces systèmes proposent des plugins ou extensions qui promettent l'accessibilité – par exemple des outils de superposition qui ajustent les contrastes ou ajoutent des attributs ARIA a posteriori. Ces solutions sont généralement insuffisantes et peuvent même créer de nouvelles barrières en écrasant les structures sémantiques existantes. Il est préférable d'implémenter l'accessibilité directement dans le thème ou le modèle : structure HTML propre, hiérarchies de titres correctes, éléments de formulaire natifs. Lors du choix des plugins, assurez-vous qu'ils soient conformes aux WCAG et régulièrement mis à jour. Un autre problème : de nombreux rédacteurs ajoutent du contenu via l'éditeur visuel et négligent les textes alternatifs ou les formats de titres. Formez vos rédacteurs ou utilisez des workflows qui imposent des saisies accessibles – par exemple des champs obligatoires pour les textes alternatifs des images. Le choix du modèle CMS influence également l'accessibilité : testez chaque modèle avant utilisation avec un outil automatisé et un échantillon manuel.
Tester avec des personnes handicapées : l'étape indispensable
Les outils automatisés et les listes de contrôle manuelles révèlent de nombreuses barrières techniques, mais ils ne remplacent pas les tests avec de vrais utilisateurs. Les personnes handicapées utilisent différentes technologies d'assistance – lecteurs d'écran comme JAWS, NVDA ou VoiceOver, logiciels de grossissement, commande vocale ou claviers spéciaux. Chacune de ces combinaisons se comporte différemment, de sorte qu'un site même formellement conforme peut être inutilisable pour un utilisateur aveugle. Planifiez donc des tests utilisateurs réguliers avec un groupe hétérogène : personnes malvoyantes, à mobilité réduite et ayant des déficiences cognitives. Demandez-leur d'effectuer des tâches définies sur votre site, comme un achat de produit ou le remplissage d'un formulaire de contact. Documentez précisément les problèmes rencontrés : où la navigation bloque, quelles annonces sont incompréhensibles, quels éléments ne sont pas atteints ? Les enseignements de ces tests sont précieux, car ils montrent non seulement les barrières, mais aussi le potentiel d'optimisation pour tous les utilisateurs. Veillez à effectuer les tests séparément pour chaque version linguistique, car les traductions et les phrases complexes affectent différemment la compréhension. Intégrez les résultats dans votre processus d'amélioration continue – l'accessibilité n'est pas un projet ponctuel, mais une tâche permanente.
Ancrer l'accessibilité dans le système de gestion de contenu
De nombreux défauts d'accessibilité surviennent dès la création de contenu : les rédacteurs oublient les textes alternatifs, n'utilisent pas les titres hiérarchiquement ou créent des liens avec des mots vagues comme « cliquez ici ». Pour éviter cela, vous devez ancrer l'accessibilité directement dans votre système de gestion de contenu (CMS). Formez vos équipes de rédaction aux bases des WCAG – et ce, séparément pour chaque équipe linguistique, afin que les exigences ne soient pas compromises par des différences culturelles dans la rédaction. Utilisez des plugins ou extensions CMS qui imposent des champs obligatoires pour les textes alternatifs lors de l'insertion d'images ou qui affichent visuellement une hiérarchie de titres. Intégrez des contrôles automatisés dans le workflow de validation, qui signalent avant publication les erreurs courantes comme les étiquettes manquantes ou les contrastes insuffisants. Assurez-vous également que les modèles et thèmes CMS que vous utilisez sont déjà construits de manière accessible – avec des points de repère ARIA corrects, une gestion du focus clavier et du HTML sémantique. Pour les sites multilingues, il est essentiel que le CMS prenne en charge la localisation des structures accessibles, par exemple en définissant automatiquement les attributs hreflang et les déclarations de langue. Un processus d'accessibilité bien intégré dans le CMS réduit les efforts de correction et garantit une qualité constante dans toutes les versions linguistiques.
blog.faqT
Que se passe-t-il si mon site web enfreint le BFSG ?
En cas de violation du BFSG, des amendes peuvent être imposées. De plus, il faut s'attendre à des avertissements de la part des concurrents ou des associations de consommateurs. Le montant des amendes dépend de la gravité de l'infraction et peut aller jusqu'à 100 000 euros. Une déclaration d'accessibilité indiquant la portée et l'état des mesures est obligatoire et sert de preuve.
Les traductions de mon site web doivent-elles également être accessibles ?
Oui, chaque version linguistique doit individuellement satisfaire aux exigences d'accessibilité. Cela inclut des attributs de langue corrects (lang), des textes alternatifs traduits ainsi qu'une navigation à faible barrière. L'attribut hreflang doit être défini de sorte que les moteurs de recherche et les technologies d'assistance reconnaissent correctement les changements de langue. Les agences de traduction doivent donc également veiller à l'accessibilité de leurs livraisons.
