Améliorer l'accessibilité rend votre site plus utilisable pour tous.
Il est important de créer des sites inclusifs et accessibles à tous. Vous pouvez optimiser votre site pour au moins six types de handicaps : visuel, auditif, mobilité, cognition, parole et neurologique. De nombreux outils et ressources peuvent vous aider, même si vous n'avez jamais travaillé sur 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 de saisie, tels que les lecteurs d'écran. De plus, les sites doivent être utilisables par le plus grand nombre d'utilisateurs, y compris les personnes ayant un handicap.
Voici quelques exemples de handicaps que vos utilisateurs peuvent avoir:
| Vision | Audition | Mobilité |
|---|---|---|
|
|
|
| Cognitive | Voix | Neuronal |
|
|
|
Les problèmes visuels vont de l'incapacité à distinguer les couleurs à l'absence totale de vision.
- Assurez-vous que le contenu textuel répond à un seuil minimal de rapport de contraste.
- Évitez de communiquer des informations uniquement à l'aide de la couleur et assurez-vous que tout le texte est redimensionnable.
- 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 écrans braille. Cela implique de s'assurer que les composants d'interface utilisateur sont marqués de sorte que les API d'accessibilité puissent déterminer de manière programmatique le rôle, l'état, la valeur et le titre de n'importe quel élément.
Personnellement, je suis malvoyant et je me retrouve souvent à faire un zoom avant sur les sites, leurs outils de développement et le terminal. Bien que la prise en charge du zoom ne figure presque jamais en haut de la liste de tâches des développeurs, elle peut faire toute la différence pour des utilisateurs comme moi.
Les problèmes d'audition peuvent empêcher un utilisateur d'entendre le son émis par une page.
- Fournissez des alternatives textuelles pour tout contenu qui n'est pas strictement textuel.
- Vérifiez que vos composants d'interface utilisateur fonctionnent toujours sans 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 fonctionnellement accessible depuis un clavier pour toutes les actions pour lesquelles une souris serait normalement utilisée.
- Assurez-vous que les pages sont correctement marquées pour les technologies d'assistance, y compris les lecteurs d'écran, les logiciels de commande vocale et les commandes de contact physique, qui ont tendance à utiliser les mêmes API.
En raison de problèmes cognitifs, un utilisateur peut avoir besoin de technologies d'assistance pour 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 qui se répètent ou clignotent, car cela peut entraîner des problèmes pour certains utilisateurs.
La requête multimédia CSS
prefers-reduced-motionvous permet de limiter les animations et les vidéos en lecture automatique pour les utilisateurs qui préfèrent une réduction du mouvement:/* 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 à couvrir, mais nous allons vous expliquer le processus d'évaluation et d'amélioration de l'accessibilité de vos composants d'UI.
Pour une aide visuelle supplémentaire, l'équipe chargée de l'accessibilité de GOV.UK a créé une série de affiches numériques sur les bonnes pratiques et les erreurs à éviter en matière d'accessibilité, que vous pouvez utiliser pour partager les bonnes pratiques avec votre équipe.
Mesurer l'accessibilité des composants d'interface utilisateur
Lorsque vous effectuez un audit de 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 le focus et évite-t-il les pièges de focus ? 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 son ?
Éteignez vos enceintes et examinez vos cas d'utilisation.
Votre composant d'interface utilisateur peut-il fonctionner sans couleur ?
Assurez-vous que votre composant d'UI peut être utilisé par une personne qui ne voit pas les couleurs. Une extension Chrome appelée Colorblindly est un outil utile pour simuler le daltonisme. (Essayez les quatre formes de simulation de daltonisme disponibles.) L'extension Daltonize, qui est tout aussi utile, peut également vous intéresser.
Votre composant d'UI peut-il fonctionner avec le mode Contraste élevé activé ?
Tous les systèmes d'exploitation modernes sont compatibles avec un mode Contraste élevé. L'extension Chrome Contraste élevé peut vous aider.
Les commandes standardisées (telles que <button> et <select>) sont intégrées au navigateur. Ils peuvent être sélectionnés à l'aide de la touche Tab. Ils répondent aux événements de clavier (comme les touches Enter, Space et les flèches). Ils ont des rôles, des états et des 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.
Les composants d'interface utilisateur personnalisés (à l'exception des composants qui étendent des éléments standards tels que <button>) ne disposent d'aucune fonctionnalité intégrée, y compris l'accessibilité. Vous devez donc la fournir. Un bon point de départ pour l'implémentation de l'accessibilité consiste à comparer votre composant à un élément standard analogue (ou à une combinaison de plusieurs éléments standards, en fonction de 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 information est disponible dans l'onglet Accessibilité du panneau Éléments.
Firefox propose également un panneau Accessibilité.
Safari affiche les informations d'accessibilité dans l'onglet Nœud du panneau Éléments.
Vous trouverez ci-dessous 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
Dans l'idéal, assurez-vous que toutes les fonctionnalités de votre composant d'UI sont accessibles avec un clavier. Lorsque vous concevez votre expérience utilisateur, réfléchissez à la façon dont vous utiliseriez votre élément avec le clavier seul et déterminez un ensemble cohérent d'interactions avec le clavier.
Tout d'abord, assurez-vous d'avoir une cible de focus appropriée pour chaque composant. Par exemple, un composant complexe tel qu'un menu peut être une cible de focus sur une page, mais doit ensuite gérer le focus en lui-même afin que l'élément de menu actif soit toujours en focus.
Utiliser tabindex
Vous pouvez ajouter la sélection au clavier pour les éléments et les composants d'interface utilisateur avec l'attribut tabindex. Les utilisateurs se servant uniquement d'un clavier et des technologies d'assistance doivent pouvoir placer le focus du clavier sur les éléments pour interagir avec eux.
Les éléments interactifs intégrés (comme <button>) peuvent être sélectionnés de manière implicite. Ils n'ont donc pas besoin d'un attribut tabindex, sauf si vous devez modifier leur position dans l'ordre des onglets.
Il existe trois types de valeurs tabindex:
tabindex="0"est l'option la plus courante et place l'élément dans l'ordre naturel des onglets (défini par l'ordre DOM).- Une valeur
tabindexégale à -1 permet de mettre l'élément en surbrillance de manière programmatique, mais pas dans l'ordre des onglets. - Une valeur
tabindexsupérieure à 0 place l'élément dans un ordre de tabulation manuel. Tous les éléments de la page avec une valeurtabindexpositive sont visités dans l'ordre numérique, avant les éléments dans l'ordre naturel des onglets.
Découvrez quelques cas d'utilisation de tabindex dans l'article Utiliser tabindex.
Assurez-vous que le focus est toujours visible, que ce soit en utilisant le style d'anneau de mise au point par défaut ou en appliquant un style de mise au point personnalisé distinctif. N'oubliez pas de ne pas piéger les utilisateurs de clavier. Ils doivent pouvoir déplacer la sélection depuis un élément en utilisant uniquement le clavier.
Utiliser l'autofocus (mise au point automatique)
L'attribut autofocus HTML permet à un auteur de spécifier qu'un élément particulier doit automatiquement être sélectionné lorsque la page est chargée.
autofocus est déjà compatible avec toutes les commandes de formulaire Web, y compris les boutons.
Pour mettre au point automatiquement des éléments dans vos propres composants d'interface utilisateur personnalisés, appelez la méthode focus(), compatible avec tous les éléments HTML pouvant être mis au point (par exemple, document.querySelector('myButton').focus()).
Ajouter une interaction avec le clavier
Une fois que votre composant d'interface utilisateur peut être sélectionné, fournissez une bonne expérience 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 des boutons.
Le guide des modèles de conception ARIA fournit des conseils à ce sujet.
Enfin, assurez-vous que vos raccourcis clavier sont visibles. Il est courant d'inclure une légende de raccourcis clavier (texte à l'écran) pour informer l'utilisateur de l'existence de raccourcis. (par exemple, "Appuyez sur ? pour les raccourcis clavier." Vous pouvez également utiliser une info-bulle pour informer l'utilisateur d'un raccourci.
L'importance de gérer la concentration ne peut être surestimée. Un exemple important est un panneau de navigation. Si vous ajoutez un composant d'interface utilisateur à la page, vous devez diriger la sélection vers un élément de celui-ci. Sinon, les utilisateurs devront peut-être parcourir toute la page à l'aide de la touche Tabulation pour y accéder. Cela peut être une expérience frustrante. Veillez donc à tester la sélection pour tous les composants de votre page pouvant être parcourus au clavier.
// 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`);
Assurer une utilisation réussie du lecteur d'écran
Environ 1% à 2% des utilisateurs utilisent un lecteur d'écran. Pouvez-vous comprendre toutes les informations importantes et interagir avec le composant à l'aide du lecteur d'écran et du clavier uniquement ?
Les questions suivantes devraient vous aider à résoudre les problèmes d'accessibilité des lecteurs d'écran.
Tous les composants et toutes les images sont-ils associés à des textes alternatifs pertinents ?
Lorsque des informations sur le nom ou l'objectif d'un composant interactif sont transmises visuellement, fournissez un texte alternatif 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 doit comporter 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, d'un attribut aria-label, d'un attribut aria-labelledby ou de texte brut dans le DOM fantôme.
Vous trouverez des conseils techniques généraux dans la référence rapide WebAIM.
Tout composant d'UI qui affiche une image doit fournir un mécanisme permettant de fournir un texte alternatif pour cette image, analogue à l'attribut alt.
Vos composants fournissent-ils des informations sémantiques ?
Les technologies d'assistance transmettent des informations sémantiques qui sont autrement exprimées aux utilisateurs voyants à l'aide de repères visuels, tels que le formatage, 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 les ajouter.
En général, tout composant qui écoute un clic de souris ou un événement de survol doit disposer d'un écouteur d'événements de clavier et d'un rôle ARIA, ainsi que d'états et d'attributs ARIA.
Par exemple, un composant d'UI <fancy-slider> personnalisé peut prendre le rôle ARIA de curseur, qui comporte des attributs ARIA associés: aria-valuenow, aria-valuemin et aria-valuemax.
En associant ces attributs aux propriétés pertinentes de votre composant personnalisé, vous pouvez autoriser les utilisateurs de technologies d'assistance à interagir avec l'élément, à modifier sa valeur et même à 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 s'appuyer sur la couleur ?
La couleur ne doit pas être le seul moyen de transmettre des informations, comme indiquer un état, inviter l'utilisateur à répondre ou visualiser des données. Par exemple, si vous utilisez un graphique circulaire, fournissez des libellés et des valeurs pour chaque segment afin que les utilisateurs ayant une déficience visuelle puissent comprendre les informations, même s'ils ne peuvent pas voir où les segments commencent et se terminent:
Le contraste est-il suffisant ?
Tout contenu textuel affiché dans votre composant doit respecter le seuil de contraste minimal de niveau AA WCAG. Envisagez de fournir un thème à contraste élevé qui répond au seuil AAA le plus élevé et assurez-vous que les feuilles de style de l'agent utilisateur peuvent être appliquées si les utilisateurs ont besoin d'un contraste personnalisé ou de couleurs différentes. Vous pouvez utiliser cet outil de vérification du contraste des couleurs pour vous aider à concevoir votre composant.
Le contenu en mouvement ou clignotant peut-il être arrêté et est-il sûr ?
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 les contenus clignotants.
Si un élément doit clignoter, assurez-vous qu'il ne clignote pas plus de trois fois par seconde.
Outils et tests d'accessibilité
Plus de 100 outils sont disponibles 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.
Voici quelques exemples:
- Axe fournit des tests d'accessibilité automatisés pour votre framework ou votre navigateur de choix. Axe Puppeteer peut être utilisé pour écrire des tests d'accessibilité automatisés.
Un audit d'accessibilité Lighthouse fournit des insights utiles pour découvrir les problèmes d'accessibilité courants. Le score d'accessibilité est une moyenne pondérée de tous les audits d'accessibilité en fonction des évaluations de l'impact sur l'utilisateur. Pour surveiller l'accessibilité avec l'intégration continue, consultez la section Intégration continue Lighthouse.
Tenon.io est utile pour tester les problèmes d'accessibilité courants. Tenon offre une intégration efficace entre les outils de compilation, les navigateurs (via des extensions) et même les éditeurs de texte.
De nombreux outils spécifiques aux bibliothèques et aux frameworks permettent de mettre en évidence les problèmes d'accessibilité 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 fournit également des audits d'accessibilité dans l'éditeur:
Fonctionner avec les technologies d'assistance
- Vous pouvez examiner la façon dont les technologies d'assistance voient le contenu Web à l'aide de l'outil d'accessibilité (Mac), des outils de test des API d'automatisation Windows et de 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 vérifier la compatibilité avec un lecteur d'écran sur un Mac est d'utiliser l'utilitaire VoiceOver. Utilisez
⌘F5pour l'activer ou la désactiver,Ctrl+Option ←→pour parcourir la page etCtrl+Shift+Option + ↑↓pour monter et descendre dans 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 Web. Sous Windows, NVDA est un lecteur d'écran Open Source et sans frais. Cependant, la courbe d'apprentissage est abrupte pour les utilisateurs voyants.
ChromeOS dispose d'un lecteur d'écran intégré.
Nous avons encore un long chemin à parcourir pour améliorer l'accessibilité sur le Web. D'après l'Almanach Web:
- Quatre sites sur cinq comportent du texte qui se fond dans l'arrière-plan, ce qui les rend illisibles.
- 49,91% des pages ne fournissent toujours pas d'attributs
altpour certaines de leurs images. - Seules 24% des pages qui utilisent des boutons ou des liens incluent des libellés.
- Seules 22,33% des pages fournissent des libellés pour toutes les entrées de formulaire.
Nous pouvons faire beaucoup pour créer des expériences plus accessibles pour tous.