Aller au contenu

Tester l'accessibilité

Le test d'accessibilité est la dernière étape avant la publication. Les outils automatiques repèrent beaucoup de problèmes, mais ils passent à côté d'environ la moitié de tous les problèmes d'accessibilité. La combinaison du scan automatique, du test au clavier et du test au lecteur d'écran vous donne la meilleure couverture.

Deux principes directeurs :

  1. Testez tôt et souvent. N'attendez pas que le site soit « terminé ». Vérifiez chaque page à mesure que vous la construisez -- les problèmes sont plus faciles à corriger avant que la mise en page ne se complexifie.
  2. Les outils automatiques trouvent les problèmes de code. Le test manuel trouve les problèmes d'expérience. Un outil peut signaler un texte alternatif manquant, mais seul un humain peut juger si le texte alternatif décrit vraiment bien l'image.

Liste de vérification rapide avant publication

Parcourez cette liste pour chaque page avant de publier :

  • [ ] Chaque image a un texte alternatif approprié (descriptif ou vide pour les décoratives)
  • [ ] Le contraste des couleurs respecte le WCAG AA (4.5:1 pour le texte, 3:1 pour les grands textes et l'interface)
  • [ ] La hiérarchie des titres est logique (h1 > h2 > h3, sans sauter de niveau)
  • [ ] Chaque champ de formulaire a un <label> visible
  • [ ] La page est entièrement utilisable au clavier seul (Tab, Entrée, Échap)
  • [ ] Les indicateurs de focus sont visibles sur chaque élément interactif
  • [ ] La langue de la page est définie dans les Réglages du site
  • [ ] Les liens ont un texte descriptif (pas de « cliquez ici »)
  • [ ] Aucun contenu ne clignote plus de 3 fois par seconde
  • [ ] Les repères <nav> multiples sont étiquetés avec aria-label

Test au clavier

Le test manuel le plus simple et le plus efficace. Aucun outil requis.

  1. Ouvrez votre page publiée dans un navigateur
  2. Appuyez sur Tab pour parcourir la page
  3. Vérifiez :
  4. Pouvez-vous atteindre chaque lien, bouton et champ de formulaire ?
  5. L'indicateur de focus est-il visible à chaque étape ?
  6. L'ordre du focus correspond-il à l'ordre de lecture visuel ?
  7. Pouvez-vous activer les boutons avec Entrée ou Espace ?
  8. Pouvez-vous fermer les surcouches ou menus avec Échap ?
  9. Y a-t-il des pièges au clavier (le focus reste bloqué et vous ne pouvez pas en sortir avec Tab) ?

Si vous trouvez des problèmes, voir Navigation au clavier et focus pour les corrections.

Extensions de navigateur

Ces extensions scannent la page et signalent les problèmes d'accessibilité directement dans votre navigateur.

axe DevTools

axe DevTools (de Deque) est l'extension de test d'accessibilité la plus utilisée.

  1. Installez l'extension axe DevTools pour Chrome, Firefox ou Edge
  2. Ouvrez votre page publiée
  3. Ouvrez les DevTools du navigateur (F12)
  4. Allez dans l'onglet axe DevTools
  5. Cliquez sur Scan All of My Page
  6. Examinez les résultats -- chaque problème inclut :
  7. L'élément concerné (mis en évidence sur la page)
  8. Le critère WCAG qu'il enfreint
  9. Une description du problème
  10. Comment le corriger

WAVE

WAVE (de WebAIM) fournit une surcouche visuelle montrant les problèmes d'accessibilité, les alertes et les éléments structurels.

  1. Installez l'extension WAVE pour Chrome ou Firefox
  2. Ouvrez votre page publiée
  3. Cliquez sur l'icône WAVE dans la barre d'outils
  4. Des icônes apparaissent sur la page marquant les erreurs (rouge), les alertes (jaune) et les caractéristiques structurelles (vert/bleu)
  5. Cliquez sur n'importe quelle icône pour les détails

WAVE est particulièrement utile pour visualiser la structure des titres, les régions repères et le texte alternatif manquant.

Lighthouse

Lighthouse est intégré aux DevTools de Chrome.

  1. Ouvrez votre page publiée dans Chrome
  2. Ouvrez les DevTools (F12)
  3. Allez dans l'onglet Lighthouse
  4. Sélectionnez Accessibility (décochez les autres catégories pour accélérer le scan)
  5. Cliquez sur Analyze page load
  6. Examinez le score d'accessibilité et les problèmes individuels

Lighthouse donne un score de 0 à 100. Visez 90+, mais rappelez-vous qu'un score parfait ne signifie pas que le site est entièrement accessible -- Lighthouse ne détecte que les problèmes automatisables.

Test au lecteur d'écran

Le test au lecteur d'écran révèle ce que l'expérience ressent réellement pour les utilisateurs de technologies d'assistance. Même un test court attrape des problèmes qu'aucun outil automatique ne peut trouver.

Lecteurs d'écran disponibles

Lecteur d'écran Plateforme Coût
NVDA Windows Gratuit et open source
VoiceOver macOS, iOS Intégré au système
TalkBack Android Intégré au système
Narrator Windows Intégré au système
JAWS Windows Payant (démo gratuite)

Recommandation pour un premier test : utilisez NVDA sur Windows (gratuit) ou VoiceOver sur macOS (déjà installé, activez-le avec Cmd+F5).

Test de base au lecteur d'écran

  1. Activez le lecteur d'écran
  2. Naviguez vers votre page publiée
  3. Écoutez le lecteur d'écran lire la page de haut en bas
  4. Vérifiez :
  5. Les images sont-elles annoncées avec des descriptions utiles ?
  6. Les titres sont-ils annoncés avec leur niveau (h1, h2, h3) ?
  7. Les champs de formulaire sont-ils annoncés avec leurs labels ?
  8. Pouvez-vous comprendre la structure de la page à partir de l'audio seul ?
  9. Les repères sont-ils annoncés (« navigation », « main », « footer ») ?
  10. Essayez de naviguer par titres (touche H dans NVDA/VoiceOver), par repères (touche D dans NVDA) et par liens (touche K dans NVDA)

Test automatique ou test manuel

Ce que les outils automatiques détectent Ce que seul le test manuel détecte
Texte alternatif manquant Si le texte alternatif est réellement descriptif
Échecs de ratio de contraste Si la couleur seule transmet du sens
Labels de formulaire manquants Si les labels sont clairs et utiles
Langue de page manquante Si le contenu dans d'autres langues est marqué
Sauts de niveau de titre Si le texte des titres correspond à la structure du contenu
Rôles de repère manquants Si les repères sont étiquetés de façon pertinente
Erreurs de syntaxe ARIA Si ARIA est utilisé de façon appropriée

Utilisez les deux. Lancez d'abord un scan automatique pour repérer les problèmes évidents, puis faites un test au clavier et au lecteur d'écran pour attraper le reste.

Exemple pratique : auditer une page avec Lighthouse et le clavier

Vous avez construit une page portfolio et voulez vérifier son accessibilité avant de publier.

  1. Publiez la page pour obtenir une URL en ligne (ou utilisez l'aperçu du navigateur)

  2. Lancez Lighthouse :

  3. Ouvrez la page dans Chrome
  4. DevTools > Lighthouse > Accessibility > Analyze

  5. Résultat : score 78. Problèmes trouvés :

    • 2 images sans texte alternatif
    • 1 champ de formulaire sans label
    • 1 échec de contraste (gris clair sur blanc)

  6. Corrigez les problèmes automatisables :

  7. Ajoutez un texte alternatif aux images (ou un alt vide pour les décoratives)
  8. Ajoutez un <label> au champ de formulaire avec un attribut for correspondant

  9. Assombrissez la couleur du texte pour atteindre un ratio de contraste de 4.5:1

  10. Relancez Lighthouse : score 95.

  11. Test au clavier :

  12. Tabulez à travers la page. Découverte : une carte du portfolio est un Div stylisé faisant office de lien -- elle n'est pas atteignable au clavier.

  13. Correction : entourez le contenu de la carte d'un élément <a> ou changez la balise du Div en <a> et définissez le href.

  14. Test au lecteur d'écran (facultatif mais recommandé) :

  15. Activez VoiceOver (Cmd+F5 sur macOS)
  16. Naviguez à travers la page. Découverte : deux éléments <nav> s'annoncent tous deux comme « navigation » sans distinction.
  17. Correction : ajoutez aria-label à chaque nav via la section Attributes.

Erreurs courantes

  • Ne lancer que des outils automatiques. Ils détectent environ 30 à 50 % des problèmes d'accessibilité. Le test au clavier et au lecteur d'écran sont essentiels.
  • Tester uniquement sur ordinateur. Les lecteurs d'écran mobiles (VoiceOver sur iOS, TalkBack sur Android) se comportent différemment. Si votre audience est mobile, testez-y aussi.
  • Traiter un score Lighthouse de 100 comme « accessible ». Cela signifie qu'aucun problème automatisable n'a été trouvé. De nombreux problèmes d'accessibilité requièrent un jugement humain.
  • Ne tester qu'une seule fois à la fin. Testez à mesure que vous construisez. Un problème de contraste repéré sur la page 1 peut se répéter sur chaque page.
  • Sauter le test au clavier. Il prend 2 minutes par page et attrape des problèmes critiques (pièges de focus, éléments inatteignables, liens d'évitement manquants).

Pour aller plus loin

Quiz

Q1 : Vous lancez Lighthouse et obtenez un score d'accessibilité de 100. Votre site est-il entièrement accessible ?

  • A) Oui, 100 signifie que tous les problèmes sont résolus
  • B) Non, les outils automatiques passent à côté d'environ la moitié des problèmes d'accessibilité
  • C) Oui, mais uniquement pour les utilisateurs de lecteur d'écran
Réponse

B) Non, les outils automatiques passent à côté d'environ la moitié des problèmes d'accessibilité -- Lighthouse vérifie des motifs de code (alt manquant, mauvais ratios de contraste) mais ne peut pas juger si le texte alternatif est descriptif, si l'ordre du focus a du sens, ou si la page est compréhensible lue à voix haute.

Q2 : Vous testez une page au clavier. Vous appuyez sur Tab et le focus se déplace vers un élément, mais vous ne voyez pas où il se trouve. Quelle est la cause probable ?

  • A) Le navigateur a un bug
  • B) Les contours de focus ont été supprimés en CSS (outline: none)
  • C) L'élément est masqué
Réponse

B) Les contours de focus ont été supprimés en CSS -- c'est une erreur d'accessibilité courante. Rétablissez ou restylisez l'indicateur de focus. Voir Navigation au clavier et focus.

Q3 : Quelle approche de test attrape le plus de problèmes d'accessibilité ?

  • A) Les outils automatiques uniquement (axe, Lighthouse)
  • B) Le test manuel uniquement (clavier, lecteur d'écran)
  • C) Le test automatique et manuel combinés
Réponse

C) Les deux combinés -- les outils automatiques sont rapides et attrapent les problèmes au niveau du code. Le test manuel attrape les problèmes au niveau de l'expérience. Ensemble, ils offrent la meilleure couverture.

Éditer cette page sur GitLab