Accessibilité pour les développeurs Web

En améliorant l'accessibilité de votre site, vous le rendez plus accessible à tous.

Addy Osmani

Il est important de créer des sites inclusifs et accessibles à tous. Il existe au moins six domaines de handicap clés pour lesquels vous pouvez optimiser: visuel, audition, mobilité, cognition, parole et neurone. De nombreux outils et ressources peuvent vous aider, même si vous débutez dans l'accessibilité Web.

Plus d'un milliard de personnes vivre avec une forme de handicap.

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

Voici quelques-uns des handicaps que vos utilisateurs peuvent souffrir:

Les problèmes visuels vont de l'incapacité à distinguer les couleurs au manque de vision.

• Assurez-vous que le contenu textuel respecte seuil du rapport de contraste.
• Évitez de communiquer des informations en utilisant uniquement la couleur et s'assurer que tout le texte est redimensionnable.
• S'assurer que tous les composants de l'interface utilisateur peuvent être utilisés avec les technologies d'assistance comme 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 afin que les API d'accessibilité puissent déterminer de manière programmatique Les rôles role, state, value et title de n'importe quel élément.

Je vis personnellement 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 soit presque jamais la partie supérieure des développeurs des listes de tâches, il peut faire toute la différence pour des utilisateurs comme moi.

Les problèmes d'audition signifient que les utilisateurs ont parfois du mal à entendre le son émis depuis une page.

• Fournissez autres textes pour tous les contenus qui ne sont pas strictement textuels.
• Tester le fonctionnement des composants de l'interface utilisateur sans le son.

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

• Rendre le contenu des composants de l'interface utilisateur fonctionnellement accessibles à partir d'un clavier pour toutes les actions pour lesquelles vous utiliseriez autrement la souris.
• S'assurer que les pages sont correctement balisées pour les technologies d'assistance, y compris des lecteurs d'écran, un logiciel de commande vocale et des commandes physiques qui permettent ont tendance à utiliser les mêmes API.

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

• Soyez prudent lorsque vous utilisez des animations. Évitez les vidéos et les animations répéter ou flash, ce qui peut entraîner des problèmes pour certains utilisateurs.

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

  /*
  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é sur le temps.

Cela peut sembler beaucoup de bases à couvrir, mais nous suivrons le processus d'évaluation puis améliorer l'accessibilité de vos composants d'UI.

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

</ph>

Mesurer l'accessibilité des composants d'interface utilisateur

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

• Pouvez-vous utiliser votre composant d'interface utilisateur avec le clavier uniquement ?

  Le composant gère-t-il la mise au point et évite-t-il les pièges de mise au point ? Peut-il 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 textuelles pour les informations présentées 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 passez en revue 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 peut pas voir les couleurs. Un outil utile pour simuler le daltonisme est une extension Chrome appelée Daltonisme. (Essayez les quatre formes de simulation du daltonisme disponibles.) Vous pourriez également être intéressé par Daltoniser qui est tout aussi utile.

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

  Tous les systèmes d'exploitation modernes prennent en charge un mode de contraste élevé. Contraste élevé est une extension Chrome qui peut vous aider.

Les commandes standardisées (<button> et <select>, par exemple) ont une accessibilité intégrés au navigateur. Ils peuvent être sélectionnés à l'aide de la clé Tab. ils répondent aux événements du clavier (comme Enter, Space et les touches fléchées) ; ainsi que des rôles, états et propriétés sémantiques utilisés par les outils d'accessibilité. Leur style par défaut doit également répondre aux exigences d'accessibilité indiquées.

Composants d'interface utilisateur personnalisés (à l'exception des composants qui étendent les fonctionnalités des éléments tels que <button>) n'ont pas de fonctionnalités intégrées, y compris l'accessibilité, vous devez donc la fournir. Un bon point de départ lorsque l'implémentation de l'accessibilité consiste à comparer votre composant à une norme similaire (ou une combinaison de plusieurs éléments standard, selon la complexité 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 comporte également un panneau Accessibilité.

Safari présente les informations d'accessibilité dans l'onglet Elements du panneau Elements.

Voici une liste de questions que vous pouvez vous poser lorsque vous tentez de rendre les composants de votre interface utilisateur plus accessibles.

Améliorer le focus au clavier

Idéalement, assurez-vous que toutes les fonctionnalités du composant d'UI sont accessibles à l'aide d'un clavier. Lors de la conception de votre expérience utilisateur, réfléchissez à la façon dont vous utiliseriez votre élément avec le clavier seul et à déterminer un ensemble cohérent d'interactions au clavier.

Tout d'abord, assurez-vous d'avoir défini une cible pertinente pour chaque composant. Par exemple, un composant complexe tel qu'un menu peut être l'une des cibles d'une mais doit ensuite gérer le focus en elle-même afin que l'élément de menu actif est toujours au centre de l'attention.

</ph>

Utiliser l'index de tabulation

Vous pouvez sélectionner des éléments et des composants d'interface utilisateur au clavier avec tabindex . Les utilisateurs se servant uniquement d'un clavier et de technologies d'assistance doivent pouvoir placer le curseur sur les éléments pour interagir avec eux.

Les éléments interactifs intégrés (comme <button>) sont implicitement sélectionnables. ils n'ont pas besoin d'un 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'onglet naturel (défini par l'ordre DOM).
• Si la valeur de tabindex est égale à -1, l'élément est programmatique. sélectionnable, mais pas dans l'ordre de tabulation.
• Une valeur tabindex supérieure à 0 place l'élément dans un ordre de tabulation manuel. Tous les éléments de la page dont la valeur tabindex est positive sont consultés dans l’ordre numérique, avant les éléments dans l’ordre de tabulation naturel.

Consultez quelques cas d'utilisation de tabindex dans l'article Utiliser tabindex

Assurez-vous que le curseur est toujours visible, que vous utilisiez l'anneau de mise au point par défaut ou en appliquant un style de focus personnalisé visible. Pensez à ne pas piéger utilisateurs de claviers : ils doivent pouvoir éloigner le focus d'un élément en utilisant uniquement le clavier.

Utiliser l'autofocus (mise au point automatique)

L'attribut de mise au point automatique HTML permet à un auteur de spécifier qu'une doit automatiquement être sélectionné lors du chargement de la page. autofocus est déjà pris en charge sur tous les contrôles de formulaire Web, y compris les boutons. Pour effectuer une mise au point automatique des éléments dans vos propres composants d'interface utilisateur personnalisés, procédez comme suit : 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 le composant d'interface utilisateur est sélectionnable, fournissez une histoire intéressante 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 des options de menu. et Space ou Enter pour activer les boutons. Le guide des modèles de conception ARIA fournit quelques conseils.

Enfin, assurez-vous que vos raccourcis clavier sont visibles. Une pratique courante consiste à avoir une légende de raccourci clavier (texte à l'écran) pour informer l'utilisateur de l'existence de raccourcis. Par exemple, "Appuyez sur ? pour clavier les raccourcis clavier. » Un indice, une info-bulle, peut aussi être utilisé pour informer l'utilisateur sur un raccourci.

L'importance de la gestion de la concentration ne saurait être trop soulignée. Voici un exemple important : un panneau de navigation. Si vous ajoutez un composant d'interface utilisateur à la page, vous devez vous concentrer sur un élément qu'il contient ; sinon les utilisateurs devront peut-être naviguer sur la page entière pour y accéder. Cela peut être une expérience frustrante, Veillez donc à tester le focus de tous les composants navigables au clavier de la 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`);

Assurez-vous que le lecteur d'écran est utilisé correctement

Environ 1 à 2 % des personnes utilisent un lecteur d'écran. Comprenez-vous tous les informations et interagir avec le composant à l'aide du lecteur d'écran et du clavier seul ?

Les questions suivantes devraient vous aider à aborder l'accessibilité du lecteur d'écran.

Tous les composants et les images proposent-ils des alternatives textuelles pertinentes ?

Où que vous soyez, les informations sur le nom ou l'objectif d'un composant interactif est transportée visuellement, fournir une alternative textuelle accessible.

Par exemple, si le 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 textuelle accessible, telle que « paramètres », qui transmet les mêmes informations. Selon le contexte, vous pouvez fournir une alternative textuelle à l'aide d'un attribut alt. un attribut aria-label, un attribut aria-labelledby ou en texte brut dans le Shadow DOM. Vous trouverez des conseils techniques généraux dans le guide de référence rapide 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 à les utilisateurs voyants avec des repères visuels, tels que la mise en forme, le style du curseur ou la position. Le navigateur intègre ces informations sémantiques aux éléments standardisés, mais pour les composants personnalisés, vous devez utiliser ARIA pour ajouter les informations

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

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

</ph>

<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 à la couleur ?

La couleur ne doit pas être utilisée comme le seul moyen de transmettre des informations, par exemple indiquer un état, inviter l'utilisateur à répondre ou visualiser des données. Par exemple, si vous disposez d'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 finissent les tranches:

</ph>

Le contraste est-il suffisant ?

Le contenu textuel affiché dans votre composant doit respecter les seuil minimal de contraste de niveau AA pour les WCAG. Envisagez de proposer un thème à contraste élevé qui répond aux seuil AAA plus élevé, et veiller à ce que les feuilles de style user-agent si les utilisateurs ont besoin d’un contraste personnalisé ou de couleurs différentes. Vous pouvez utiliser le Vérificateur de contraste des couleurs comme une aide lors de la conception de votre composant.

Le déplacement ou le clignotement du contenu est-il bloqué et sécurisé ?

Les utilisateurs doivent pouvoir mettre en pause, arrêter ou masquer le contenu qui se déplace, défile ou clignote pendant plus de cinq secondes. En règle générale, évitez de flasher du contenu.

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

Outils d'accessibilité et tests

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

En voici quelques-uns à prendre en considération:

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

• Une accessibilité phare l'audit fournit des informations 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é grâce aux évaluations d'impact sur les utilisateurs Axe. Pour surveiller l'accessibilité avec l'intégration continue, consultez Lighthouse CI.

  

• Tenon.io est utile pour tester les problèmes d'accessibilité courants. Tenon offre une compatibilité étendue avec les outils de développement, les navigateurs (via des extensions), et même des éditeurs de texte.

• Il existe de nombreux outils spécifiques aux bibliothèques et aux frameworks pour mettre en avant les problèmes d'accessibilité avec les composants. Par exemple, utilisez eslint-plugin-jsx-a11y pour signaler les problèmes d'accessibilité des composants React dans votre éditeur.

  

  Si vous utilisez Angular, codelyzer propose également des audits d'accessibilité dans l'éditeur:

  

Travailler avec des technologies d'assistance

• Vous pouvez examiner la façon dont les technologies d'assistance voient le contenu Web en utilisant Accessibility Inspector (Mac) ou Outils de test de l'API Windows Automation et 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é avec les lecteurs d'écran sur un Mac est d'utiliser VoiceOver utilitaire. Utilisez ⌘F5 pour l'activer ou le désactiver, Ctrl+Option ←→ pour passer de l'une à l'autre la page, et Ctrl+Shift+Option + ↑↓ pour monter et descendre dans la arborescence. Pour obtenir des instructions plus détaillées, consulter la liste complète des commandes VoiceOver et la liste des commandes Web VoiceOver.

• Sous Windows, NVDA est un écran Open Source sans frais en lecture seule. Cependant, la phase d'apprentissage est ardue pour les personnes voyantes.

  

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

Nous avons beaucoup à faire pour améliorer l'accessibilité sur le Web. Conformément à l'almanach Web:

• 4 sites sur 5 comportent du texte qui se fond dans l'arrière-plan, les rendant illisibles.
• 49,91% des pages ne fournissent toujours pas d'attribut alt pour certaines de leurs images.
• Seulement 24% des pages qui utilisent des boutons ou des liens incluent des libellés.
• Seules 22,33% des pages fournissent des étiquettes pour toutes les entrées de formulaire.

Nous pouvons faire beaucoup pour créer des expériences plus accessibles aux tout le monde.