Vérifier l'accessibilité

Rob Dodson

Déterminer si votre site Web ou votre application est accessible peut sembler une tâche ardue. Si vous abordez l'accessibilité pour la première fois, l'étendue du sujet peut vous amener à vous demander par où commencer. Après tout, si vous essayez de vous adapter à un large éventail de capacités, cela signifie qu'il y a un éventail tout aussi différent de problèmes à prendre en compte.

Cet article décompose ces problèmes en un processus logique et étape par étape pour examiner l'accessibilité d'un site existant.

Commencez avec le clavier

Pour les utilisateurs qui ne peuvent pas ou choisissent de ne pas utiliser la souris, la navigation au clavier est le principal moyen d'atteindre tous les éléments à l'écran. Cette audience inclut les utilisateurs souffrant de déficiences motrices telles que les blessures liées au stress ou la paralysie répétitives, ainsi que les utilisateurs de lecteurs d'écran.

Pour une expérience de clavier de qualité, essayez d'utiliser un ordre de tabulation logique et des styles de mise au point clairement identifiables.

  • Commencez par parcourir votre site via la touche de tabulation. L'ordre dans lequel les éléments sont sélectionnés doit suivre l'ordre du DOM. Si vous ne savez pas quels éléments doivent faire l'objet d'une mise au point, consultez Principes de base de la sélection pour un rappel. La bonne pratique est que toute commande avec laquelle un utilisateur peut interagir ou fournir une entrée doit être sélectionnable et afficher un indicateur de mise au point (tel qu'un anneau de sélection).

  • Les commandes interactives personnalisées doivent être sélectionnables. Si vous utilisez JavaScript pour transformer une <div> en une liste déroulante sophistiquée, elle ne sera pas automatiquement insérée dans l'ordre de tabulation. Pour qu'une commande personnalisée puisse être sélectionnable, attribuez-lui un tabindex="0". Les valeurs tabindex supérieures à 0 modifient l'ordre de tabulation et peuvent prêter à confusion pour les utilisateurs de lecteurs d'écran.

  • Faites en sorte que seul le contenu interactif soit sélectionnable. L'ajout de tabindex aux éléments non interactifs tels que les titres ralentit les utilisateurs du clavier qui peuvent voir l'écran. Cela n'aide pas les utilisateurs de lecteurs d'écran, car le lecteur d'écran sait déjà l'annoncer.

  • Si vous ajoutez du nouveau contenu à une page, dirigez d'abord l'utilisateur vers ce contenu afin qu'il puisse prendre des mesures dessus. Pour obtenir des exemples, consultez la page Gérer le ciblage au niveau de la page.

  • Concevez votre site de sorte que l'utilisateur puisse toujours se concentrer sur l'élément suivant quand il le souhaite. Méfiez-vous des widgets de saisie semi-automatique et des autres contextes qui peuvent piéger la sélection au clavier. Vous pouvez piéger temporairement le focus lorsque vous souhaitez que l'utilisateur interagit avec une fenêtre modale et non avec le reste de la page, mais vous devez toujours fournir un moyen accessible via le clavier pour échapper la fenêtre modale. Consultez la section Modales et pièges à clavier pour obtenir un exemple.

Rendre la mise au point utilisable

Si vous avez créé une commande personnalisée, permettez à vos utilisateurs d'accéder à toutes ses fonctionnalités en n'utilisant que le clavier. Pour connaître les techniques permettant d'améliorer l'accès au clavier, consultez la page Gérer le ciblage des composants.

Gérer le contenu hors écran

De nombreux sites comportent du contenu hors écran qui est présent dans le DOM, mais qui n'est pas visible, comme des liens dans un menu de panneau responsif ou un bouton dans une fenêtre modale qui n'a pas encore été affiché. Laisser ces éléments dans le DOM peut créer une expérience de clavier déroutante, en particulier pour les lecteurs d'écran, qui affichent le contenu hors écran comme s'il faisait partie de la page.

Consultez Gérer le contenu hors écran pour obtenir des conseils sur la gestion de ces éléments.

Tester avec un lecteur d'écran

L'amélioration de la prise en charge générale du clavier jette les bases pour l'étape suivante, qui consiste à vérifier que l'étiquetage et la sémantique de la page sont corrects, ainsi que tout obstacle à la navigation avec le lecteur d'écran.

Si vous ne savez pas comment le balisage sémantique est interprété par les technologies d'assistance, consultez la page Structure du contenu.

  • Vérifiez que le texte alt de toutes les images est correct. Il existe une exception à cette pratique lorsque les images sont principalement utilisées à des fins de présentation et ne sont pas des éléments de contenu essentiels. Pour indiquer que les lecteurs d'écran doivent ignorer une image, définissez la valeur sur une chaîne vide: alt="".
  • Vérifiez toutes les commandes d'un libellé. Pour les commandes personnalisées, vous devrez peut-être utiliser aria-label ou aria-labelledby. Consultez l'article Étiquettes et relations ARIA pour obtenir des exemples.
  • Vérifiez que toutes les commandes personnalisées comportent un élément role approprié et tous les attributs ARIA requis qui communiquent leur état. Par exemple, une case à cocher personnalisée a besoin de role="checkbox" et de aria-checked="true|false" pour transmettre correctement son état. Consultez la page Présentation d'ARIA pour découvrir comment ARIA peut fournir la sémantique manquante pour les commandes personnalisées.
  • Faites en sorte que la circulation des informations sur votre page soit judicieuse. Étant donné que les lecteurs d'écran parcourent la page dans l'ordre DOM, ils annoncent tous les éléments que vous avez repositionnés visuellement à l'aide de code CSS dans un ordre incompréhensible. Si vous souhaitez qu'un élément apparaisse plus tôt sur la page, déplacez-le physiquement dans le DOM.
  • Faites en sorte de permettre la navigation via le lecteur d'écran pour tout le contenu de la page. Assurez-vous qu'aucune section du site n'est définitivement masquée ou empêche l'accès au lecteur d'écran.
    • Si le contenu doit être masqué pour un lecteur d'écran, par exemple s'il est hors écran ou simplement de présentation, définissez-le sur aria-hidden="true". Pour en savoir plus, consultez la section Masquer du contenu.

Se familiariser avec les lecteurs d'écran

Même si apprendre à utiliser un lecteur d'écran peut sembler intimidant, il est en fait assez convivial. En général, la plupart des développeurs peuvent s'en sortir avec quelques commandes clés simples.

Si vous utilisez un Mac, regardez cette vidéo sur VoiceOver, le lecteur d'écran intégré à Mac OS. Si vous utilisez un PC, regardez cette vidéo sur NVDA, un lecteur d'écran Open Source financé par des dons pour Windows.

aria-hidden n'empêche pas la sélection au clavier

Il est important de comprendre que les ARIA ne peuvent affecter que la sémantique d'un élément. Elles n'ont aucun effet sur le comportement de l'élément. Vous pouvez masquer un élément pour les lecteurs d'écran avec aria-hidden="true", mais cela ne modifie pas le comportement de sélection de cet élément. Pour le contenu interactif hors écran, utilisez l'attribut inert afin de vous assurer qu'il est bien supprimé du clavier. Pour les navigateurs plus anciens, combinez aria-hidden="true" et tabindex="-1".

Les éléments interactifs doivent indiquer leur objectif et leur état

Fournir des conseils visuels, ou affordances, sur l'utilité d'une commande, aide un large éventail d'utilisateurs sur une grande variété d'appareils à exploiter et à parcourir votre site.

  • Les éléments interactifs, comme les liens et les boutons, doivent se distinguer des éléments non interactifs. Il est difficile pour les utilisateurs de naviguer sur un site ou dans une application lorsqu'ils ne peuvent pas savoir si un élément est cliquable. Il existe de nombreuses façons valides d'indiquer les éléments interactifs. Une pratique courante consiste à souligner les liens pour les différencier du texte environnant.
  • À l'instar des exigences de sélection, les éléments interactifs tels que les liens et les boutons nécessitent un état hover pour indiquer aux utilisateurs de souris lorsque leur pointeur est placé sur un élément cliquable. Toutefois, pour rendre ces éléments accessibles à d'autres méthodes de saisie, ils doivent être identifiables sans état hover.

Tirez parti des titres et des points de repère

Les titres et les éléments de points de repère donnent une structure sémantique à votre page et augmentent considérablement l'efficacité de navigation des utilisateurs de technologies d'assistance. De nombreux utilisateurs de lecteurs d'écran signalent que lorsqu'ils accèdent pour la première fois à une page qu'ils ne connaissent pas, ils essaient généralement de naviguer par en-tête.

De même, les lecteurs d'écran permettent également d'accéder à des points de repère importants tels que <main> et <nav>. C'est pourquoi il est important de réfléchir à la façon dont la structure de votre page peut être utilisée pour guider l'expérience utilisateur.

  • Utilisez la hiérarchie h1-h6. Considérez les en-têtes comme des outils permettant de créer le contour de votre page. Ne vous fiez pas au style intégré des titres. Traitez-les plutôt comme s'ils avaient tous la même taille et utilisez le niveau sémantique approprié pour le contenu principal, secondaire et tertiaire. Ensuite, utilisez le CSS pour que les en-têtes correspondent à votre conception.
  • Utilisez des éléments et des rôles de point de repère afin que les utilisateurs puissent contourner les contenus répétitifs. De nombreuses technologies d'assistance fournissent des raccourcis pour accéder à des parties spécifiques de la page, telles que celles définies par les éléments <main> ou <nav>. Ces éléments ont des rôles de points de repère implicites. Vous pouvez également utiliser l'attribut ARIA role pour définir explicitement des régions sur la page, comme dans <div role="search">. Pour obtenir d'autres exemples, consultez Sémantique et navigation dans les contenus.
  • Évitez role="application", sauf si vous savez déjà comment l'utiliser. Le rôle de point de repère application indique à la technologie d'assistance de désactiver ses raccourcis et de transmettre toutes les pressions sur les touches à la page. Cela signifie que les touches que les utilisateurs de lecteurs d'écran utilisent généralement pour se déplacer sur la page ne fonctionnent plus et que vous devrez implémenter toutes les actions de clavier vous-même.

Passer en revue les titres et les points de repère avec un lecteur d'écran

Les lecteurs d'écran, tels que VoiceOver et NVDA, fournissent un menu contextuel permettant d'accéder directement aux régions importantes de la page. Lorsque vous testez l'accessibilité, vous pouvez utiliser ces menus pour obtenir un aperçu de la page et déterminer si vos niveaux de titre sont appropriés et quels points de repère sont utilisés.

Pour en savoir plus, regardez ces vidéos d'instructions sur les principes de base de VoiceOver et NVDA.

Automatiser le processus

Tester manuellement l'accessibilité d'un site peut s'avérer fastidieux et source d'erreurs. Il est utile d'automatiser les tests autant que possible. Vous pouvez utiliser les extensions de navigateur et les suites de tests d'accessibilité de la ligne de commande.

  • La page réussit-elle tous les tests des extensions de navigateur aXe ou WAVE ? D'autres options sont disponibles, mais ces extensions peuvent s'avérer utiles en complément de tout processus de test manuel, car elles peuvent détecter des problèmes subtils tels que l'échec des rapports de contraste et l'absence d'attributs ARIA.
    • Si vous préférez travailler sur la ligne de commande, axe-cli fournit les mêmes fonctionnalités que l'extension de navigateur aXe, mais vous pouvez l'exécuter à partir de votre terminal.
  • Pour éviter les régressions, en particulier dans un environnement d'intégration continue, intégrez une bibliothèque telle que axe-core à votre suite de tests automatisés. axe-core est le même moteur que l'extension Chrome aXe, mais dans un utilitaire de ligne de commande.
  • Si vous utilisez un framework ou une bibliothèque, fournit-il ses propres outils d'accessibilité ? Par exemple, le rapportor-accessibility-plugin pour Angular. Dans la mesure du possible, utilisez les outils disponibles.

Utiliser Lighthouse pour tester les PWA

Lighthouse est un outil qui mesure les performances de votre progressive web app (PWA). De plus, il utilise la bibliothèque axe-core pour effectuer ses tests d'accessibilité.

Si vous utilisez déjà Lighthouse, recherchez les échecs de tests d'accessibilité dans votre rapport. Corrigez les erreurs pour améliorer l'expérience utilisateur globale de votre site.

Ressources supplémentaires