Aperçu lecteur d'écran, gratuit

Collez du HTML pour voir comment un lecteur d'écran le linéariserait et l'annoncerait. Vérifiez vos textes alt, vos en-têtes et vos attributs ARIA.

Sortie du lecteur d'écran

Collez du HTML et cliquez sur Analyser.
📚 Bases scientifiques et sources

Pour qui cet outil est conçu

Les lecteurs d'écran sont une technologie d'assistance essentielle pour les personnes aveugles ou atteintes d'une déficience visuelle importante. Selon le Rapport mondial sur la vision de l'OMS (2019), au moins 2,2 milliards de personnes dans le monde souffrent d'une déficience visuelle, dont environ 43 millions sont aveugles. L'enquête WebAIM Screen Reader Survey (2024) constate systématiquement que la grande majorité des utilisateurs de lecteurs d'écran sont des personnes en situation de handicap, la cécité en étant la raison la plus fréquente. Les développeurs, designers et créateurs de contenu utilisent cet outil pour prévisualiser comment leur HTML sera interprété par les technologies d'assistance, ce qui aide à repérer les textes alternatifs manquants, les structures de titres incorrectes, les boutons et champs sans nom accessible, et les utilisations erronées de l'ARIA, avant que les utilisateurs finaux ne les rencontrent.

Comment fonctionne cet outil

Cet outil analyse votre HTML via le DOMParser natif du navigateur (aucune donnée ne quitte votre appareil), puis parcourt l'arbre d'accessibilité pour construire un ordre de lecture linéarisé. Il vérifie la présence de textes alternatifs sur les images, la cohérence des niveaux de titres, les liens et boutons sans nom accessible, les rôles et libellés ARIA, ainsi que les champs de formulaire sans étiquette associée.

Références scientifiques

  • WebAIM (2024). « Screen Reader User Survey #10 Results. » webaim.org · La plus grande enquête en continu sur les modes d'utilisation des lecteurs d'écran, les combinaisons de navigateurs et les obstacles à l'accessibilité. Constate systématiquement que les titres et les repères (landmarks) sont les principales stratégies de navigation des utilisateurs.
  • Organisation mondiale de la Santé (2019). Rapport mondial sur la vision. · Rapporte qu'au moins 2,2 milliards de personnes dans le monde souffrent d'une déficience visuelle de près ou de loin, dont environ 43 millions sont aveugles.
  • Power, C., Freire, A., Petrie, H. & Swallow, D. (2012). « Guidelines are only half of the story: Accessibility problems encountered by blind users on the web. » Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '12). · A constaté qu'une part importante des problèmes d'accessibilité rencontrés par les utilisateurs aveugles n'était pas couverte par les WCAG seuls, soulignant la nécessité d'une revue manuelle et de tests au lecteur d'écran.
  • Lazar, J., Allen, A., Kleinman, J. & Malarkey, C. (2007). « What frustrates screen reader users on the web: A study of 100 blind users. » International Journal of Human-Computer Interaction, 22(3), 247–269. · A identifié les textes alternatifs manquants, les champs de formulaire non libellés et les libellés de liens trompeurs parmi les principales frustrations rapportées par les utilisateurs aveugles.
  • W3C WAI (2023). « WAI-ARIA Authoring Practices 1.2. » · Définit comment les rôles, états et propriétés doivent être utilisés pour rendre accessible un contenu dynamique aux technologies d'assistance.

Avertissement

Cet outil fournit une approximation simplifiée de la sortie d'un lecteur d'écran basée sur l'arbre d'accessibilité HTML. Les lecteurs d'écran réels (NVDA, JAWS, VoiceOver, TalkBack) diffèrent dans la façon d'annoncer le contenu, de gérer les attributs ARIA et d'interagir avec les widgets dynamiques. Cet aperçu ne remplace pas les tests avec de vrais lecteurs d'écran et de vrais utilisateurs. Il est destiné à détecter les problèmes courants tôt dans le processus de rédaction.

Une brève histoire des standards d'accessibilité web

L'accessibilité sur le web est régie par une petite pile de standards du W3C Web Accessibility Initiative (WAI), plus les lois nationales qui s'y réfèrent. WCAG 1.0 a été publié en mai 1999, la première directive formelle pour rendre le contenu web accessible. Elle était largement centrée sur HTML et est rapidement devenue obsolète. WCAG 2.0 (décembre 2008) a été une réécriture majeure organisée autour de quatre principes (Perceptible, Utilisable, Compréhensible, Robuste) et trois niveaux de conformité (A, AA, AAA). Elle est devenue une norme ISO (ISO/IEC 40500) en 2012 et est la cible de conformité que la plupart des lois référencent encore. WCAG 2.1 (juin 2018) a ajouté 17 nouveaux critères de réussite couvrant le mobile, la basse vision et les handicaps cognitifs. WCAG 2.2 (octobre 2023) en a ajouté 9 de plus, notamment 2.4.11 Focus Non Obscurci et 3.3.8 Authentification Accessible. WAI-ARIA 1.0 a été finalisée en mars 2014; 1.2 en juin 2023 est la Recommandation actuelle. Côté juridique, la Refonte Section 508 des États-Unis (janvier 2018) a incorporé WCAG 2.0 AA dans les achats fédéraux américains. La Loi européenne sur l'accessibilité (Directive 2019/882) est entrée en vigueur le 28 juin 2025, exigeant que la plupart des produits numériques destinés aux consommateurs dans l'UE répondent aux normes d'accessibilité. La plupart des pays référencent WCAG, donc construire pour WCAG 2.2 AA est la cible pratique pour tout produit global aujourd'hui.

Le paysage des lecteurs d'écran aujourd'hui

Le WebAIM Screen Reader User Survey #10 (2024) est la source canonique sur les lecteurs d'écran que les gens utilisent réellement. Cinq produits dominent le bureau, le mobile et ChromeOS.

  • JAWS (Freedom Scientific, première version 1989) est le leader commercial de longue date sur Windows. Coûte environ 1000$+. WebAIM 2024 le trouve comme le lecteur d'écran principal pour environ 40% des répondants à l'enquête, légèrement en dessous de NVDA.
  • NVDA (NV Access, première version 2006, écrit en Python) est l'alternative open-source Windows. Gratuit. WebAIM 2024 le rapporte comme le lecteur d'écran principal le plus utilisé, environ 47% des répondants. La croissance de NVDA d'un outil de niche à leader du marché en 15 ans est l'une des grandes histoires de succès open-source en technologie d'assistance.
  • VoiceOver (Apple, 2005 sur macOS, 2009 sur iOS) est intégré à chaque Mac, iPhone, iPad, Apple Watch, Apple TV. C'est le lecteur d'écran mobile le plus utilisé. Étroitement intégré à Safari et au rotor iOS pour la navigation.
  • TalkBack (Google, 2009 sur Android) est l'équivalent Android. Open-source depuis Android 4. Utilise des gestes et le menu de navigation.
  • ChromeVox (Google, 2012) et Narrator (Microsoft, 2000, modernisé dans Windows 10) complètent le tableau. Chacun a une base d'utilisateurs petite mais fidèle.

Une seule page peut être annoncée différemment par chaque produit. Les pages robustes testent proprement dans au moins deux: généralement NVDA + Firefox ou Chrome, et VoiceOver + Safari.

Quand recourir à cet outil

  • Audits avant lancement. Collez une page clé (page d'accueil, formulaire d'inscription, caisse) et lisez la sortie linéarisée à voix haute. Si elle n'a pas de sens pour vous, elle n'aura pas de sens pour un utilisateur de lecteur d'écran.
  • Revues de code. Avant de fusionner une PR avec des modifications de balisage importantes, collez le HTML rendu et confirmez que les en-têtes, les repères et le texte alternatif sont restés intacts.
  • Vérification du transfert de conception. Les designers peuvent coller leur HTML final pour confirmer que la hiérarchie visuelle correspond à la hiérarchie sémantique. Une page qui ressemble à un en-tête devrait aussi en être un dans le DOM.
  • Enseigner l'accessibilité. Montrez à une classe ou à une équipe ce qu'un lecteur d'écran reçoit réellement. L'écart entre la disposition visuelle et la sortie linéarisée est souvent la première fois que les développeurs non handicapés comprennent pourquoi le HTML sémantique compte.
  • Vérifications de conformité avec WCAG. Vérifications ponctuelles rapides pour les quatre critères les plus violés: 1.1.1 Contenu non textuel (texte alternatif), 1.3.1 Information et relations (structure sémantique), 2.4.4 Objet du lien, 4.1.2 Nom, rôle, valeur.
  • Vérifications de site CMS / no-code. Les éditeurs visuels produisent souvent des divs au lieu d'en-têtes ou des liens sans texte. Collez le HTML publié, voyez ce qui s'est faufilé.
  • Accessibilité des modèles d'email. Les emails HTML sont notoirement difficiles à rendre accessibles. Utilisez l'aperçu pour vérifier le texte alternatif sur chaque image, l'ordre approprié des en-têtes et un flux de lecture lisible.

Erreurs courantes que les lecteurs d'écran exposent

  • Texte alternatif manquant ou inutile. alt="image", alt="photo", alt="logo" sont à peine mieux que rien. Lazar et al. (2007) ont identifié le texte alternatif manquant comme la principale frustration des utilisateurs web aveugles. Écrivez un texte alternatif qui transmet le but de l'image dans le contexte environnant, ou utilisez alt="" pour les images purement décoratives afin que le lecteur d'écran les saute.
  • Niveaux d'en-tête qui sautent ou redémarrent. Passer de h1 à h3 en sautant h2 confond la navigation. Utiliser plusieurs éléments h1 sur la même page (un modèle assez courant dans la conception axée sur les composants) brise le plan du document que les utilisateurs de lecteurs d'écran utilisent pour naviguer. WebAIM 2024 constate que les en-têtes sont la stratégie de navigation la plus courante pour les utilisateurs de lecteurs d'écran.
  • Divite. Envelopper du texte cliquable dans <div> avec un gestionnaire de clic au lieu d'utiliser <button> ou <a> signifie aucun support clavier, aucun anneau de focus, aucune annonce de rôle. Commencez toujours par du HTML sémantique et ajoutez ARIA seulement quand aucun élément natif ne convient.
  • ARIA utilisé là où HTML ferait l'affaire. Première règle d'ARIA (selon les Pratiques de Création WAI-ARIA du W3C): «si vous pouvez utiliser un élément HTML natif... faites-le». <button role="button"> est redondant; <div role="button"> est un signe que vous devriez utiliser un vrai bouton à la place.
  • ARIA utilisé incorrectement. aria-hidden="true" sur un élément focalisable le rend invisible aux lecteurs d'écran mais toujours focalisable au clavier, une recette pour un ordre de tabulation désorientant. role="button" sans tabindex="0" et des gestionnaires de clavier ne fait rien d'utile.
  • Champs de formulaire sans étiquettes. Un <input> sans <label>, aria-label ou aria-labelledby associé est annoncé comme «édit, vide» sans contexte. Le texte d'espace réservé n'est pas un substitut, il disparaît au focus et échoue souvent au contraste.
  • Liens «cliquez ici» et «en savoir plus». Les utilisateurs de lecteurs d'écran naviguent souvent en faisant apparaître la liste de tous les liens sur la page. «Cliquez ici» seul ne leur dit rien. Faites en sorte que le texte du lien décrive la destination: «Lire l'enquête WebAIM 2024» bat «Lire la suite ici».
  • Suppression des styles de focus. outline: none sans indicateur de focus de remplacement est l'un des critères WCAG les plus violés (2.4.7 Visibilité du focus). Les utilisateurs du clavier, y compris de nombreux utilisateurs de lecteurs d'écran, ont besoin de voir où se trouve le focus.

ARIA en un coup d'œil: ce que fait chaque type de rôle

  • Rôles de repère (banner, navigation, main, complementary, contentinfo, search) divisent la page en régions entre lesquelles un utilisateur de lecteur d'écran peut sauter. La plupart ont des équivalents HTML natifs (<header>, <nav>, <main>, <aside>, <footer>). Utilisez d'abord l'élément natif.
  • Rôles de widget (button, checkbox, combobox, menu, tabpanel, etc.) décrivent les contrôles interactifs. Les rôles de widget impliquent des modèles d'interaction clavier que le W3C ARIA Authoring Practices Guide (APG) documente en détail. Si vous ne pouvez pas faire correspondre la spécification APG exactement, préférez HTML natif.
  • Rôles de structure de document (article, list, listitem, row, cell, etc.) décrivent le contenu non interactif. La plupart ont aussi des équivalents HTML natifs. Utilisez-les seulement quand l'élément natif est indisponible (par exemple, construire une grille de données personnalisée où <table> ne convient pas).
  • Régions live (aria-live="polite", aria-live="assertive", role="status", role="alert") indiquent aux lecteurs d'écran d'annoncer les mises à jour dynamiques sans déplacer le focus. Utilisé pour les messages de chat, les erreurs de formulaire, les états de chargement. La surutilisation provoque une fatigue de notification; réservez assertive pour les véritables urgences comme les états d'erreur.

Plus de questions fréquentes

Cet aperçu correspond-il à ce que NVDA / JAWS / VoiceOver diront réellement?

Il approxime. Cet outil lit l'arborescence d'accessibilité du navigateur (la même structure que les lecteurs d'écran utilisent) et produit une version linéarisée de ce qui serait annoncé. Les vrais lecteurs d'écran ajoutent des comportements spécifiques au produit: annonces des changements de focus, navigation de table, en-têtes de table, comptes d'éléments de liste, gestion de la politesse ARIA-live, paramètres de verbosité personnalisés. Traitez l'aperçu comme une première vérification de bon sens; pour les lancements en production, testez avec au moins un lecteur d'écran réel sur les systèmes d'exploitation que votre audience utilise.

Quelle est la différence entre WCAG et ARIA?

WCAG (Web Content Accessibility Guidelines) est une liste d'exigences: «chaque contenu non textuel doit avoir une alternative textuelle». Il vous dit quoi atteindre mais pas toujours comment. ARIA (Accessible Rich Internet Applications) est l'un des outils pour répondre à WCAG: un ensemble d'attributs HTML (rôles, états, propriétés) qui exposent la sémantique à la technologie d'assistance lorsque le HTML natif est insuffisant. Vous pouvez répondre à WCAG sans aucun ARIA si votre HTML est suffisamment sémantique. ARIA est pour les cas où il ne l'est pas.

Comment écrire un bon texte alternatif?

Trois règles de l'Arbre de décision alt du W3C: (1) Si l'image est purement décorative, utilisez alt="" pour que le lecteur d'écran la saute entièrement. (2) Si l'image transmet des informations qui ne sont pas déjà dans le texte environnant, décrivez ces informations de manière concise (généralement sous 125 caractères). (3) Si l'image est fonctionnelle (par exemple un logo qui renvoie à l'accueil ou un bouton d'icône), décrivez l'action plutôt que l'apparence. «Rechercher» bat «icône de loupe». Évitez «image de...», «photo de...», les lecteurs d'écran annoncent déjà que l'élément est une image.

Mon site utilise des divs partout. Par où commencer?

Commencez par ajouter les cinq éléments de repère: <header>, <nav>, <main>, <aside>, <footer>. Puis remplacez les divs cliquables par <button> (pour les actions) ou <a> (pour la navigation). Puis auditez les en-têtes: chaque page devrait avoir un <h1> et le reste dans l'ordre imbriqué. Ces trois étapes résolvent peut-être 70% des problèmes d'accessibilité sur un site typique chargé en divs. La gestion ARIA et JavaScript du focus vient après, une fois la fondation sémantique en place.

Le HTML que je colle ici est-il envoyé quelque part?

Non. L'analyse utilise le DOMParser intégré du navigateur et l'analyse s'exécute entièrement côté client. Ouvrez l'onglet Réseau dans DevTools et cliquez Analyser, vous verrez zéro requête sortante pendant la linéarisation. Sûr pour les modèles internes, les pages non publiées ou le HTML contenant des données client.

Outils associés

Vérificateur d'en-têtes WCAG, gratuit Ressources d'accessibilité Générateur de palette accessible, gratuit Vérificateur de contraste de couleurs, gratuit