# JAWS contre NVDA : deux lecteurs d’écran, deux comportements

> Sur les mêmes composants (menu, formulaire, tableau), JAWS et NVDA n'annoncent pas toujours la même chose. Comparatif pratique des divergences à connaître avant de conclure un test.

- Auteur : WordPress Développement
- Publié le : 2021-10-31
- Mis à jour le : 2021-10-31
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/jaws-nvda-comportements-lecteurs-ecran/

## L’essentiel

- Un composant qui passe sur NVDA ne garantit rien sur JAWS
- Les tableaux de données révèlent les écarts les plus nets
- Tester sur un seul lecteur d'écran donne une fausse impression de couverture

Un composant testé avec succès sur NVDA ne garantit rien sur JAWS, et inversement : ces deux lecteurs d'écran, largement utilisés sous Windows, n'implémentent pas toujours de la même façon leur interprétation des rôles et attributs ARIA. Ce comparatif pratique s'appuie sur trois composants courants d'un thème WordPress — menu, formulaire, tableau — pour montrer où ces divergences se manifestent le plus.

## Comportement sur un menu déroulant

Sur un menu principal avec des sous-menus dépliables au clavier, NVDA annonce généralement l'état du bouton d'ouverture via `aria-expanded`, en indiquant « replié » ou « déplié » à chaque changement d'état. JAWS suit le même attribut mais formule l'annonce différemment selon sa configuration, et certains modes de navigation propres à JAWS (le mode de navigation virtuelle notamment) peuvent intercepter certaines touches avant qu'elles n'atteignent le gestionnaire JavaScript du menu, ce qui ne se produit pas de la même façon sous NVDA.

| Composant | Comportement sous NVDA | Comportement sous JAWS |
| --- | --- | --- |
| Menu déroulant | Annonce systématique de l'état déplié ou replié | Annonce présente mais parfois retardée selon le mode de navigation actif |
| Formulaire avec erreur | Lit le message associé via aria-describedby dès le focus du champ | Lit le message, mais nécessite parfois un déplacement explicite en mode formulaire |
| Tableau de données | Annonce l'en-tête de colonne à chaque cellule parcourue par défaut | Nécessite souvent l'activation explicite du mode tableau pour obtenir la même annonce |

> L'essentiel à retenir : Un composant qui passe sur NVDA ne garantit rien sur JAWS ; Les tableaux de données révèlent les écarts les plus nets ; Tester sur un seul lecteur d'écran donne une fausse impression de couverture

## Comportement sur un formulaire avec message d'erreur

Sur un champ de formulaire associé à un message d'erreur par `aria-describedby`, NVDA lit en général le message dès que le focus atteint le champ, immédiatement après le libellé. JAWS le fait également en mode formulaire, mais certaines versions demandent que le focus reste plus longtemps sur le champ, ou que la personne bascule explicitement du mode de navigation virtuelle vers le mode formulaire, ce qui peut retarder la perception du message pour une personne peu expérimentée avec cet outil précis.

## Comportement sur un tableau de données

C'est sur les tableaux que la divergence se voit le plus nettement. NVDA annonce par défaut, à chaque cellule du corps du tableau parcourue avec les flèches, l'en-tête de colonne correspondant, à condition que le tableau utilise correctement `<th scope="col">`. JAWS propose un comportement équivalent, mais certaines versions imposent d'activer un mode de navigation par tableau spécifique (souvent la combinaison de touches propre à JAWS pour passer en mode tableau), sans quoi les cellules sont lues sans rappel de leur en-tête.

### Ce que cela implique pour les tests

Cette divergence ne signifie pas qu'un des deux lecteurs d'écran serait « meilleur » que l'autre : elle signifie surtout qu'un composant qui semble fonctionner parfaitement testé sur un seul outil peut révéler un comportement différent, parfois dégradé, sur l'autre. Un balisage rigoureux (rôles ARIA corrects, attributs `scope` sur les tableaux, `aria-expanded` à jour) reste la meilleure garantie de cohérence entre les deux, mais ne dispense pas d'un test réel sur chacun avant une mise en production critique.

- Tester au minimum NVDA (gratuit, installation rapide) et JAWS (largement utilisé en environnement professionnel) sur les composants interactifs les plus critiques du parcours.
- Documenter dans le rapport de recette sur quel lecteur d'écran chaque composant a été testé, pour éviter une fausse impression de couverture complète.
- Prioriser les tests croisés sur les tableaux de données et les formulaires, les deux zones où les écarts se sont révélés les plus marqués dans cette comparaison.

> Sur les recettes que je mène, je documente systématiquement le lecteur d'écran utilisé pour chaque test : un composant validé « sous NVDA seulement » n'a pas la même valeur qu'un composant validé sur les deux, et ce distinguo évite de mauvaises surprises après la mise en ligne.

## Verdict

Aucun des deux lecteurs d'écran ne peut servir de référence unique pour valider un composant destiné à un public large. NVDA offre un accès gratuit qui en fait un bon outil de test quotidien pendant le développement, tandis que JAWS, très répandu en contexte professionnel, mérite un passage de vérification avant toute mise en production d'un composant complexe comme un tableau de données ou un menu à plusieurs niveaux.