Tests et outils

Panorama des lecteurs d'écran : NVDA, JAWS et VoiceOver

Un lecteur d'écran convertit le contenu affiché en parole de synthèse ou en sortie braille, permettant aux personnes aveugles ou malvoyantes de parcourir et de comprendre une page sans la voir. Les trois lecteurs d'écran les plus utilisés se comportent assez différemment - raccourcis clavier, interprétation d'ARIA, réglages par défaut - pour qu'un test manuel d'accessibilité couvre idéalement plus d'un seul d'entre eux.

NVDA (NonVisual Desktop Access)

Gratuit et open source, réservé à Windows, c'est le lecteur d'écran le plus utilisé tant par les personnes concernées que pour les tests d'accessibilité : sa gratuité et son développement actif en font un choix par défaut naturel pour les équipes qui testent elles-mêmes. Il s'utilise le plus souvent avec Firefox ou Chrome sous Windows.

JAWS (Job Access With Speech)

Un lecteur d'écran commercial et payant pour Windows, historiquement leader du marché dans les grandes organisations et le secteur public, doté d'une longue expérience et de fonctionnalités étendues. Parce qu'il est payant et nécessite une licence, il est moins utilisé que NVDA pour des tests ponctuels, mais il reste important à couvrir pour des produits destinés à des publics où JAWS est très présent.

VoiceOver

Le lecteur d'écran intégré d'Apple, fourni gratuitement avec macOS et iOS - l'outil par défaut, et pour beaucoup le seul, dans l'écosystème Apple. Tester avec VoiceOver importe particulièrement pour tout produit ayant un usage iOS et Safari significatif, son modèle d'interaction (notamment les gestes tactiles sur iOS) différant sensiblement du modèle clavier de NVDA et JAWS sur ordinateur.

Pourquoi un seul lecteur d'écran ne suffit pas

Chaque lecteur d'écran a ses particularités dans l'interprétation des attributs ARIA, l'annonce des changements de contenu dynamique (comme les régions live) et la gestion des cas limites des composants sur mesure : un composant irréprochable sous NVDA peut se comporter autrement, voire échouer, sous VoiceOver, et réciproquement. C'est une grande part de la raison pour laquelle la conformité WCAG ne peut pas être entièrement vérifiée par la seule analyse automatisée : un analyseur contrôle la correction du balisage au regard de la spécification, alors que le comportement réel d'un lecteur d'écran s'en écarte parfois d'une manière que seuls des tests manuels révèlent.

Une approche minimale réaliste

Pour la plupart des équipes sans spécialiste dédié, une base raisonnable consiste à tester les parcours principaux sous NVDA avec Chrome ou Firefox (la combinaison gratuite et Windows la plus répandue), et sous VoiceOver avec Safari si le produit connaît un usage Mac ou iOS significatif. Ce n'est pas une couverture exhaustive, mais cela révèle la majorité des problèmes propres aux lecteurs d'écran que l'analyse automatisée et le test au clavier seul laisseraient passer.

Questions fréquentes

Qu'est-ce qu'un lecteur d'écran ?

Un logiciel qui convertit le contenu affiché en parole de synthèse ou en braille, permettant aux personnes aveugles ou malvoyantes de parcourir et de comprendre une page sans la voir.

Avec quels lecteurs d'écran principaux faut-il tester ?

NVDA (gratuit, open source, Windows - le plus courant pour les tests), JAWS (leader commercial sous Windows dans les grandes organisations et le secteur public) et VoiceOver (intégré à macOS et iOS).

Pourquoi tester avec plus d'un lecteur d'écran ?

Chacun interprète ARIA, annonce les contenus dynamiques et gère les composants sur mesure différemment. Un composant qui fonctionne sous NVDA peut échouer sous VoiceOver : tester avec un seul outil laisse passer de vrais problèmes.