FR
EN
JA
PT
ES
IT
DE
SV
DA
RU
ZH
AR
NL
EL
LV
KO
TR
FR
EN
JA
PT
ES
IT
DE
SV
DA
RU
ZH
AR
NL
EL
LV
KO
TR
Depuis plusieurs années, les solutions d’accessibility overlays promettent une mise en conformité rapide des sites web. Leur promesse est séduisante : quelques lignes de JavaScript, un abonnement mensuel, et votre site deviendrait accessible sans modifier son code. Sur le papier, l’idée paraît presque idéale. Dans la réalité, les choses sont beaucoup plus complexes. Les études […]
Résumé de l’actualité
Depuis plusieurs années, les solutions d’accessibility overlays promettent une mise en conformité rapide des sites web. Leur promesse est séduisante : quelques lignes de JavaScript, un abonnement mensuel, et votre site deviendrait accessible sans modifier son code.
Sur le papier, l’idée paraît presque idéale.
Dans la réalité, les choses sont beaucoup plus complexes.
Les études techniques, les retours d’expérience des spécialistes de l’accessibilité numérique et les limites intrinsèques des frameworks modernes montrent que ces solutions ne peuvent corriger qu’une partie des problèmes, et souvent de manière fragile. Elles interviennent après le rendu de la page, alors que les véritables causes des défauts d’accessibilité résident dans le code source lui-même.
Le principe d’un overlay consiste à analyser la page une fois qu’elle est affichée dans le navigateur, puis à modifier dynamiquement le DOM : ajout d’attributs ARIA, modification d’attributs HTML, insertion d’éléments invisibles, ajustement du focus, etc.
Cette approche présente immédiatement une limite fondamentale.
Elle ne participe pas à la construction de l’interface : elle tente de la réparer une fois celle-ci terminée.
C’est un peu comme vouloir corriger les fondations d’une maison une fois le bâtiment construit.
Aujourd’hui, la majorité des applications web utilisent des frameworks comme React, Angular, Vue ou encore Svelte.
Tous reposent sur le même principe : le framework est le seul maître du DOM.
À chaque changement d’état, il reconstruit tout ou partie de l’interface. Toute modification réalisée par un script externe risque alors d’être immédiatement supprimée lors du prochain rendu.
Autrement dit, l’overlay ne travaille pas avec le framework ; il travaille contre lui.
Chaque correction doit être surveillée, détectée puis réappliquée en permanence.
Cette course permanente contre le moteur de rendu introduit de la complexité, de la consommation de ressources et une fragilité qui n’existe pas lorsque l’accessibilité est directement intégrée dans le composant.
Certaines corrections sont relativement simples.
Ajouter un aria-label à un bouton statique ou définir un rôle ARIA sur un élément qui ne change jamais est généralement possible.
En revanche, dès que l’on touche à des composants interactifs, les difficultés apparaissent rapidement.
Les overlays ne connaissent pas l’état interne des composants React ou Angular. Ils ne savent pas pourquoi un menu est ouvert, pourquoi une boîte de dialogue apparaît ou pourquoi un bouton devient actif.
Ils tentent de deviner ce fonctionnement en observant le DOM.
Cette méthode fonctionne… jusqu’au jour où un développeur modifie une classe CSS, renomme un identifiant, change un composant ou fait évoluer l’architecture de l’application.
La correction cesse alors de fonctionner, parfois sans que personne ne s’en aperçoive.
Une autre idée reçue consiste à croire que l’on peut rendre une interface accessible simplement en ajoutant des attributs ARIA.
Or ARIA n’a jamais eu vocation à remplacer le HTML sémantique.
Un <div> auquel on ajoute role="button" ne devient pas un véritable bouton HTML.
Il faut également gérer correctement le focus clavier, les événements clavier, les états actifs, les annonces aux technologies d’assistance, les interactions avec les lecteurs d’écran et bien d’autres comportements.
Le HTML natif fournit déjà tout cela.
Les overlays tentent d’en reproduire une partie, mais ne peuvent jamais égaler la robustesse des composants correctement développés dès l’origine.
Même lorsqu’un correctif fonctionne aujourd’hui, rien ne garantit qu’il fonctionnera encore demain.
Les sites web évoluent constamment :
Chaque évolution peut invalider les sélecteurs utilisés par l’overlay.
Une classe CSS renommée, un composant déplacé ou une structure HTML légèrement modifiée suffisent parfois à rendre le correctif inopérant.
On entre alors dans une logique de maintenance permanente, où chaque évolution du site nécessite de revoir les mécanismes de correction.
Un autre aspect est souvent sous-estimé.
Lorsque l’accessibilité repose principalement sur une solution d’overlay, elle dépend directement du fournisseur.
Les corrections ne font pas partie du code de l’application.
Elles sont apportées par un service externe.
Si le contrat s’arrête, si le script n’est plus chargé ou si le fournisseur cesse son activité, une partie importante des corrections disparaît immédiatement.
À l’inverse, lorsqu’un site est développé selon les bonnes pratiques d’accessibilité, celles-ci restent intégrées au produit lui-même.
L’accessibilité devient un patrimoine logiciel et non un service loué.
Respecter une norme est une chose.
Permettre à une personne en situation de handicap d’utiliser réellement un service en est une autre.
Une interface peut satisfaire une partie des critères techniques tout en restant difficile, voire impossible, à utiliser avec un lecteur d’écran, uniquement au clavier ou avec une commande vocale.
L’accessibilité ne consiste pas uniquement à ajouter quelques attributs techniques.
Elle concerne l’expérience complète de navigation, de compréhension et d’interaction.
La véritable accessibilité commence dès la conception.
Elle implique des composants correctement développés, une structure HTML sémantique, une gestion rigoureuse du clavier, des contrastes suffisants, des formulaires bien conçus et des tests réalisés avec de véritables technologies d’assistance.
Cette approche demande certes davantage d’investissement au départ.
En contrepartie, elle produit un résultat plus robuste, plus pérenne, plus facile à maintenir et réellement bénéfique pour les utilisateurs.
Les overlays peuvent parfois apporter des améliorations ponctuelles ou corriger certains défauts mineurs.
En revanche, ils ne remplacent pas un développement accessible.
L’accessibilité ne peut pas être ajoutée après coup comme une couche de peinture. Elle fait partie intégrante de la qualité du logiciel.
Les solutions d’overlay répondent à une promesse séduisante : rendre un site accessible rapidement, sans modifier son code.
Mais cette promesse se heurte aux réalités techniques des applications modernes.
Plus les interfaces deviennent dynamiques et complexes, plus les limites de ces approches apparaissent.
L’accessibilité ne peut pas être considérée comme une fonctionnalité que l’on ajoute après le développement.
Elle doit être pensée, conçue et développée dès l’origine.
C’est cette démarche qui garantit une accessibilité durable, conforme aux standards et, surtout, réellement utile aux personnes qui en ont besoin.
« Les solutions d’overlay peuvent apporter des améliorations ponctuelles, mais elles ne remplacent pas une accessibilité intégrée dès la conception. Les standards du W3C, les référentiels nationaux comme le RGAA et les prises de position de la communauté internationale convergent sur un point : la meilleure manière de rendre un site accessible consiste à corriger directement son code source plutôt qu’à tenter de le réparer après son rendu. »
À propos de l'auteur·rice
Mayeul Beretta
Président du Média de l’Accessibilité
