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, la vaste étendue du sujet peut vous amener à vous demander par où commencer. Après tout, s'efforcer d'adapter un site à un large éventail de capacités implique de prendre en compte une grande variété de problèmes.

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

Commencer avec le clavier

Pour les utilisateurs qui ne peuvent pas ou choisissent de ne pas utiliser de souris, la navigation au clavier est le principal moyen d'accéder à tout ce qui est à l'écran. Cette audience inclut les utilisateurs souffrant d'un handicap moteur, comme une lésion due au stress répétitif (RSI) ou une paralysie, ainsi que les utilisateurs de lecteurs d'écran.

Pour une bonne expérience au clavier, essayez d'avoir un ordre de tabulation logique et des styles de mise au point clairement visibles.

  • Commencez par parcourir votre site à l'aide de la touche Tabulation. L'ordre dans lequel les éléments sont mis en surbrillance doit suivre l'ordre DOM. Si vous ne savez pas quels éléments doivent être mis en avant, consultez le module du cours "Apprendre l'accessibilité" sur le focus. Il est recommandé que toute commande avec laquelle un utilisateur peut interagir ou fournir une entrée puisse être sélectionnée et affiche un indicateur de sélection (comme un anneau de sélection).

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

  • Ne permettez la sélection que pour le contenu interactif. Ajouter tabindex à des éléments non interactifs tels que les titres ralentit les utilisateurs de clavier qui peuvent voir l'écran et ne les aide pas, car le lecteur d'écran sait déjà les annoncer.

  • Si vous ajoutez du contenu à une page, orientez d'abord l'attention de l'utilisateur vers ce contenu afin qu'il puisse y réagir. Pour obtenir des exemples, consultez la section Gérer la sélection au niveau de la page.

  • Concevez votre site de sorte que l'utilisateur puisse toujours mettre en surbrillance l'élément suivant lorsqu'il le souhaite. Méfiez-vous des widgets de saisie semi-automatique et des autres contextes pouvant bloquer le focus du clavier. Vous pouvez capturer temporairement le focus lorsque vous souhaitez que l'utilisateur interagisse avec une fenêtre modale et non avec le reste de la page. Toutefois, vous devez toujours fournir un moyen d'échapper à la fenêtre modale accessible au clavier. Pour obtenir un exemple, consultez la section Fenêtres modales et pièges de clavier.

Rendre votre commande de mise au point utilisable

Si vous avez créé un contrôle personnalisé, permettez à vos utilisateurs d'accéder à toutes ses fonctionnalités à l'aide du clavier uniquement. Consultez Gérer la sélection dans les composants pour découvrir des techniques permettant d'améliorer l'accès au clavier.

Gérer le contenu hors écran

De nombreux sites comportent du contenu hors écran dans le DOM, mais non visible. Il peut par exemple s'agir de liens dans un menu de panneau responsif ou d'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 saisie au clavier déroutante, en particulier pour les lecteurs d'écran, qui annoncent 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 manière de gérer ces éléments.

Tester l'application avec un lecteur d'écran

L'amélioration de la compatibilité générale avec le clavier prépare l'étape suivante, qui consiste à vérifier que la page comporte un libellé et une sémantique appropriés, et qu'elle ne présente aucune obstruction à la navigation avec un lecteur d'écran.

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

  • Vérifiez que le texte alt est correct dans toutes les images. L'exception à cette pratique est lorsque les images sont principalement destinées à des fins de présentation et ne constituent 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, cela peut nécessiter l'utilisation de aria-label ou aria-labelledby. Pour obtenir des exemples, consultez la section Libellés et relations ARIA.
  • Vérifiez que toutes les commandes personnalisées comportent un role approprié et tous les attributs ARIA requis qui communiquent leur état. Par exemple, une case à cocher personnalisée nécessite un role="checkbox" et un aria-checked="true|false" pour transmettre correctement son état. Consultez la section Présentation d'ARIA pour obtenir une présentation générale de la façon dont ARIA peut fournir les sémantiques manquantes pour les commandes personnalisées.
  • Organisez le flux d'informations de votre page de manière logique. É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 CSS dans un ordre absurde. Si vous devez afficher un élément plus tôt sur la page, déplacez-le physiquement plus tôt dans le DOM.
  • Essayez de permettre la navigation avec un lecteur d'écran pour tout le contenu de la page. Assurez-vous qu'aucune section du site n'est définitivement masquée ou bloquée pour les lecteurs d'écran.
    • Si un contenu doit être masqué par un lecteur d'écran (par exemple, s'il est hors écran ou s'il ne sert qu'à la présentation), définissez-le sur aria-hidden="true". Pour en savoir plus, consultez Masquer du contenu.

Familiarisez-vous avec les lecteurs d'écran

Même si apprendre à utiliser un lecteur d'écran peut sembler difficile, c'est en fait assez facile. 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 la spécification ARIA ne peut affecter que la sémantique d'un élément. Elle n'a aucun impact sur le comportement de l'élément. Vous pouvez masquer un élément aux 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 pour vous assurer qu'il est bien supprimé du flux du clavier. Pour les anciens navigateurs, combinez aria-hidden="true" avec tabindex="-1".

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

Fournir des indices visuels, ou affordances, sur l'action effectuée par un bouton permet à un large éventail d'utilisateurs sur différents appareils d'utiliser et de naviguer sur votre site.

  • Les éléments interactifs, comme les liens et les boutons, doivent être distinguables 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 déterminer si un élément est cliquable. Il existe de nombreuses façons valides d'indiquer des éléments interactifs. Une pratique courante consiste à souligner les liens pour les différencier du texte environnant.
  • Comme pour l'exigence de mise au point, les éléments interactifs tels que les liens et les boutons nécessitent un état hover pour indiquer aux utilisateurs de la souris quand leur pointeur se trouve sur un élément cliquable. Toutefois, pour que ces éléments soient accessibles aux autres modes de saisie, ils doivent être distinguables sans état hover.

Utiliser les titres et les repères

Les titres et les éléments de repère donnent à votre page une structure sémantique et améliorent considérablement l'efficacité de la navigation pour les utilisateurs de technologies d'assistance. De nombreux utilisateurs de lecteurs d'écran indiquent qu'ils tentent généralement de naviguer par titres lorsqu'ils accèdent pour la première fois à une page inconnue.

De même, les lecteurs d'écran permettent de passer à des repères 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 guider l'expérience utilisateur.

  • Utilisez la hiérarchie h1-h6. Considérez les titres comme des outils permettant de créer une structure pour 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émantiquement approprié pour le contenu principal, secondaire et tertiaire. Utilisez ensuite le CSS pour que les titres correspondent à votre conception.
  • Utilisez des éléments et des rôles de repère pour que les utilisateurs puissent ignorer 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 des éléments <main> ou <nav>. Ces éléments ont des rôles 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 en savoir plus, consultez Sémantique et navigation dans le contenu.
  • Évitez d'utiliser role="application", sauf si vous avez déjà travaillé avec. Le rôle de repère application indique à la technologie d'assistance de désactiver ses raccourcis et de transmettre toutes les pressions de touche à 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. Vous devrez donc implémenter tout le traitement du clavier vous-même.

Examiner les titres et les repères avec un lecteur d'écran

Les lecteurs d'écran, comme VoiceOver et NVDA, proposent un menu contextuel permettant de passer à des 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 les niveaux de titres sont appropriés et quels repères sont utilisés.

Pour en savoir plus, consultez ces vidéos d'instructions sur les bases de VoiceOver et de NVDA.

Automatiser le processus

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

  • La page passe-t-elle tous les tests des extensions de navigateur aXe ou WAVE ? D'autres options sont disponibles, mais ces extensions peuvent être un complément utile à tout processus de test manuel, car elles peuvent détecter des problèmes subtils tels que des ratios de contraste incorrects et des attributs ARIA manquants.
    • Si vous préférez travailler en ligne de commande, axe-cli offre les mêmes fonctionnalités que l'extension de navigateur aXe, mais peut être exécuté à partir de votre terminal.
  • Pour éviter les régressions, en particulier dans un environnement d'intégration continue, incorporez une bibliothèque comme axe-core dans votre suite de tests automatisés. axe-core est le même moteur qui alimente l'extension Chrome aXe, mais dans un utilitaire de ligne de commande.
  • Si vous utilisez un framework ou une bibliothèque, fournissent-ils leurs propres outils d'accessibilité ? Par exemple, le protractor-accessibility-plugin pour Angular. Dans la mesure du possible, profitez des outils disponibles.

Utiliser Lighthouse pour tester les PWA

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

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

Ressources supplémentaires