4 problèmes courants d'accessibilité du Web à connaître

Problème de rapport de contraste

Le problème d'accessibilité le plus courant que j'ai constaté au fil des ans est celui de la problème de contraste et d'accessibilité des couleursUn mauvais rapport de contraste rendra le contenu de votre page difficile à voir, ce qui sera très préjudiciable à vos utilisateurs, y compris à ceux qui souffrent d'un handicap visuel.

Le contraste est une mesure de la différence de "luminance" ou de luminosité perçue entre deux couleurs. Il s'agit par exemple de la différence entre la couleur d'arrière-plan et la couleur de premier plan du contenu de votre page. Examinons cette barre de navigation.

Disons que votre client aime beaucoup cette couleur verdâtre et la trouve géniale, mais qu'il y a un problème de contraste. Nous avons un #FFFFFF en arrière-plan avec un #83A94C La couleur du texte donne un rapport de contraste de 2,71:1, ce qui est bien en dessous du minimum requis. 4.5:1 nécessaire. Pour détecter ce problème, nous disposons de plusieurs solutions :

1. Utilisez un vérificateur de contraste en ligne comme le Vérificateur de contraste Webaimqui calculera le rapport de contraste et vous donnera une valeur de Passez ou Échec grade.
2. Utilisez l'une des nombreuses extensions de contrôle de contraste du navigateur, par exemple : WCAG Contrôleur de contraste des couleurs.
3. Essayez le vérificateur de contraste intégré au navigateur. Pour l'utiliser sur Google Chrome, ouvrez les outils de développement, inspectez l'élément ciblé (ex : le lien Home de notre navbar), allez à la propriété de couleur CSS, et cliquez sur le rectangle de couleur pour ouvrir le sélecteur de couleur, en bas, vous serez présenté avec une valeur de ratio de contraste, développez-la pour plus de détails. Le processus est exactement le même pour Firefox, il y a juste une petite différence dans le ratio affiché en bas à gauche du sélecteur de couleurs.

Pour plus d'informations sur les contrastes, consultez le site suivant Article sur l'accessibilité des contrastes et des couleurs.

Problème de texte de lien

De nos jours, les liens occupent une place importante sur le web, et il est donc très important de les rendre accessibles. Un lien doit avoir un sens et informer l'utilisateur de son contexte. Un lien non informatif avec un texte comme "en savoir plus", "cliquez ici", "vérifiez les détails" n'est pas très utile. produit Par exemple, l'utilisation du nom du produit tel que "Le casque du Mandalorien" est plus efficace et plus informatif. Des mots comme cliquez ici ou plus d'informations peut être omis parce qu'un lien est cliquable par défaut et que quelque chose comme "en savoir plus sur les nouvelles du jour" peut être raccourci en "nouvelles du jour". Il n'y a pas de règle ou de limite particulière concernant la longueur des liens. le lien doit être lisible et suffisamment longue pour donner une bonne description de son objectif.

Les images en tant que liens sont un modèle très répandu, qui doit donc suivre les mêmes règles que celles dont nous avons parlé plus haut. L'attribut alt de l'image jouera le rôle de texte de lien et sera annoncé par les lecteurs d'écran. Si l'image est le seul contenu du lien, elle doit avoir un attribut alt. Si le lien contient du texte et une image, on peut omettre l'attribut alt :

<a href="/fr/notifications/">
  <img src="/img/notification.png" alt="Notifications">
</a>

Consultez quelques liens ici pour en savoir plus sur l'accessibilité des liens :Texte et apparence des liens, Images fonctionnelles.

Étiquette manquante dans une entrée de formulaire

Nous avons tous déjà vu ces entrées de formulaire sans étiquette et avec juste un espace réservé pour décrire le but de l'entrée. Une première remarque est que dès que l'utilisateur remplit toutes les entrées et que les espaces réservés ne sont plus visibles, nous n'aurons plus de contexte visuel sur l'objectif des entrées, mais concentrons-nous sur l'accessibilité ici.

Associer un étiquette à une entrée présente deux avantages majeurs : un lecteur d'écran lira l'étiquette lorsque l'utilisateur se concentre sur l'entrée du formulaire et, lorsqu'une étiquette est cliquée ou touchée, le navigateur transfère le focus à l'entrée associée. Pour remédier à ce genre de situation, il suffit d'ajouter des étiquettes comme suit :

    Prénom

    
  

    Nom de famille

    
  

    Courriel

    
  

    Soumettre
  

```

Voilà, toutes les entrées ont leurs étiquettes associées, ce qui les rend accessibles à tout le monde. Nous pouvons même supprimer les espaces réservés pour éviter de dupliquer l'objectif de l'entrée, mais nous savons tous que les scénarios du monde réel ne sont pas si faciles à gérer, vous venez de recevoir une conception qui a ces entrées de formulaire sans étiquettes et le client ne veut pas changer cette partie. La première solution qui vient à l'esprit est d'appliquer un affichage : aucun ; ou visibilité : cachée ; à nos étiquettes, cela les cachera mais elles sont toujours là, n'est-ce pas ? Ces propriétés cachent des éléments non seulement à l'écran, mais aussi pour les utilisateurs de lecteurs d'écran, ce qui ne résoudra pas notre problème.

Nous pouvons utiliser le modèle de clip pour résoudre ce problème. De cette manière, nous masquerons le contenu visuellement, tout en fournissant le contenu aux lecteurs d'écran. Nous allons créer le CSS suivant sr-only et l'appliquer à toutes nos étiquettes :

 .sr-only:not(:focus):not(:active) {
   clip : rect(0 0 0 0) ;
   clip-path : inset(50%) ;
   height : 1px ;
   overflow : hidden ;
   position : absolute ;
   white-space : nowrap ;
   width : 1px ;
 }

Cela permettra de masquer nos étiquettes, de les rendre accessibles aux lecteurs d'écran et de les faire correspondre à notre design. Les :not(:focus):not(:active) La pseudo-classe empêche les éléments focalisables tels que a, bouton, entrée d'être caché lorsqu'il reçoit la focalisation.

Pas d'indicateur de mise au point

Il fut un temps où je faisais cela dans ma feuille de style CSS globale :

* {
outline : none ; /* horrible erreur */
}

Vers 2020, j'ai remarqué que des bordures noires apparaissaient sur les entrées de formulaire de Google Chrome lorsqu'elles étaient focalisées ou sur les boutons lorsqu'on y accédait par la tabulation - c'était vraiment bizarre car je ne le comprenais pas à l'époque. Après quelques recherches, j'ai découvert que c'était dû à la propriété CSS outline, ce qui a permis de résoudre ce "problème" pour moi.

À l'époque, je n'avais aucune idée de la manière correcte de procéder. Après quelques recherches sur le pourquoi et le comment de cette nouvelle valeur par défaut, j'ai découvert que le contour est un indicateur de mise au point de l'élément et que s'il est supprimé, un style de mise au point évident doit être fourni ; en fait, ce que je faisais est considéré comme une mauvaise pratique. Vous pouvez personnaliser les indicateurs de mise au point comme bon vous semble, mais les supprimer complètement du site web pose un gros problème d'accessibilité. Il est assez facile, par exemple, de personnaliser le style de mise au point d'un élément :

<a:focus {
   outline : 4px solid #ee7834 ;
   outline-offset : 4px ;
 }

Outils d'accessibilité

Vérifier tous les points dont nous avons parlé peut représenter beaucoup de travail, surtout si l'on sait qu'il y a encore beaucoup de choses à couvrir en matière d'accessibilité. Pour nous aider à gérer l'accessibilité, nous avons deux excellentes extensions de navigateur.

Outil d'évaluation WAVE est une suite d'outils d'évaluation qui nous aide à rendre notre contenu web plus accessible. Il est disponible dans Google Chrome et Firefox.

Essayons-le sur une petite page web contenant une barre de navigation et une entrée sans étiquette et voyons ce qu'il renvoie. Après avoir installé l'extension, il suffit de cliquer sur l'icône de l'extension pour l'utiliser.

L'onglet Résumé montre 1 erreur (élément de formulaire sans étiquette), 2 erreurs de contraste et 1 alerte (structure d'en-tête manquante), comme vous pouvez le voir, le résultat est très clair et détaillé. L'onglet Détails affiche une liste de toutes les erreurs, alertes et caractéristiques. Nous pouvons également interagir directement sur la page en cliquant sur ces rectangles rouges pour vérifier la description et le type d'erreur.

Axe DevTools est une boîte à outils d'accessibilité puissante et précise. Il est disponible dans Google Chrome et Firefox. Après avoir installé l'extension, nous devrons ouvrir les outils de développement du navigateur et aller dans l'onglet DevTools de l'axe et cliquer sur Scanner toutes mes pages.

Vous pouvez voir qu'Axe DevTools a signalé les mêmes problèmes avec l'outil d'évaluation WAVE, à savoir des problèmes de contraste, des éléments de formulaire sans étiquette et des éléments d'en-tête manquants, et nous a même donné quelques bonnes pratiques à suivre.

Un autre moyen de tester l'accessibilité est d'utiliser un lecteur d'écran et de tester votre site web avec lui. Il existe de nombreux lecteurs d'écran, pour n'en citer que quelques-uns :

• NVDA
• VoiceOver est disponible sur les appareils MacOs.
• Orque est un lecteur d'écran libre et gratuit pour linux.

Résumé

Nous avons vu dans cet article quelques problèmes courants d'accessibilité du web, les moyens de les résoudre et quelques outils formidables pour tester l'accessibilité du web. Il reste encore beaucoup à faire en matière d'accessibilité pour des éléments tels que les dialogues, les accordéons et les carrousels, mais comme vous l'avez vu dans cet article, il existe beaucoup de documentation et d'outils pour vous aider à gérer l'accessibilité.

Quelques points clés à retenir :

• Vérifiez toujours le rapport de contraste.
• Fournissez toujours un contenu informatif aux liens.
• Un élément de formulaire doit être associé à une étiquette.
• Un style de focalisation évident doit être fourni.