Lecteurs d’écran : préférences et principaux problèmes des utilisateurs

Depuis 2009, l’association américaine WebAIM a mené six enquêtes à l’échelle mondiale, pour mieux connaître les usages et les préférences des utilisateurs de lecteurs d’écran.

WebAIM a publié les résultats de sa dernière enquête en octobre 2017. Ils sont riches d’enseignements et surtout ils nous permettent de faire à nouveau un point sur la nécessité d’améliorer nos pages web, pour fournir des sites plus accessibles.

Un lecteur d’écran est un logiciel qui permet de vocaliser le contenu d’un site grâce à une synthèse vocale mais aussi de transmettre ce contenu à un afficheur braille.

Types de handicap

Les internautes qui ont répondu à l’enquête compensent avec un lecteur d’écran, les handicaps suivants :

  • Cécité : 75,8%
  • Basse vision : 20,4%
  • Cognitif, problème d’apprentissage : 2,2%
  • Surdité, malentendants : 5,0%
  • Moteur (membres supérieurs) : 1.8%

Les utilisateurs en situation de handicap visuel sont les plus nombreux à avoir répondu à l’enquête. Certains ont déclaré un handicap multiple.

Les personnes dyslexiques, empêchées de lire, peuvent compenser leur handicap grâce à la vocalisation. Les aveugles avec des problèmes d’audition et connaissant le braille peuvent être aidés par un lecteur d’écran qui va transcrire le contenu de la page en braille.

Lecteurs d’écran utilisés

Il existe plusieurs lecteurs d’écran, payants, gratuits,  à installer sur son ordinateur ou encore déjà intégrés à un système d’exploitation.

Les lecteurs les plus utilisés sont les suivants :

  • Jaws : 66.0%
  • NVDA : 64.9%
  • VoiceOver : 39.6%
  • Narrateur : 21.4% (depuis Windows 10)

Les utilisateurs de NVDA sont de plus en plus nombreux et son usage rattrape celui de Jaws, longtemps en position de leader. NVDA est gratuit et s’installe sur Windows. Une communauté très dynamique le met à jour régulièrement, tout en prenant en compte les évolutions des langages du Web.

Jaws est payant et s’installe sur Windows. Tous les utilisateurs de Jaws ne le mettent pas à jour, ce qui multiplie les versions de Jaws utilisées. Les anciennes versions de Jaws ne prennent pas en compte toutes les évolutions du langage HTML et restituent alors des informations erronées. Par exemple, depuis HTML5, une balise <a> peut contenir un élément de type bloc comme par exemple un titre de niveau 2. Certaines anciennes versions de Jaws (Jaws 14 par exemple) ne vont pas restituer un titre de niveau 2 mais un titre de niveau 3 et soulever ainsi une rupture dans la hiérarchie alors que le codage est correct. Il suffit de passer à la version 15 pour que le problème soit résolu. Nous en sommes actuellement à la version 18.

Le narrateur de Windows est à surveiller de près car il est de plus en plus riche en fonctionnalités, Microsoft souhaitant proposer nativement un lecteur d’écran digne de ce nom.

VoiceOver est depuis toujours installé d’office sur les systèmes d’exploitation d’Apple, facilitant ainsi son usage.

Les navigateurs utilisés

Les navigateurs les plus utilisés par notre cible sont les suivants :

  • Firefox : 41%
  • IE 11 : 23,3%
  • Chrome : 15,5%
  • Safari : 10,5%

Ces résultats ne reflètent pas les statistiques qu’un site comme statcounter peut nous fournir, où Chrome est largement en tête, suivi ensuite par Safari. Les autres navigateurs sont en dessous des 12%.

Les combinaisons lecteur/navigateur

Un lecteur d’écran s’utilise avec un navigateur donné. Par exemple, Jaws va majoritairement s’utiliser avec Internet Explorer, NVDA avec Firefox. Certaines combinaisons sont plus efficaces que d’autres.

Les combinaisons les plus utilisées et leur pourcentage d’usage sont les suivants :

  • Jaws avec IE : 24,7%
  • NVDA avec Firefox : 23,6%
  • Jaws avec Firefox : 15,1%
  • VoiceOver avec Safari : 10%
  • Jaws avec Chrome : 6,5%
  • NVDA avec Chrome : 5,9%
  • NVDA avec IE : 2,3%
  • VoiceOver avec Chrome : 1,4%

Mobile

Depuis 2009, le nombre d’utilisateurs de lecteurs d’écran sur mobile ne cesse de croître.

Les plateformes les plus utilisées sont :

  • Apple Iphone, Ipad, Ipod touch (avec VoiceOver) : 75,6%
  • Android (avec TalkBack): 22%

Il est signalé que les utilisateurs de lecteurs d’écran sur mobile utilisent également un clavier externe relié à leur mobile, pour environ 40% d’entre eux.

Recherche d’information

La navigation par titre est le moyen privilégié pour rechercher de l’information sur une page. Et c’est d’ailleurs ce que les utilisateurs nous disent le plus souvent.

« Il nous faut des titres mais pas partout. Il n’est pas nécessaire de mettre des titres dans des menus. Le lecteur d’écran nous permet de nous déplacer directement vers les moyens de navigation comme les menus, le moteur de recherche, grâce aux régions lorsqu’elles existent ».

Par ailleurs, les utilisateurs préfèrent avoir un seul titre de niveau 1 par page avec le titre du contenu éditorial de la page. Ce point est souvent discuté. Peut-on mettre plusieurs titres de niveau 1 ? Doit-on mettre des titres dans les parties communes à toutes les pages (pied de page, sidebar…) ? Comment peut-on à la fois répondre aux exigences de l’accessibilité et aux besoins de référencement naturel ?

Pour le titre de niveau 1, cette enquête peut nous aider à prendre une décision. La bonne pratique qui consiste à ne prévoir qu’un seul titre de niveau 1 avec le titre du contenu éditorial de la page est donc bien approuvée par les utilisateurs.

L’accessibilité et le référencement sont deux disciples qui travaillent ensemble et qui doivent trouver des solutions pour répondre aux besoins des utilisateurs humains et logiciels.

Pour les parties communes à toutes les pages, il est possible d’utiliser la balise <p> et de lui rajouter l’attribut role heading et l’attribut aria-level pour indiquer le niveau de titrage :

<p role="heading" aria-level="2">Contact< /p>

Les attributs « role » et « aria-level » font partie de la norme ARIA, qui consiste à améliorer l’accessibilité des contenus et applications web.

Ce code est considéré par un lecteur d’écran comme un titre de niveau 2, l’équivalent de la balise <h2>, ce qui ne sera pas le cas pour un moteur de recherche.

Les liens d’évitement

Les liens d’évitement sont peu utilisés par les usagers de lecteur d’écran. Ce sont plutôt les utilisateurs qui naviguent au clavier, qui vont utiliser ces liens pour accéder directement au contenu, au menu, à la recherche ou toute autre partie importante de la page.

Pour accéder au contenu principal de la page, les utilisateurs de lecteurs d’écran peuvent utiliser la navigation par région, si la région « main » a été prévue dans le code de la page.

Les régions

Les régions permettent aux utilisateurs de lecteurs d’écran de se déplacer directement vers les zones d’une page web, lorsque celles-ci sont intégrées dans le code HTML. Ce sont :

  • L’entête de la page
  • Le moteur de recherche
  • Le menu de navigation principal
  • Le contenu principal de la page
  • le pied de page

Les codes à prévoir sont les suivants :

<header role="banner">…</header>

<form role="search ">…< /form>

<nav role="navigation">…</nav>

<main role="main">…</main>

<footer role="contentinfo ">…< /footer>

D’après l’étude, la majorité des utilisateurs en profitent lorsque ces régions existent.

Les principaux problèmes rencontrés

L’accessibilité des sites s’améliore mais il reste encore des progrès à faire.

Les internautes qui ont répondu à l’enquête ont soulevé une dizaine de points qui leur semblent les plus bloquants et les plus frustrants lorsqu’ils naviguent sur le Web. Ils sont présentés ici par ordre d’importance décroissante.

  1. CAPTCHA – images présentant du texte utilisé pour vérifier que vous êtes un utilisateur humain
  2. Écrans ou parties d’écrans qui changent de façon inattendue
  3. Des liens ou des boutons qui n’ont pas de sens
  4. La présence de contenu Flash inaccessible
  5. Manque d’accessibilité au clavier
  6. Formulaires complexes ou difficiles
  7. Images avec des descriptions manquantes ou inappropriées (attribut alt)
  8. Titres manquants ou inappropriés
  9. Trop de liens ou d’éléments de navigation
  10. Tableaux de données complexes
  11. Fonctionnalité de recherche inaccessible ou manquante
  12. Manque de liens « Passer au contenu principal » ou « Ignorer la navigation »

Les Captchas

La présence d’un captcha anti-spam uniquement visuel est bien connue comme étant un vrai blocage à l’usage des formulaires. L’idéal est de ne rien demander à l’internaute, et de gérer techniquement le contrôle anti-spam de manière totalement transparente. Si la présence d’un captcha est obligatoire alors il faut prévoir une alternative comme de l’audio pour un captcha visuel.

Les liens et boutons

Ce qui ressort également et qui sont très fréquemment rencontrés, ce sont les liens ou les boutons avec des intitulés non explicites et souvent inexistants.

  • Images cliquables avec l’attribut alt vide
  • Lien avec une image en background sans texte associé
  • Lien sur des icônes sans texte

Pour remédier à cela, voici quelques codes à retenir :

Pour un lien sur un logo :

<a href="/">

<img src="/media/logo.png" alt="WebAIM - Web Accessibility In Mind – Home page return" width="302" height="80">

</a>

Dans ce cas, l’attribut alt de l’image doit expliquer la cible du lien.

Pour un lien avec une image en background :

<a href="paiement-visa">

<span class="screen-reader-text">Visa</span>

</a>

Il s’agit ici de rajouter un texte caché, en utilisant la classe CSS « screen-reader-text », et qui devient alors l’intitulé du lien.

Pour un lien sur un icône :

<a href="paiement-visa">

<span class="fa fa-cc-visa" aria-hidden="true"></span>

<span class="screen-reader-text">Visa</span>

</a>

Même chose ici, le texte caché est l’intitulé du lien.

La classe CSS « screen-reader-text » permet de cacher du texte, tout en étant vocalisé par les lecteurs d’écran. Elle est présente dans le code généré par WordPress et dans les thèmes livrés par défaut comme « twentyseventeen ». Pour intégrer cette classe dans la feuille de style de votre thème WordPress, vous trouverez le code de la classe CSS « screen-reader-text » sur le site make WordPress Core.

La technique qui consiste à rajouter à la balise <a> un attribut aria-label avec comme valeur l’intitulé du lien n’est pas valide car le lien doit être utilisable lorsque CSS est désactivé et dans ce cas, le lien n’apparaît pas. L’attribut aria-label sert à préciser l’intitulé d’un lien mais pas à le remplacer complètement.

Changement dans les pages

Le point n°2 lié au changement dans le contenu de la page non signalé à l’utilisateur, est passé à la 2e place alors qu’il était en 7e position en 2009.

En effet, le contenu d’une page web peut être modifié sans que cette page soit rechargée, améliorant l’usage. Mais si nous pouvons voir s’afficher les nouveaux contenus, ce n’est pas le cas de tous les utilisateurs de lecteur d’écran. C’est pourquoi l’utilisateur qui écoute les pages doit être averti de l’apparition de ces nouveaux contenus. Des solutions existent pour permettre à l’utilisateur d’en prendre connaissance, comme positionner le focus sur le premier élément inséré. Dans certains cas de figure, Il est également possible d’utiliser l’attribut role= »alert » sur un contenu nouvellement affiché, qui est alors immédiatement vocalisé.

Usage du clavier

Certains éléments cliquables ne sont pas accessibles au clavier avec les touches TAB, shift TAB car codé en HTML avec des éléments ne recevant pas naturellement le focus clavier, comme les balises <div> et <span>. Pour corriger ce point, si les éléments utilisés ne reçoivent pas nativement le focus, il possible d’ajouter des attributs ARIA qui vont permettre de changer la nature de l’élément en s’appuyant également sur des scripts JS. Grâce à cette adaptation du code, l’usage du clavier sur ces éléments cliquables devient alors possible.

Pour aller plus loin

Voici quelques ressources en lignes pour compléter cet article :

 

 

Photo by Gabriel Barletta, Nicole Mason on Unsplash