Support réel : Ce que testent vraiment les technologies d'assistance

La spécification WAI-ARIA définit ce que les technologies d’assistance (AT) devraient annoncer. La réalité est différente, car le support varie selon la technologie d’assistance, le navigateur, leur version, et parfois les paramètres utilisateur. Un attribut ARIA correctement implémenté peut être ignoré par NVDA, annoncé par JAWS, et partiellement supporté par VoiceOver.

Cet article couvre les paires AT+navigateur qui comptent en audit RGAA, les attributs au support inégal, et comment lire l’arbre d’accessibilité pour vérifier ce que le lecteur d’écran voit réellement, sans avoir à tester avec chaque AT.

Les paires AT+navigateur qui comptent

Une technologie d’assistance fonctionne rarement bien avec tous les navigateurs. Chaque AT a des affinités avec un navigateur spécifique, et c’est cette combinaison qu’il faut tester, pas l’AT seul.

NVDA + Firefox : La paire de référence en Europe

NVDA (NonVisual Desktop Access) est le lecteur d’écran gratuit le plus utilisé en Europe. Sa combinaison avec Firefox est la plus répandue parmi les utilisateurs qui dépendent d’un lecteur d’écran au quotidien.

• Système : Windows
• Coût : gratuit et open source
• Téléchargement : NVDA ↗ lien externe qui s'ouvre dans un nouvel onglet
• Combinaison recommandée : NVDA + Firefox ESR (version stable longue durée)

Raccourcis essentiels pour auditer :

Mode navigation vs mode formulaire (distinction critique) : en mode navigation (par défaut), les touches de lettre sont des raccourcis de navigation (H pour titre, B pour bouton…). En mode formulaire (activé automatiquement quand le focus entre dans un champ), les lettres saisissent du texte.

NVDA bascule automatiquement mais l’auditeur doit comprendre quel mode est actif pour interpréter le comportement.

JAWS + Chrome : La référence enterprise

JAWS (Job Access With Speech) est le lecteur d’écran professionnel le plus utilisé en milieu enterprise et dans les administrations. C’est souvent lui qui est utilisé par les agents des collectivités ayant une déficience visuelle.

• Système : Windows
• Coût : payant (licence annuelle ~1 000 €), version d’évaluation 40 minutes
• Combinaison recommandée : JAWS + Chrome
• Différences notables avec NVDA : annonce davantage de métadonnées (nombre de résultats dans une listbox, relations aria-controls), comportement légèrement différent sur les live regions

En audit RGAA pour des sites de communes et d’institutions publiques, tester avec JAWS est recommandé si le budget et le temps le permettent, c’est probablement l’AT utilisé par les agents en situation de handicap visuel dans ces structures.

Ce que JAWS fait différemment de NVDA :

• Annonce aria-controls, alors qu’NVDA l’ignore
• Gère mieux certains widgets complexes (grilles, arbres)
• Annonce parfois plus d’informations sur les tableaux
• Se comporte différemment sur les formulaires (mode virtuel vs mode formulaire)

VoiceOver + Safari : Indispensable pour iOS

VoiceOver est le lecteur d’écran natif d’Apple, intégré à macOS, iOS et iPadOS. Il est obligatoire pour tester l’accessibilité mobile, c’est l’AT utilisé par la grande majorité des utilisateurs iPhone et iPad ayant une déficience visuelle.

• Système : macOS, iOS, iPadOS
• Coût : inclus dans les appareils Apple
• Activation : Réglages → Accessibilité → VoiceOver (iOS) ou Cmd+F5 (macOS)
• Combinaison recommandée : VoiceOver + Safari (les autres navigateurs iOS utilisent le moteur WebKit de Safari)

Particularités importantes :

Sur iOS, VoiceOver ne navigue pas au clavier mais par gestes tactiles. Les critères RGAA 7.3 (contrôle au clavier) concernent les utilisateurs desktop. Sur mobile, c’est le geste de balayage qui remplace le Tab.

VoiceOver sur macOS avec Safari a des différences de comportement notables par rapport à NVDA+Firefox sur certains composants (notamment les live regions et les dialogues).

Narrator + Edge : En progression

Narrator est le lecteur d’écran natif de Windows, activé par défaut depuis Windows 10. Longtemps très limité, il s’est beaucoup amélioré depuis Windows 11.

• Système : Windows
• Coût : inclus dans Windows
• Activation : Win+Ctrl+Entrée
• Combinaison recommandée : Narrator + Edge

Son importance en audit augmente car c’est l’AT que les utilisateurs Windows découvrent en premier — sans installation ni achat. Sur les sites de communes, un habitant qui commence à perdre la vue peut activer Narrator avant de connaître NVDA.

TalkBack + Chrome : Mobile Android

TalkBack est le lecteur d’écran natif Android, installé par défaut sur les appareils Google et Samsung.

• Système : Android
• Coût : gratuit, inclus dans Android
• Activation : Accessibilité → TalkBack dans les réglages Android
• Combinaison recommandée : TalkBack + Chrome

Pour les sites de communes, TalkBack est particulièrement important : une part significative des utilisateurs en situation de handicap visuel utilise Android sur mobile comme terminal principal.

Attributs ARIA au support inégal

Ces attributs sont dans la spécification, mais leur support réel varie suffisamment pour influencer les décisions d’implémentation.

aria-controls : Annoncé par JAWS, ignoré par NVDA et VoiceOver

<button aria-expanded="false" aria-controls="panneau-1">
  Voir les détails
</button>
<div id="panneau-1" hidden>...</div>

Verdict : ne pas compter sur aria-controls pour créer une relation navigable entre éléments. L’utiliser comme documentation sémantique et pour JAWS, mais construire la relation via la structure HTML et l’ordre du DOM.

aria-errormessage : Bien supporté mais avec fallback recommandé

<input aria-invalid="true" aria-errormessage="msg-erreur-email">
<p id="msg-erreur-email">Format invalide.</p>

Verdict : utiliser aria-errormessage mais ajouter aria-describedby pointant vers le même élément en fallback, ça ne nuit pas et garantit l’annonce même sur les AT qui ignorent aria-errormessage.

<!-- Double couverture — aria-errormessage + aria-describedby sur le même id -->
<input
  aria-invalid="true"
  aria-errormessage="msg-err"
  aria-describedby="msg-err"
>
<p id="msg-err" role="alert">Format invalide.</p>

aria-modal : Support inégal, compléter avec inert

<div role="dialog" aria-modal="true">...</div>

Verdict : aria-modal="true" seul est insuffisant. Compléter avec inert sur le contenu en arrière-plan pour une couverture complète.

<!-- Pendant l'ouverture de la modale -->
<main inert>
  <!-- contenu principal inaccessible pendant la modale -->
</main>

<div role="dialog" aria-modal="true" aria-labelledby="titre-modal">
  <h2 id="titre-modal">Titre</h2>
  <!-- contenu de la modale -->
</div>

inert bloque à la fois le focus clavier ET la lecture AT, plus fiable qu’aria-modal seul ou qu’aria-hidden sur le fond.

inert : Excellent mais vérifier la baseline du projet

<div inert>Contenu inaccessible</div>

Verdict : support moderne bien établi. Si le projet supporte des navigateurs antérieurs à 2022 (rare mais possible sur des sites de communes avec une clientèle âgée utilisant des appareils anciens), vérifier la baseline. Un polyfill existe (wicg-inert).

aria-roledescription : Bien supporté, à utiliser avec parcimonie

Permet de renommer le rôle annoncé par l’AT. Utile pour les composants custom dont le rôle natif ARIA est trop générique.

<section
  aria-label="Photos du patrimoine"
  aria-roledescription="carrousel"
>

→ NVDA : "Photos du patrimoine, carrousel"
  (au lieu de "Photos du patrimoine, région")

Verdict : bien supporté. Mais à utiliser uniquement quand le rôle natif est vraiment trompeur. Créer des rôles personnalisés sans raison valable perturbe les utilisateurs qui ont des habitudes basées sur les rôles standards.

aria-haspopup : Support variable selon la valeur

<!-- Différentes valeurs, comportements différents -->
<button aria-haspopup="menu">Actions</button>
<button aria-haspopup="dialog">Voir les détails</button>
<button aria-haspopup="listbox">Choisir une option</button>

Verdict : tester par valeur. "menu" / "true" est le mieux supporté. Pour les dialogues, "dialog" est annoncé par JAWS mais ignoré par NVDA+Firefox. L’information reste utile pour les utilisateurs JAWS.

Lire l’arbre d’accessibilité sans lecteur d’écran

L’arbre d’accessibilité est la représentation de la page que construit le navigateur à partir du HTML et de l’ARIA. C’est ce que lisent les AT, pas le HTML brut. Le lire dans les DevTools permet de vérifier rapidement ce qu’un lecteur d’écran verra, sans avoir à lancer NVDA.

Chrome DevTools

1. Ouvrir DevTools (F12)
2. Onglet Elements
3. Clic droit sur un élément → Inspect accessibility properties
4. Ou : onglet Accessibility dans le panneau latéral

Ce que l’arbre d’accessibilité de Chrome montre :

button "Fermer la fenêtre" (focused)
  role:    button
  name:    "Fermer la fenêtre"       ← nom calculé (pas aria-label brut)
  state:   focusable, focused
  
input "Adresse email"
  role:    textbox
  name:    "Adresse email"           ← vient du <label> associé
  required: true                     ← vient de aria-required ou required
  invalid:  true                     ← vient de aria-invalid
  description: "Format : nom@exemple.fr"  ← vient de aria-describedby

Ce qu’il faut vérifier :

• name : le nom calculé correspond-il à ce qui devrait être annoncé ?
• role : le rôle est-il correct (pas de rôle natif écrasé par ARIA incorrect) ?
• state : les états sont-ils à jour (expanded, checked, invalid…) ?
• description : la description complémentaire est-elle présente ?

Firefox DevTools

1. Ouvrir DevTools (F12)
2. Onglet Accessibilité
3. Cliquer sur “Activer les fonctionnalités d’accessibilité” si nécessaire
4. Naviguer dans l’arbre ou utiliser “Sélectionner un élément accessible” (icône curseur)

Firefox affiche également les problèmes d’accessibilité détectés automatiquement : contrastes insuffisants, éléments focusables sans nom, etc.

Différence entre arbre Chrome et arbre Firefox

Les deux arbres ne sont pas identiques. Chrome et Firefox calculent parfois le nom accessible différemment, notamment sur les éléments complexes avec plusieurs sources de label (aria-label + aria-labelledby + texte natif). Si le nom affiché diffère entre les deux, Firefox est généralement plus proche du comportement NVDA.

La matrice de test minimale en audit RGAA

En audit RGAA, tester avec toutes les combinaisons AT+navigateur est impossible dans les délais réels. Voici la matrice minimale recommandée selon le contexte :

Pour un site de commune (contexte boussole-rgaa)

Vérifications sans AT (arbre d’accessibilité)

Avant de lancer un lecteur d’écran, vérifier dans les DevTools :

1. Chaque bouton et lien a un nom accessible non vide
2. Les champs de formulaire ont un label calculé
3. Les éléments interactifs custom ont le bon rôle
4. Les états (aria-expanded, aria-selected, aria-invalid) sont cohérents avec l’état visuel
5. Aucun élément focusable n’a aria-hidden="true"

La référence à garder sous la main

a11ysupport.io ↗ lien externe qui s'ouvre dans un nouvel onglet est la source la plus complète et la plus maintenue pour le support AT par attribut ARIA et par fonctionnalité HTML. Pour chaque attribut, le site documente le comportement exact par paire AT+navigateur, avec des tests reproductibles.

Avant d’implémenter un attribut ARIA peu courant, consulter a11ysupport.io pour vérifier son support dans les combinaisons qui comptent pour ton contexte.