La compatibilité avec les lecteurs d’écran signifie que le contenu, les contrôles et la structure d’un site web peuvent tous être compris et utilisés par une personne qui recourt à une technologie d’assistance lisant la page à voix haute ou l’affichant sur un afficheur braille, plutôt qu’en la regardant. Cela dépend bien plus de la façon dont le HTML sous-jacent est écrit que d’une quelconque fonctionnalité ou extension isolée. Bien faire les choses signifie porter attention ensemble à la structure sémantique, à l’ordre de lecture, à l’étiquetage et à l’utilisabilité au clavier, pas à un seul de ces éléments isolément.

Comment un lecteur d’écran perçoit réellement une page

Un lecteur d’écran ne voit pas la mise en page comme la voit un utilisateur voyant. Il construit son propre modèle de la page à partir de la structure sémantique du HTML : titres, repères de structure (comme <nav>, <main>, <footer>), listes, étiquettes de formulaire, texte des liens, et l’ordre dans lequel les éléments apparaissent dans le DOM. Un utilisateur peut sauter d’un titre à l’autre, lister tous les liens d’une page, ou passer directement au champ de formulaire suivant, sans jamais avoir besoin de balayer visuellement l’écran. Si un site est construit avec une soupe de <div> dénuée de sens, des titres utilisés pour un style visuel plutôt que pour la structure réelle du document, ou un contenu ordonné visuellement via CSS d’une façon qui ne correspond pas à l’ordre réel du DOM, tout ce modèle de navigation s’effondre, même si la page paraît parfaitement normale à un visiteur voyant.

Les habitudes qui font ou défont la compatibilité

Une poignée d’habitudes au niveau du code expliquent la plupart des problèmes réels de lecteur d’écran. Un texte alternatif pertinent sur les images porteuses d’information (et un texte alternatif vide sur celles purement décoratives) est le problème le plus courant, présent sur la grande majorité des pages : l’étude WebAIM Million 2026 a constaté que 83,9 % des pages d’accueil présentaient un texte à faible contraste comme problème le plus fréquent, suivi de près par un texte alternatif manquant ou de mauvaise qualité et des champs de formulaire non étiquetés. Au-delà du texte alternatif, les autres habitudes les plus importantes sont : une structure de titres logique qui ne saute pas de niveau, des champs de formulaire dotés d’étiquettes associées par programmation plutôt que d’un simple texte de substitution, un ordre de focus visible et logique lors de la navigation par tabulation, et un texte de lien descriptif (« consultez notre guide sur la conformité à l’EAA » plutôt que « cliquez ici »).

Où l’ARIA a sa place, et où elle ne l’a pas

Les attributs ARIA (Accessible Rich Internet Applications) existent pour décrire des composants interactifs personnalisés, comme un panneau d’onglets ou une liste déroulante combinée, pour lesquels le HTML natif n’a pas d’élément intégré. La règle la plus importante est de privilégier d’abord le HTML natif : un véritable élément <button> gère déjà correctement l’activation au clavier, le focus et l’annonce du rôle, tandis qu’un <div> stylé avec un gestionnaire de clic doit voir tout cela reconstruit manuellement avec de l’ARIA et du JavaScript, ce qui se fait facilement de travers de façon subtile. Un ARIA mal utilisé, comme un rôle qui ne correspond pas au comportement réel de l’élément, est une source bien documentée de confusion pour les lecteurs d’écran ; il peut annoncer un contrôle de façon incorrecte ou le rendre totalement inaccessible au clavier, ce qui est souvent pire pour l’utilisateur que si aucun ARIA n’avait été ajouté du tout.

Tester votre propre site

Les outils automatisés constituent un premier passage raisonnable. Un outil construit sur le moteur largement utilisé axe-core, comme axe DevTools de Deque, détecte rapidement un ensemble significatif de problèmes structurels et d’étiquetage et s’intègre au flux de travail existant d’un développeur. Mais les scans automatisés ne détectent en général qu’une partie de ce qui compte réellement pour un vrai utilisateur de technologie d’assistance ; des aspects comme le fait qu’un ordre de lecture ait du sens à voix haute, ou qu’un message d’erreur soit réellement annoncé lorsque l’envoi d’un formulaire échoue, exigent qu’une personne utilise réellement la page avec un lecteur d’écran actif. Pour les sites WordPress en particulier, WebYes se concentre sur l’identification et la correction directe de ce type de problèmes au niveau du code plutôt que sur leur masquage par une surcouche, une approche raisonnable si votre équipe est à l’aise pour modifier les modèles et thèmes sous-jacents.

Ce que les widgets d’accessibilité peuvent et ne peuvent pas faire ici

Les widgets et outils de surcouche, y compris ceux dotés de fonctionnalités assistées par IA comme la génération automatique de texte alternatif et d’étiquettes ARIA de Wawsome, peuvent réellement aider à combler certains écarts, en particulier sur des sites où corriger le code sous-jacent n’est pas réaliste à court terme. Ce qu’ils ne peuvent généralement pas faire, c’est restructurer l’ordre fondamental du DOM d’une page, réécrire des associations de formulaire défaillantes sur l’ensemble des modèles d’un site, ou garantir que chaque widget interactif personnalisé se comporte correctement avec un lecteur d’écran. Des enquêtes indépendantes menées auprès de professionnels de l’accessibilité ont systématiquement révélé un réel scepticisme sur la portée réelle des corrections automatisées par surcouche ; une enquête affiliée à WebAIM a montré que 67 % des professionnels jugeaient les surcouches « pas du tout » ou « pas très » efficaces, un taux qui grimpe à 72 % chez les répondants eux-mêmes en situation de handicap. La conclusion réaliste est qu’un widget peut constituer une couche d’une stratégie de compatibilité, mais que la véritable compatibilité avec les lecteurs d’écran dépend en fin de compte des décisions de code prises lors de la construction du site.

Contenu dynamique et applications mono-page

Les sites modernes qui mettent à jour du contenu sans recharger entièrement la page, une liste de produits filtrée, un total de panier en direct, un message de validation de formulaire affiché en ligne, ont besoin d’un mécanisme précis pour indiquer aux technologies d’assistance qu’un changement a eu lieu, car un lecteur d’écran n’a aucun moyen de remarquer par lui-même une mise à jour silencieuse du DOM. Les zones live ARIA répondent à ce besoin : marquer un conteneur avec aria-live="polite" (ou, pour des messages urgents comme une erreur, aria-live="assertive") indique au lecteur d’écran d’annoncer le nouveau contenu dès son apparition. C’est l’un des schémas les plus souvent oubliés sur les sites modernes riches en JavaScript, car un changement peut sembler complet et évident pour un utilisateur voyant qui regarde l’écran tout en restant totalement silencieux pour une personne qui écoute via un lecteur d’écran.

Lecteurs d’écran mobiles

Les mêmes principes s’appliquent sur mobile, mais les outils diffèrent : VoiceOver sur iOS et TalkBack sur Android fonctionnent par gestes plutôt que par clavier, en utilisant des balayages pour se déplacer entre les éléments et des tapotements pour les activer. Un site testé avec un lecteur d’écran de bureau n’est pas automatiquement validé sur mobile, car la taille des zones tactiles, les conflits de gestes avec des interactions de balayage personnalisées (comme un carrousel d’images) et les changements de mise en page propres au mobile peuvent tous introduire des problèmes qui n’apparaissent pas lors d’un test sur bureau. Si une part significative de votre trafic est mobile, ce qui est le cas pour la plupart des sites e-commerce et grand public aujourd’hui, un passage dédié au lecteur d’écran mobile mérite son propre temps de test plutôt que d’être traité comme un simple complément aux tests sur bureau.

Une routine de test de base pour démarrer

Activez NVDA (gratuit) ou VoiceOver (intégré à chaque Mac et iPhone), parcourez votre page d’accueil et une page de conversion clé (comme un formulaire de paiement ou de contact) en utilisant uniquement le clavier et les commandes de navigation propres au lecteur d’écran, et notez tout endroit où vous restez bloqué, où rien n’est annoncé, ou où ce qui est annoncé n’a pas de sens. Cet exercice de trente minutes, répété après tout changement significatif du site, fera apparaître plus de véritables problèmes que la plupart des scans automatisés à eux seuls.

Il vaut aussi la peine d’intégrer cela à votre processus de mise en production plutôt que de le traiter comme un exercice ponctuel. Un changement de design ou de modèle qui semble correct visuellement peut discrètement casser la structure des titres, l’ordre de focus ou l’annonce d’une zone live, et ces régressions coûtent bien moins cher à détecter avant un déploiement qu’après que de vrais utilisateurs les rencontrent. Même une version allégée de cette pratique, une personne consacrant vingt minutes à tester avec un lecteur d’écran les pages modifiées, appliquée systématiquement avant chaque mise en production, permet de détecter une part significative des régressions qui s’accumuleraient sinon sans être remarquées au fil du temps.