Comment réaliser un audit d’accessibilité ?
Obtenir une idée de l’accessibilité de votre module, thème ou site peut sembler une tâche ardue. Si vous êtes novice en accessibilité, le sujet lui-même peut vous laisser perplexe quant au point de départ. S’adapter à une diversité de capacités signifie qu’un large éventail de questions doit être considéré. Dans cette documentation, nous listons les considérations nécessaires sous forme d’un processus logique et étape par étape pour vérifier l’accessibilité d’un thème ou site lié à votre module.
Commencez par exécuter des outils automatisés
Beaucoup de problèmes d’accessibilité peuvent être détectés en analysant la page avec des outils automatisés. Parmi ces outils figurent WAVE, Tenon, Accessibility Insights, Google Lighthouse, Siteimprove et l’extension Siteimprove Accessibility Checker pour Chrome. Partiellement automatisable avec axe-core. Ces outils vous aideront à identifier rapidement certains problèmes comme une structure HTML incorrecte, des attributs ARIA manquants, ou un contraste de couleur insuffisant.
Tester la navigation au clavier
La navigation au clavier est le principal moyen d’accéder à tout l’écran pour les utilisateurs ne pouvant ou ne souhaitant pas utiliser une souris. Cela inclut les utilisateurs de lecteurs d’écran ainsi que les personnes avec des troubles moteurs tels que le syndrome de stress répétitif (RSI) ou la paralysie. Pour une bonne expérience clavier, assurez-vous d’un ordre logique de tabulation et de styles de focus facilement visibles. Assurez-vous aussi que l’utilisateur ne doit pas tabuler excessivement.
Points à vérifier
- Pouvez-vous sauter les contenus répétés ?
Un lien de saut doit être fourni pour permettre aux utilisateurs d’accéder directement au contenu unique de la page, en sautant les menus de navigation répétés. Ce lien doit être le premier élément tabbable et visible lorsqu’il reçoit le focus.
- Tous les contrôles sont-ils accessibles au clavier ?
Chaque élément interactif doit être utilisable au clavier. Développer/replier, vues arborescentes, curseurs, dialogues et overlays, glisser-déposer — tout doit être accessible ou avoir une alternative.
- Pouvez-vous naviguer dans les deux sens avec Tab ?
Assurez-vous que la navigation avec Tab en avant et Shift+Tab en arrière fonctionne, évitant ainsi les pièges clavier.
- Existe-t-il des pièges clavier ?
Évitez que le focus soit complètement piégé. L’utilisateur doit pouvoir sortir des overlays, modaux, ou widgets d’autocomplétion uniquement avec le clavier.
- Le focus est-il limité aux dialogues ?
Quand un dialogue est ouvert, le focus clavier doit être confiné à l’intérieur, pour éviter que l’utilisateur navigue hors de celui-ci sans le voir.
- Le focus est-il toujours visible ?
Tout contrôle interactif doit être focalisable et afficher un indicateur visible (ex. anneau de focus). Sans indication visuelle, un utilisateur clavier ne sait pas où il est.
- Y a-t-il du contenu invisible mais accessible au clavier ?
Vérifiez qu’aucun contenu caché ne soit encore tabbable.
- Les contenus visibles au survol ont-ils des équivalents accessibles au clavier ?
Le contenu qui apparaît au survol doit avoir une alternative accessible au clavier, indispensable aussi aux utilisateurs tactiles.
- Y a-t-il des éléments focalisables qui ne devraient pas l’être ?
- Les contenus non interactifs ne doivent pas être focalisables.
- N’ajoutez pas tabindex="0" aux éléments sauf si l’utilisateur doit les contrôler.
- Les tabindex inutiles compliquent la navigation.
- L’ordre de tabulation est-il naturel et logique ?
Si tabindex est modifié ou si la structure DOM est différente du rendu visuel, la navigation peut devenir confuse pour les utilisateurs clavier voyants.
Revérifiez vos points de contrôle
Après tous ces tests, augmentez le zoom du navigateur jusqu’au point de rupture responsive et testez de nouveau. Les utilisateurs avec un fort zoom naviguent souvent sur la version « tablette » ou « mobile » même sur leur ordinateur.
Les titres
Les titres structurent le contenu. Une bonne hiérarchie reflète la structure de la page, comme un sommaire. Des titres descriptifs et bien hiérarchisés sont essentiels car certains lecteurs d’écran s’en servent pour parcourir la page.
À vérifier
- Y a-t-il un seul élément H1 par page ?
Une page doit contenir un seul H1 décrivant son contenu.
- Les niveaux des titres correspondent-ils au contenu ?
Utilisez les titres selon leur niveau, pas selon la taille de police. Ne sautez pas de niveaux.
- Les titres sont-ils suffisamment descriptifs ?
Un bon titre décrit brièvement le contenu qu’il introduit.
Couleur et contraste
Contraste suffisant
Le contraste entre la couleur du texte et le fond doit être d’au moins 4,5:1. Utilisez des outils de vérification de contraste pour valider vos couleurs.
La couleur ne doit pas être le seul moyen de transmission d’information
La couleur seule ne doit pas transmettre d’information importante, car les daltoniens peuvent la manquer.
Utilisez aussi au moins une des méthodes suivantes :
- Texte descriptif (ex. « activé » / « désactivé » à côté d’un indicateur vert/rouge)
- Icônes significatives pour différencier les états
- Pour indiquer des erreurs de formulaire, ne dites pas seulement « champs en rouge », mais mentionnez les champs par leur nom et utilisez une icône visible
Exemple : marquer les champs obligatoires en rouge et avec une astérisque.
Le focus ne doit pas reposer uniquement sur la couleur, mais aussi sur un contour ou un indicateur visuel distinct.
Pas seulement une icône
Si une icône joue un rôle fonctionnel, elle doit être accompagnée d’un texte décrivant sa fonction. Assurez-vous que les éléments interactifs (menus, boutons) sont correctement étiquetés. Les utilisateurs ne comprennent pas toujours les icônes seules, et les lecteurs d’écran ont besoin d’étiquettes textuelles.
Son et vidéo
Pour le contenu audio ou vidéo, assurez-vous que des sous-titres ou transcriptions sont disponibles. Voir WebAim : sous-titres, transcriptions et descriptions audio.
- Une vidéo informative, avec ou sans son, doit avoir une transcription pour les malvoyants.
- Une vidéo informative avec son doit inclure des sous-titres pour les malentendants.
- Pour une vidéo complexe avec son, il peut être nécessaire d’ajouter une description audio des scènes pour les malvoyants.
- Les vidéos en direct doivent fournir des sous-titres pour les malentendants.
- L’audio en direct doit offrir une alternative textuelle pour les malvoyants.
Cela concerne les contenus temporels selon WCAG 1.2.
Animations et lecture automatique
Les animations, vidéos ou audios lancés automatiquement peuvent distraire et gêner la concentration. Même si le contenu est placé où vous pensez qu’il ne pose pas problème, les usages utilisateurs varient.
Exemples :
- Animations : carrousel défilant automatiquement des images
- Lecture automatique vidéo : vidéo YouTube lancée au chargement de la page
- Lecture automatique audio : station radio lancée au chargement de la page
Pour limiter les distractions :
- Évitez les animations, vidéos ou audios de plus de 5 secondes sans contrôle utilisateur.
- Fournissez des contrôles pour permettre à l’utilisateur d’arrêter, démarrer ou mettre en pause.
Contenu dynamique
JavaScript permet de modifier la page sans rechargement complet. Les utilisateurs doivent être informés de ces changements. Par exemple, mise à jour dynamique des résultats de recherche ou notification affichée sans interaction.
L’API Drupal.announce() permet de signaler les changements dynamiques aux technologies d’assistance.
Drupal.announce() s’appuie sur les régions ARIA live. Des exemples d’utilisation sont disponibles dans la documentation des rôles ARIA live regions.
Le meilleur moyen de tester le contenu dynamique est avec un lecteur d’écran.
Tests avec un lecteur d’écran
L’exécution d’outils automatiques et la navigation manuelle sont utiles, mais certains problèmes ne sont détectables qu’avec un lecteur d’écran.
Points à vérifier
- Tous les contrôles ont-ils une étiquette ?
Chaque contrôle doit avoir une étiquette décrivant sa fonction. Souvent, cela se fait via l’élément <label>, mais parfois l’attribut aria-labelledby est nécessaire.
- Les contrôles personnalisés ont-ils un rôle ARIA et les attributs nécessaires indiquant leur état ?
Les utilisateurs d’aides techniques doivent recevoir les mêmes informations que les utilisateurs voyants via les indices visuels (styles, position du curseur). Les éléments natifs fournissent cela automatiquement, mais les contrôles personnalisés nécessitent l’ajout d’ARIA. Par exemple, un composant slider personnalisé doit avoir le rôle ARIA « slider » et des attributs comme aria-valuenow, aria-valuemin, aria-valuemax.
- Le flux d’informations correspond-il à ce qui est affiché à l’écran ?
Le CSS peut modifier le flux d’information. Le contenu est-il logique lorsqu’il est lu par un lecteur d’écran ?
- Les textes des liens sont-ils compréhensibles ?
Les lecteurs d’écran annoncent « lien » avant chaque lien. Évitez donc d’inclure le mot « lien » dans le texte des liens, car cela serait redondant. Les liens doivent avoir un sens hors contexte. Évitez les textes ambigus comme « cliquez ici », « en savoir plus ».
- Toutes les images ont-elles un texte alternatif approprié ?
Toutes les images doivent avoir un attribut alt correct, sauf si elles sont purement décoratives. Dans ce cas, alt="" doit être utilisé pour qu’elles soient ignorées par le lecteur d’écran.
Tests manuels avec lecteur d’écran
Certaines erreurs ne sont détectables qu’en testant manuellement avec un lecteur d’écran. Les lecteurs les plus répandus sont VoiceOver (Mac OS) et NVDA (Windows). Pour débuter avec VoiceOver, voyez cette vidéo d’introduction et le tutoriel WebAIM. Pour NVDA, voyez cette vidéo et le guide de Marco Zehe sur l’utilisation de NVDA et Firefox pour tester l’accessibilité web.
Une fois que vous maîtrisez les commandes essentielles du lecteur d’écran, essayez de désactiver votre moniteur et de vous passer de souris. N’oubliez pas que la qualité de la synthèse vocale ne doit pas influencer vos tests.
Si vous débutez avec un lecteur d’écran, le test peut sembler difficile. Il faut du temps pour apprendre à naviguer sans visuel et maîtriser les raccourcis clavier. De plus, les lecteurs fonctionnent différemment selon les navigateurs et plateformes, il est donc important de tester avec plusieurs combinaisons.