Les surcouches d'accessibilité : la correction en une ligne qui vous vaut un procès

Réponse courte : non. Un overlay d'accessibilité, le script qui dépose un widget sur un site existant, ne le rend pas conforme. Des tests indépendants montrent que les overlays ne détectent qu'une fraction des problèmes WCAG, qu'une part croissante des poursuites en accessibilité vise des sites qui en ont un installé, et que la FTC a déjà infligé une amende à un grand fournisseur d'overlay pour avoir affirmé le contraire. La conformité réelle se construit dans les composants, elle ne s'ajoute pas par-dessus.

Qu'est-ce qu'un overlay d'accessibilité, et pourquoi est-il vendu comme une solution ?

Un overlay est une simple balise <script> qu'un fournisseur vend comme un raccourci vers la conformité. Une fois installé, il ajoute un widget flottant avec des réglages de taille de police, de contraste, et un bouton « pause des animations », et il exécute des scripts automatisés qui tentent de corriger la page à la volée : en devinant le texte alternatif, en ajustant les valeurs de couleur, en réécrivant des attributs ARIA qu'il n'a pas écrits.

L'argument de vente est réellement séduisant : pas de revue de code, pas de temps de designer, et un badge qui affirme que le site est protégé. Ce qu'il omet, c'est la partie qui compte : le widget devine sur un site qu'il n'a pas construit, au-dessus d'une page qu'il ne peut pas voir entièrement.

Quelle part des critères WCAG un overlay peut-il réellement détecter ?

Pas la majorité. Les outils automatisés, y compris les scanners intégrés aux widgets d'overlay, ne peuvent tester de façon significative qu'une minorité des critères de succès WCAG par eux-mêmes.

(Deque, Deque coverage report, à revérifier.)

L'écart est structurel, ce n'est pas un bug que la prochaine mise à jour corrigera. Un script peut confirmer qu'une image possède un attribut alt. Il ne peut pas dire si ce texte décrit l'image, si un widget personnalisé répond au clavier, ou si l'ordre de lecture a du sens pour un lecteur d'écran. Ce sont des questions de jugement, et c'est précisément ce qui fait défaut à un overlay. Le WebAIM Million, un scan annuel d'un million de pages d'accueil, a encore trouvé des échecs WCAG 2 détectables sur 95,9 % d'entre elles en 2026, contre 94,8 % l'année précédente (WebAIM, à revérifier). La détection automatisée seule ne comble pas cet écart. Elle le creuse.

Les overlays sont-ils réellement cités dans des poursuites liées à l'accessibilité ?

Oui, et la tendance ne joue pas en faveur du widget. Le rapport 2024 d'UsableNet sur les poursuites a montré qu'environ un quart de toutes les poursuites liées à l'accessibilité numérique déposées cette année-là visaient des sites disposant déjà d'un overlay installé, l'overlay lui-même étant cité comme un obstacle plutôt que comme une solution (rapporté via une couverture secondaire des données d'UsableNet, Accessibility.Works, à revérifier). Le suivi propre à UsableNet pour 2025 montre que la tendance se confirme, avec des poursuites mentionnant des widgets d'accessibilité enregistrées chaque mois : 85 en janvier, grimpant à 132 en février, puis se stabilisant entre 99 et 119 par mois jusqu'en juin (UsableNet, à revérifier).

La présence d'un widget ne prouve pas qu'il a causé la poursuite, ni que les sites sans overlay sont plus sûrs. Sur deux années de suivi, un overlay ne s'est jamais révélé un substitut crédible à la correction du code sous-jacent. Les cabinets d'avocats des plaignants le contournent lors de leurs tests, et les tribunaux ne l'ont pas traité comme un bouclier.

Que s'est-il passé entre la FTC et accessiBe ?

C'est l'affaire qui a fait passer « les overlays ne fonctionnent pas vraiment » du statut de plainte communautaire à celui de droit fédéral. En janvier 2025, la Federal Trade Commission a annoncé une plainte et une proposition de règlement contre accessiBe, l'un des fournisseurs d'overlay les plus connus, finalisée sous forme d'ordonnance le 21 avril 2025. L'accusation : l'accessWidget d'accessiBe était présenté comme capable de rendre n'importe quel site conforme au WCAG grâce à l'IA, ce qui était faux, l'outil ne parvenant pas à corriger des éléments de base comme les menus de navigation, les champs de formulaire et les descriptions d'images. La plainte alléguait en outre qu'accessiBe avait maquillé des recommandations de tiers pour les faire paraître indépendantes sans divulguer sa propre implication. L'entreprise a payé 1 million de dollars et il lui est désormais interdit d'affirmer que son produit peut rendre un site conforme au WCAG, ou le maintenir conforme dans le temps, sans preuve à l'appui (FTC, à revérifier).

Il s'agit de l'un des plus grands fournisseurs de la catégorie, dont un régulateur a jugé qu'il avait survendu ce que la catégorie peut réellement faire. Il faut voir cela comme le plafond de ce qu'un overlay peut honnêtement promettre, pas comme le plancher.

Alors, qu'est-ce qui fonctionne réellement à la place ?

Il n'existe pas de raccourci. La solution, c'est la même discipline qui rend un site bon à tous les autres égards.

1. Commencer par le composant, pas par la page. Chaque bouton, champ de formulaire, menu et fenêtre modale est construit avec un HTML sémantique et des attributs ARIA corrects dès la première version, jamais corrigé après coup.
2. Faire de la navigation au clavier un parcours à part entière. Une fonctionnalité qui ne fonctionne qu'à la souris n'est pas terminée, quel que soit son score.
3. Tester avec de véritables technologies d'assistance. Un lecteur d'écran, un passage au clavier seul, et une personne qui dépend de cette technologie au quotidien détectent ce qu'un scanner ne peut pas.
4. Soumettre le contraste et le mouvement à la norme, pas au test visuel. Les ratios de contraste WCAG 2.2 AA et la prise en charge de prefers-reduced-motion sont vérifiés, jamais supposés.
5. Retester après chaque modification. La conformité est une propriété de la version actuelle, pas un certificat acquis une fois pour toutes.

C'est pourquoi Thabrew Effect traite l'accessibilité comme faisant partie du même système que la visibilité et la conversion, jamais comme une ligne budgétaire confiée à un plugin. Un composant conçu de manière accessible dès le départ sert chaque visiteur et chaque audit à la fois. Un widget ajouté après coup ne sert qu'une capture d'écran.

Une précision avant la FAQ : rien de tout cela ne constitue un conseil juridique. Ce texte résume des recherches rendues publiques et une action fédérale d'application de la loi. Quiconque fait face à une plainte active en matière d'accessibilité a besoin d'un avocat, pas d'un article de blog.