Accessibilité pour les développeurs Web

Améliorer l'accessibilité de votre site rend votre site plus accessible à tous.

Il est important de créer des sites inclusifs et accessibles à tous. Vous pouvez optimiser au moins six domaines clés du handicap : le visuel, l'ouïe, la mobilité, la cognition, la voix et le neural. De nombreux outils et ressources peuvent vous aider, même si vous débutez dans l'accessibilité Web.

Plus d'un milliard de personnes vivent avec un handicap.

Pour être accessibles, les sites doivent fonctionner sur plusieurs appareils avec des tailles d'écran différentes et différents types d'entrées, tels que des lecteurs d'écran. De plus, les sites doivent être utilisables par le plus grand groupe d'utilisateurs, y compris les personnes handicapées.

Voici quelques handicaps que vos utilisateurs peuvent avoir:

Les problèmes visuels peuvent aller de l'incapacité à distinguer les couleurs ou encore de l'absence totale de vision.

• Assurez-vous que le contenu textuel atteint un seuil minimal de rapport de contraste.
• Évitez de communiquer des informations en n'utilisant que la couleur et assurez-vous que tout le texte est resizable.
• Assurez-vous que tous les composants de l'interface utilisateur peuvent être utilisés avec des technologies d'assistance telles que les lecteurs d'écran, les loupes et les plages braille. Cela implique de s'assurer que les composants de l'interface utilisateur sont balisés de sorte que les API d'accessibilité puissent déterminer de manière automatisée le rôle, l'état, la valeur et le titre de n'importe quel élément.

Personnellement, je vis avec une déficience visuelle et je me retrouve souvent à zoomer sur des sites, leurs outils de développement et le terminal. Bien que la prise en charge du zoom ne figure presque jamais en tête des listes de tâches des développeurs, elle peut faire toute la différence pour des utilisateurs comme moi.

Les problèmes auditifs signifient qu'un utilisateur peut avoir des difficultés à entendre le son émis par une page.

• Fournissez des alternatives textuelles pour tous les contenus qui ne sont pas strictement textuels.
• Vérifiez que vos composants d'interface utilisateur fonctionnent toujours sans le son.

Les problèmes de mobilité peuvent inclure l'impossibilité d'utiliser une souris, un clavier ou un écran tactile.

• Rendez le contenu de vos composants d'interface utilisateur accessible de manière fonctionnelle à partir d'un clavier pour toutes les actions pour lesquelles vous utiliseriez la souris autrement.
• Assurez-vous que les pages sont correctement balisées pour les technologies d'assistance (y compris les lecteurs d'écran, les logiciels de commande vocale et les commandes de commutation physiques) qui ont tendance à utiliser les mêmes API.

Les problèmes cognitifs signifient qu'un utilisateur peut avoir besoin de technologies d'assistance pour l'aider à lire du texte. Il est donc important de s'assurer que des alternatives textuelles existent.

• Soyez prudent lorsque vous utilisez des animations. Évitez les vidéos et les animations qui répétent ou clignotent, car elles peuvent causer des problèmes à certains utilisateurs.

  La requête média CSS prefers-reduced-motion vous permet de limiter les animations et la lecture automatique des vidéos pour les utilisateurs qui préfèrent réduire les mouvements:

  /*
  If the user expresses a preference for reduced motion, don't use animations on buttons.
  */
  @media (prefers-reduced-motion: reduce) {
    button {
      animation: none;
    }
  }
  

• Évitez les interactions basées sur le temps.

Cela peut sembler beaucoup de bases à aborder, mais nous allons parcourir le processus d'évaluation, puis d'amélioration de l'accessibilité de vos composants d'interface utilisateur.

Pour une aide visuelle supplémentaire, l'équipe Accessibilité de GOV.UK a créé une série d'affiches numériques à faire et à ne pas faire concernant l'accessibilité, que vous pouvez utiliser pour partager les bonnes pratiques avec votre équipe.

Mesurer l'accessibilité des composants d'UI

Lorsque vous vérifiez l'accessibilité des composants d'interface utilisateur de votre page, posez-vous les questions suivantes:

• Est-il possible d'utiliser le composant d'interface utilisateur uniquement avec le clavier ?

  Le composant permet-il de gérer la mise au point et d'éviter les pièges de sélection ? Est-il capable de répondre aux événements de clavier appropriés ?

• Pouvez-vous utiliser votre composant d'interface utilisateur avec un lecteur d'écran ?

  Avez-vous fourni des alternatives au texte pour toute information présentée visuellement ? Avez-vous ajouté des informations sémantiques à l'aide d'ARIA ?

• Votre composant d'interface utilisateur peut-il fonctionner sans le son ?

  Éteignez vos enceintes et consultez vos cas d'utilisation.

• Votre composant d'interface utilisateur peut-il fonctionner sans couleur ?

  Assurez-vous que votre composant d'interface utilisateur peut être utilisé par une personne qui ne voit pas les couleurs. L'extension Chrome Colordly est un outil utile pour simuler les daltonismes. (Essayez les quatre formes de simulation de daltonisme disponibles.) L'extension Daltonize peut également vous intéresser. Elle est également utile.

• Votre composant d'interface utilisateur peut-il fonctionner si le mode Contraste élevé est activé ?

  Tous les systèmes d'exploitation modernes prennent en charge le mode contraste élevé. L'extension Contraste élevé est une extension Chrome qui peut vous aider dans ce cas de figure.

L'accessibilité est intégrée au navigateur pour les commandes standardisées (telles que <button> et <select>). Ils sont sélectionnables à l'aide de la touche Tab, répondent aux événements de clavier (comme Enter, Space et les touches fléchées) et possèdent des rôles sémantiques, des états et des propriétés utilisés par les outils d'accessibilité. Leur style par défaut doit également respecter les exigences d'accessibilité indiquées.

Les composants d'interface utilisateur personnalisés (à l'exception des composants qui étendent les éléments standards tels que <button>) n'ont pas de fonctionnalités intégrées, y compris l'accessibilité. Vous devez donc les fournir. Pour implémenter l'accessibilité, un bon point de départ consiste à comparer votre composant à un élément standard analogue (ou à une combinaison de plusieurs éléments standards, selon la complexité de votre composant).

La plupart des outils pour les développeurs de navigateurs permettent d'inspecter l'arborescence d'accessibilité d'une page. Dans les outils pour les développeurs Chrome, cette option est disponible dans l'onglet Accessibilité du panneau Éléments.

Firefox dispose également d'un panneau Accessibilité.

Safari expose des informations d'accessibilité dans l'onglet Nœud du panneau Éléments.

Voici une liste de questions que vous pouvez vous poser lorsque vous essayez de rendre vos composants d'interface utilisateur plus accessibles.

Améliorer la sélection au clavier

Idéalement, assurez-vous que toutes les fonctionnalités de votre composant d'interface utilisateur sont accessibles avec un clavier. Lors de la conception de votre expérience utilisateur, réfléchissez à la manière dont vous utiliseriez votre élément avec le clavier uniquement et trouvez un ensemble cohérent d'interactions avec le clavier.

Tout d'abord, assurez-vous d'avoir une cible pertinente pour chaque composant. Par exemple, un composant complexe tel qu'un menu peut être une cible de sélection dans une page, mais il doit ensuite gérer le curseur en lui-même de sorte que l'élément de menu actif le soit toujours.

Utiliser tabindex

Vous pouvez ajouter le ciblage au clavier pour des éléments et des composants d'interface utilisateur avec l'attribut tabindex. Les utilisateurs de technologies d'assistance et de clavier uniquement doivent pouvoir placer le curseur sur les éléments du clavier pour interagir avec eux.

Les éléments interactifs intégrés (tels que <button>) sont implicitement sélectionnables. Ils n'ont donc pas besoin d'attribut tabindex, sauf si vous devez modifier leur position dans l'ordre de tabulation.

Il existe trois types de valeurs tabindex:

• tabindex="0" est le plus courant et place l'élément dans l'ordre de tabulation naturel (défini par l'ordre DOM).
• Une valeur tabindex supérieure à 0 place l'élément dans un ordre de tabulation manuel. Tous les éléments de la page ayant une valeur tabindex positive sont consultés dans l'ordre numérique, avant les éléments selon l'ordre de tabulation naturel.
• Une valeur tabindex égale à -1 permet de programmer l'élément, mais pas dans l'ordre de tabulation.

Pour les composants d'interface utilisateur personnalisés, utilisez toujours des valeurs tabindex de 0 ou -1, car vous ne pourrez pas déterminer à l'avance l'ordre des éléments d'une page donnée. Une valeur tabindex de -1 est particulièrement utile pour gérer la sélection au sein de composants complexes.

Assurez-vous que le focus est toujours visible, que ce soit en utilisant le style de l'anneau de sélection par défaut ou en appliquant un style de focus personnalisé et visible. N'oubliez pas de ne pas piéger les utilisateurs du clavier. Ils doivent pouvoir éloigner le curseur d'un élément en n'utilisant que le clavier.

Utiliser l'autofocus (mise au point automatique)

L'attribut HTML autofocus permet à un auteur de spécifier qu'un élément particulier doit automatiquement être sélectionné lors du chargement de la page. autofocus est déjà compatible avec toutes les commandes de formulaire Web, y compris les boutons. Pour effectuer une mise au point automatique des éléments de vos propres composants d'interface utilisateur personnalisés, appelez la méthode focus(), compatible avec tous les éléments HTML pouvant être sélectionnés (par exemple, document.querySelector('myButton').focus()).

Ajouter une interaction avec le clavier

Une fois que votre composant d'interface utilisateur est sélectionnable, fournissez une bonne histoire d'interaction avec le clavier lorsqu'un composant est sélectionné, en gérant les événements de clavier appropriés. Par exemple, autorisez l'utilisateur à utiliser les touches fléchées pour sélectionner les options du menu et Space ou Enter pour activer les boutons. Le guide des modèles de conception ARIA fournit quelques conseils ici.

Enfin, assurez-vous que vos raccourcis clavier sont visibles. Une pratique courante consiste à ajouter une légende de raccourci clavier (texte à l'écran) pour informer l'utilisateur que des raccourcis existent. Par exemple, "Appuyez sur ? pour les raccourcis clavier. » Un conseil de ce type peut également être utilisé pour informer l'utilisateur d'un raccourci.

L'importance de la concentration ne peut pas être surestimée. Un exemple important est un panneau de navigation. Si vous ajoutez un composant d'interface utilisateur à la page, vous devez vous concentrer sur un élément qu'elle contient. Sinon, les utilisateurs devront peut-être parcourir toute la page à l'aide de la touche de tabulation pour y accéder. Cette expérience peut être frustrante. Veillez donc à tester le ciblage de tous les composants navigables au clavier de votre page.

// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

Garantir une utilisation réussie du lecteur d'écran

Environ 1% à 2% des personnes utilisent un lecteur d'écran. Pouvez-vous comprendre toutes les informations importantes et interagir avec le composant en utilisant uniquement le lecteur d'écran et le clavier ?

Les questions suivantes devraient vous aider à aborder l'accessibilité des lecteurs d'écran.

Tous les composants et toutes les images ont-ils des alternatives au texte significatives ?

Chaque fois que des informations sur le nom ou l'objectif d'un composant interactif sont transmises visuellement, fournissez une alternative textuelle accessible.

Par exemple, si votre composant d'interface utilisateur <fancy-menu> n'affiche qu'une icône en forme de roue dentée pour indiquer qu'il s'agit d'un menu de paramètres, il a besoin d'une alternative au texte accessible, telle que "settings", qui véhicule les mêmes informations. Selon le contexte, vous pouvez fournir une alternative textuelle à l'aide d'un attribut alt, d'un attribut aria-label, d'un attribut aria-labelledby ou de texte brut dans Shadow DOM. Vous trouverez des conseils techniques généraux dans le Guide de référence rapide de WebAIM.

Tout composant d'interface utilisateur qui affiche une image doit fournir un mécanisme permettant de fournir un texte alternatif pour cette image, semblable à l'attribut alt.

Vos composants fournissent-ils des informations sémantiques ?

La technologie d'assistance transmet des informations sémantiques qui sont autrement exprimées aux utilisateurs voyants à l'aide de repères visuels, tels que la mise en forme, le style du curseur ou la position. Les éléments standardisés intègrent ces informations sémantiques dans le navigateur. Toutefois, pour les composants personnalisés, vous devez utiliser ARIA afin d'ajouter ces informations.

En général, tout composant qui écoute un événement de clic de souris ou de survol doit avoir une sorte d'écouteur d'événements au clavier et un rôle ARIA, éventuellement des états et des attributs ARIA.

Par exemple, un composant d'interface utilisateur <fancy-slider> personnalisé peut prendre le rôle ARIA de curseur, lequel est associé à certains attributs ARIA: aria-valuenow, aria-valuemin et aria-valuemax. En liant ces attributs aux propriétés pertinentes de votre composant personnalisé, vous pouvez permettre aux utilisateurs de technologies d'assistance d'interagir avec l'élément, de modifier sa valeur et même de modifier la présentation visuelle de l'élément en conséquence.

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

Les utilisateurs peuvent-ils tout comprendre sans se fier aux couleurs ?

La couleur ne doit pas être utilisée comme le seul moyen de transmettre des informations, par exemple pour indiquer un état, demander une réponse à l'utilisateur ou visualiser des données. Par exemple, si vous avez un graphique à secteurs, fournissez des étiquettes et des valeurs pour chaque secteur afin que les utilisateurs ayant une déficience visuelle puissent comprendre les informations, même s'ils ne peuvent pas voir où commencent et se terminent les secteurs:

Le contraste est-il suffisant ?

Tout contenu textuel affiché dans votre composant doit respecter le seuil minimal de contraste au niveau de l'AA des WCAG. Envisagez de fournir un thème à contraste élevé qui respecte le seuil AAA plus élevé et assurez-vous que les feuilles de style user-agent peuvent être appliquées si les utilisateurs ont besoin d'un contraste personnalisé ou de couleurs différentes. Vous pouvez utiliser le vérificateur de contraste de couleurs comme aide lors de la conception de votre composant.

Le contenu en mouvement ou qui clignote peut-il être arrêté et sans danger ?

Les utilisateurs doivent pouvoir mettre en pause, arrêter ou masquer les contenus qui se déplacent, défilent ou clignotent pendant plus de cinq secondes. En règle générale, évitez de flasher du contenu.

Si un élément doit clignoter, veillez à ce qu'il ne clignote pas plus de trois fois par seconde.

Outils et tests d'accessibilité

Il existe plus de 100 outils pour évaluer l'accessibilité de votre site et de ses composants. Certains outils sont automatisés, tandis que d'autres nécessitent des tests manuels.

En voici quelques-unes à prendre en compte:

• Axe fournit des tests d'accessibilité automatisés pour le framework ou le navigateur de votre choix. Axe Pupppeteer permet d'écrire des tests d'accessibilité automatisés.

• Un audit de l'accessibilité Lighthouse fournit des insights utiles pour identifier les problèmes d'accessibilité courants. Le score d'accessibilité est une moyenne pondérée de tous les audits d'accessibilité basée sur les évaluations de l'impact sur les utilisateurs d'Axe. Pour surveiller l'accessibilité avec l'intégration continue, consultez la section CI Lighthouse.

  

• Tenon.io est utile pour tester les problèmes d'accessibilité courants. Tenon est parfaitement compatible avec l'intégration des outils de compilation, des navigateurs (via les extensions) et même des éditeurs de texte.

• Il existe de nombreux outils propres à une bibliothèque et à un framework pour mettre en évidence les problèmes d'accessibilité à l'aide des composants. Par exemple, utilisez eslint-plugin-jsx-a11y pour mettre en évidence les problèmes d'accessibilité des composants React dans votre éditeur.

  

  Si vous utilisez Angular, codelyzer propose également des audits d'accessibilité intégrés à l'éditeur:

  

Travailler avec des technologies d'assistance

• Vous pouvez examiner la façon dont les technologies d'assistance voient le contenu Web à l'aide de l'Accessibility Inspector (Mac) ou des outils de test de l'API Windows Automation et d'AccProbe (Windows). Vous pouvez également afficher l'arborescence d'accessibilité complète créée par Chrome en accédant à about://accessibility.
• Le meilleur moyen de tester la compatibilité du lecteur d'écran sur un Mac consiste à utiliser l'utilitaire VoiceOver. Utilisez ⌘F5 pour l'activer ou le désactiver, Ctrl+Option ←→ pour vous déplacer dans la page et Ctrl+Shift+Option + ↑↓ pour vous déplacer vers le haut et le bas de l'arborescence d'accessibilité. Pour obtenir des instructions plus détaillées, consultez la liste complète des commandes VoiceOver et la liste des commandes VoiceOver pour le Web.

• Sous Windows, NVDA est un lecteur d'écran Open Source sans frais. La phase d'apprentissage est toutefois raide pour les personnes voyantes.

  

• ChromeOS dispose d'un lecteur d'écran intégré.

Nous avons un long chemin à parcourir pour améliorer l'accessibilité sur le Web. D'après l'article Web Almanac:

• 4 sites sur cinq affichent du texte qui se fond dans l'arrière-plan, ce qui le rend illisible.
• 49,91% des pages ne fournissent toujours pas d'attributs alt pour certaines images.
• Seules 24% des pages qui utilisent des boutons ou des liens incluent des libellés.
• Seules 22,33% des pages proposent des libellés pour toutes les entrées de formulaire.

Nous pouvons faire beaucoup de choses pour créer des expériences plus accessibles à tous.