Accessibilité ≠ Overlay : quand un overlay interfère avec le lecteur d’écran
Les lecteurs d’écran restituent par la parole ou le braille les informations qu’une interface expose de manière programmatique. Leurs utilisateurs apprennent leurs commandes, règlent leurs préférences et développent des stratégies pour parcourir titres, liens, régions, formulaires et contrôles. Le W3C classe les lecteurs d’écran parmi les technologies d’assistance utilisées sur le Web. Le point de départ doit donc être un site correctement construit, pas une tentative de remplacer l’outil de l’utilisateur depuis la page.
Le lecteur d’écran est déjà la technologie d’assistance de l’utilisateur
Les lecteurs d’écran restituent par la parole ou le braille les informations qu’une interface expose de manière programmatique. Leurs utilisateurs apprennent leurs commandes, règlent leurs préférences et développent des stratégies pour parcourir titres, liens, régions, formulaires et contrôles. Le W3C classe les lecteurs d’écran parmi les technologies d’assistance utilisées sur le Web. Le point de départ doit donc être un site correctement construit, pas une tentative de remplacer l’outil de l’utilisateur depuis la page.
Ce dont un lecteur d’écran a réellement besoin sur un site
L’interopérabilité dépend du code : HTML sémantique, vrais titres, liens et boutons identifiables, libellés associés aux champs, noms accessibles, rôles, états et valeurs corrects, ainsi qu’une gestion cohérente du focus. Le W3C explique que les lecteurs d’écran peuvent utiliser la structure des titres pour naviguer et que les contrôles HTML standards favorisent l’interopérabilité. Si cette base échoue, le problème se situe dans l’implémentation du site.
Ce qui change lorsqu’un overlay intervient
Certains overlays injectent du JavaScript tiers qui analyse la page et tente de réparer des problèmes côté interface. La technologie d’assistance peut alors recevoir une version modifiée de l’interface. L’Overlay Fact Sheet avertit que ces réparations peuvent ralentir le chargement ou provoquer des changements inattendus pour les utilisateurs de technologies d’assistance. Tous les overlays ne produisent pas systématiquement la même panne, mais une variable supplémentaire est introduite entre le site et le lecteur d’écran.
Focus, clavier et structure : de petits changements peuvent devenir de grands obstacles
Pour une personne qui navigue sans la vue, le focus détermine sa position et l’élément qu’elle va manipuler. Un déplacement inattendu du focus, une touche interceptée ou une sémantique modifiée peuvent désorienter complètement. Il en va de même pour des titres artificiels, des noms peu fiables ou des états mal annoncés. L’Overlay Fact Sheet rassemble des témoignages d’utilisateurs décrivant des sauts de focus et une navigation rendue plus difficile.
Un bouton « profil lecteur d’écran » pose la mauvaise question
La question n’est pas de savoir si l’utilisateur a activé un profil spécial, mais si le site fonctionne dès le départ avec sa technologie d’assistance habituelle. Le W3C souligne que les personnes utilisent des configurations et des outils différents selon leurs besoins et préférences. Devoir trouver un widget, l’ouvrir puis sélectionner un mode supplémentaire ajoute des étapes sans garantir la correction des obstacles d’origine.
Tous les utilisateurs de lecteurs d’écran ne naviguent pas de la même façon
NVDA, JAWS, VoiceOver, TalkBack et d’autres solutions ont des commandes et modes différents. Chaque personne configure aussi la voix, la vitesse, la ponctuation, le braille et la navigation. Concevoir une expérience universelle de « lecteur d’écran » est donc risqué. Une accessibilité robuste expose des informations standards et prévisibles.
Une sémantique correcte laisse l’utilisateur décider comment naviguer
Un bon titre n’est pas simplement un texte agrandi. Un champ n’est pas accessible parce qu’un mot apparaît visuellement à proximité. Avec un HTML approprié et, si nécessaire, un ARIA correct, le lecteur d’écran peut transmettre la structure et l’utilisateur naviguer avec ses propres commandes. Le W3C recommande les éléments natifs lorsque c’est possible et ARIA pour communiquer rôles, états et propriétés.
Tester avec un lecteur d’écran ne consiste pas seulement à vérifier que la page parle
Entendre du texte ne prouve pas qu’une page est utilisable. Il faut tester des tâches complètes : atteindre le contenu principal, comprendre la hiérarchie, utiliser menus et formulaires, identifier les erreurs, manipuler les dialogues et composants dynamiques et retrouver son orientation. Les tests au clavier et avec des utilisateurs habituels de ces technologies sont également importants.
Ce qu’une entreprise devrait faire au lieu de compter sur une couche
Il faut d’abord identifier les obstacles réels puis les corriger dans le composant, le modèle, le thème ou l’application qui les génère. HTML sémantique, modèles accessibles, bonne gestion du focus et tests avec des combinaisons représentatives de navigateur et technologie d’assistance. L’automatisation peut détecter certains problèmes, mais l’expérience au lecteur d’écran exige des tests fonctionnels et humains.
Accessibilité ≠ Overlay
Cette livraison 06 repose sur une idée simple : le lecteur d’écran appartient à l’utilisateur, pas au site. Le site doit offrir une interface solide et prévisible avec laquelle cette technologie peut interagir. Si une couche modifie structure, focus ou sémantique, elle peut transformer une barrière connue en une autre plus difficile à diagnostiquer. La solution durable reste la correction à la source et les tests avec de vraies technologies d’assistance.
Sources officielles et techniques
W3C Web Accessibility Initiative (WAI)
Tools and Techniques — How People with Disabilities Use the Web
Page Structure Tutorial
WAI-ARIA Overview
Overlay Fact Sheet
Overlay Fact Sheet — assistive technology experiences and limitations
Entrega 06 — Overlays y lectores de pantalla.