Vérifier l'accessibilité

Rob Dodson

Déterminer si votre site Web ou application est accessible peut sembler être une tâche écrasante. Si vous découvrez l'accessibilité pour la première fois, l'ampleur du sujet peut vous donner envie de commencer. Après tout, en s'adaptant à un large éventail de capacités signifie toute une variété correspondante de problèmes à prendre en compte.

Ce post décompose ces problèmes en un processus logique étape par étape pour en examinant l'accessibilité d'un site existant.

Commencer avec le clavier

Pour les utilisateurs qui ne peuvent pas ou qui choisissent de ne pas utiliser une souris, la navigation au clavier est le principal moyen d’atteindre tout ce qui est à l’écran. Cette audience comprend : les utilisateurs souffrant de troubles moteurs, tels qu'une blessure due au stress répétitif (RSI) ; ou paralysie, ainsi que des utilisateurs de lecteurs d'écran.

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

  • Commencez par parcourir votre site à l'aide de la touche de tabulation. Ordre dans lequel les éléments sont sélectionnés doit suivre l'ordre DOM. Si vous n'êtes pas sûr des éléments à recevoir consultez le module consacré à l'accessibilité dans le cours consacré à l'accessibilité. Le meilleur est que tout contrôle avec lequel un utilisateur peut interagir ou fournir des données doit pouvoir être sélectionné et afficher un indicateur de mise au point (une bague de mise au point, par exemple).

  • Les commandes interactives personnalisées doivent être sélectionnables. Si vous utilisez JavaScript pour transformer un <div> dans un menu déroulant, il n'est pas automatiquement inséré dans le ordre de tabulation. Pour rendre une commande personnalisée sélectionnable, attribuez-lui un tabindex="0". Les valeurs tabindex supérieures à 0 modifient l'ordre de tabulation et peuvent prêter à confusion pour pour les utilisateurs de lecteurs d'écran.

  • Ne rendez que le contenu interactif sélectionnable. Ajout de tabindex aux entités non- les éléments interactifs comme les en-têtes ralentissent les utilisateurs du clavier, qui peuvent voir l'écran et n'aide pas les utilisateurs de lecteurs d'écran, car le lecteur d'écran sait déjà les annoncer.

  • Si vous ajoutez du nouveau contenu à une page, dirigez l'utilisateur vers ce contenu afin de pouvoir prendre des mesures le concernant. Voir Gérer la concentration au niveau de la page pour obtenir des exemples.

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

Faites en sorte que votre contrôle de la mise au point soit utilisable

Si vous avez créé une commande personnalisée, permettez à vos utilisateurs d'accéder à toutes ses fonctionnalités en utilisant uniquement le clavier. Lue Gérer la focalisation sur les composants des techniques pour améliorer l’accès au clavier.

Gérer le contenu hors écran

De nombreux sites comportent du contenu hors écran présent dans le DOM, mais non visible, comme des liens dans un menu de panneau responsive ou un bouton dans une fenêtre modale qui n'a pas encore été affichée. Si vous laissez ces éléments dans le DOM, expérience de clavier déroutante, en particulier pour les lecteurs d'écran, qui annoncer 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 compatibilité générale du clavier jette les bases pour l'étape suivante, qui est de vérifier que l'étiquetage et la sémantique de la page sont corrects, et qu'il n'y a pas d'obstacle la navigation avec un lecteur d'écran.

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

  • Vérifiez que le texte alt de toutes les images est correct. L'exception à cette pratique est les images sont principalement à des fins de présentation et ne sont pas des éléments essentiels contenus. Pour indiquer que les lecteurs d'écran doivent ignorer une image, définissez la valeur en une chaîne vide: alt="".
  • Cochez toutes les commandes pour voir ce libellé. Pour les commandes personnalisées, il peut être nécessaire utilisation de aria-label ou aria-labelledby. Voir Étiquettes et relations ARIA pour obtenir des exemples.
  • Vérifiez tous les contrôles personnalisés pour un role approprié et tout ARIA requis. qui communiquent leur état. Par exemple, une case à cocher personnalisée doit role="checkbox" et aria-checked="true|false" pour transmettre correctement de l'état. Reportez-vous à la section Introduction à ARIA pour obtenir des informations générales présentation de la manière dont ARIA peut fournir une sémantique manquante pour les commandes personnalisées.
  • Donnez un sens au flux d'informations sur votre page. Parce que l'écran les lecteurs naviguent sur la page dans l'ordre DOM, ils annoncent tous les éléments que vous avez repositionné visuellement à l'aide de CSS dans un ordre absurde. Si vous avez besoin pour qu'un élément apparaisse plus tôt sur la page, déplacez-le physiquement plus tôt dans le DOM.
  • Essayez de permettre la navigation avec le lecteur d'écran pour tout le contenu de la page. Assurez-vous que aucune section du site n'est définitivement masquée ni bloquée à l'écran. en lecture seule.
    • Si le contenu devrait être masqué par un lecteur d'écran, par exemple s'il est hors écran ou simplement de présentation, définissez ce contenu sur aria-hidden="true". Pour en savoir plus, consultez Masquage de contenu :

Se familiariser avec les lecteurs d'écran

Bien qu’il puisse sembler intimidant d’apprendre à utiliser un lecteur d’écran, il est en fait assez facile à utiliser. En général, la plupart des développeurs s'en sortent avec quelques étapes simples commandes clavier.

Si vous utilisez un Mac, regardez cette vidéo sur VoiceOver, le lecteur d'écran fourni avec Mac OS. Si vous utilisez un PC, consultez cette vidéo sur NVDA un lecteur d'écran open source soumis à un don pour Windows.

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

Il est important de comprendre que l'algorithme ARIA ne peut influer que sur la sémantique d'une element; cela n'a aucun effet sur le comportement de l'élément. Vous pouvez faire un élément masqué pour les lecteurs d'écran avec aria-hidden="true", mais qui ne l'est pas ; modifier le comportement de sélection de cet élément. Pour le contenu interactif hors écran, Pour le contenu interactif hors écran, utilisez l'attribut inert. pour vous assurer qu'il est vraiment supprimé du flux du clavier. Pour les navigateurs plus anciens, combiner aria-hidden="true" avec tabindex="-1".

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

Fournir des indices visuels, ou affordances, sur ce qu'un contrôle fera aide une grande variété de personnes, sur une grande variété d'appareils, utilisent et naviguent dans votre sur votre site.

  • Les éléments interactifs, comme les liens et les boutons, doivent se distinguer des des éléments non interactifs. Il est difficile pour les utilisateurs de naviguer sur un site ou une application lorsque ils ne peuvent pas savoir si un élément est cliquable. Il existe de nombreuses façons valides de indiquer des éléments interactifs. Une pratique courante consiste à souligner les liens vers les différencier du texte environnant.
  • Semblables à l'exigence de focus, les éléments interactifs comme les liens et les boutons ont besoin d'un état hover pour indiquer aux utilisateurs de la souris que leur pointeur est sur un élément cliquables. Cependant, 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 en-têtes et les points de repère donnent une structure sémantique à votre page. augmenter considérablement l'efficacité de la navigation des utilisateurs de technologies d'assistance. Beaucoup les utilisateurs de lecteurs d'écran signalent que, lorsqu'ils accèdent pour la première fois à une page inconnue, ils essaient généralement de parcourir les titres.

De même, les lecteurs d'écran permettent d'accéder directement à des points de repère importants. comme <main> et <nav>. C'est pourquoi il est important de considérer la structure de votre page peut être utilisée pour guider l'expérience de l'utilisateur.

  • Utilisez la hiérarchie h1-h6. Considérez les en-têtes comme des outils permettant de créer un plan 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 qu'ils utilisent le niveau sémantique approprié pour le contenu primaire, secondaire et tertiaire. Utilisez ensuite le CSS en-têtes correspondent à votre conception.
  • Utilisez des rôles et des éléments de repère afin que les utilisateurs puissent contourner les contenus répétitifs. Beaucoup les 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 point de repère implicites. Vous pouvez également utiliser l'attribut role ARIA pour définir explicitement des régions sur la page, comme dans <div role="search">. Voir Sémantique et navigation dans les contenus pour en savoir plus exemples.
  • Évitez d'utiliser role="application", sauf si vous avez l'habitude de l'utiliser. Le rôle de point de repère application indique à la technologie d'assistance de désactiver sa les raccourcis clavier et passer toutes les pressions sur les touches jusqu'à la page. Cela signifie que les clés les lecteurs d'écran que les utilisateurs de lecteurs d'écran utilisent généralement pour se déplacer sur la page ne fonctionnent plus, et vous devrez implémenter vous-même toutes la gestion du clavier.

Examiner les en-têtes et les points de repère avec un lecteur d'écran

Les lecteurs d'écran, comme VoiceOver et NVDA, proposent un menu contextuel pour passer les régions les plus importantes sur la page. Lorsque vous testez l'accessibilité, vous pouvez utiliser ces menus pour avoir un aperçu de la page et déterminer si votre titre sont appropriés et quels points de repère sont utilisés.

Pour en savoir plus, visionnez ces vidéos pédagogiques sur les bases 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, car autant que possible. Vous pouvez utiliser les extensions de navigateur et l'accessibilité par ligne de commande des suites de tests.

  • La page réussit-elle tous les tests de l'une des méthodes aXe ou WAVE des extensions de navigateur ? D'autres options sont disponibles, mais ces extensions peuvent être un ajout utile à tout processus de test manuel, car ils peuvent repérer les problèmes subtils, comme les rapports de contraste et les éléments ARIA manquants .
    • Si vous préférez travailler avec la ligne de commande, axe-cli fournit les mêmes fonctionnalités en tant qu'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égrer une bibliothèque comme axe-core à votre suite de tests automatisés. axe-core est le moteur qui alimente le l'extension Chrome aXe, mais dans un utilitaire de ligne de commande.
  • Si vous utilisez un framework ou une bibliothèque, offre-t-il sa propre solution d'accessibilité ? outils ? Par exemple, protractor-accessibility-plugin pour Angular. Tirez parti des outils disponibles autant que possible.

Utiliser Lighthouse pour tester les PWA

Lighthouse est un outil 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 problèmes d'accessibilité dans votre rapport. Corrigez les erreurs pour améliorer l'expérience utilisateur globale de sur votre site.

Ressources supplémentaires