7 erreurs courantes en matière d'accessibilité (et comment les éviter)

Il y a de fortes chances que vous ayez déjà entendu parler de digital accessibility, et vous savez qu'il est important d'optimiser votre produit en ligne pour les personnes handicapées. Il est compréhensible que vous vous sentiez submergé par toutes les informations et les tâches à accomplir pour améliorer votre produit. Vous avez peut-être conclu que c'est tellement compliqué qu'il vous faut engager un expert pour faire le travail. Pourtant, vous vous sentez concerné ! Vous ne savez tout simplement pas comment commencer.

Ne vous inquiétez pas, résoudre ou éviter ces problèmes ne prend souvent pas beaucoup de temps ! À condition de savoir où chercher et quoi faire à la place. Au cours de mes années de travail en tant que développeur web et ingénieur en logiciels frontaux, j'ai rencontré de nombreux problèmes d'accessibilité. Souvent, ils se résument à la même série de points. Dans la plupart des cas, une approche axée sur l'accessibilité ne prend pas beaucoup de temps. Ce n'est pas plus difficile ou plus cher. Il s'agit de faire son travail quotidien avec un état d'esprit différent qui améliore considérablement l'accessibilité.

Mais passons maintenant aux choses sérieuses : laissez-moi vous expliquer quels sont les problèmes d'accessibilité les plus courants et, surtout, comment les éviter.

Erreur 1 : balisage sémantique médiocre

Éviter les problèmes d'accessibilité ne nécessite pas de travail supplémentaire. Il faut simplement travailler différemment

L'une des erreurs les plus couramment commises et dont les conséquences sont malheureusement majeures est un mauvais balisage sémantique. Si vous connaissez un peu le langage HTML, vous savez peut-être qu'une page se compose d'éléments définis par balises HTML, par exemple <h1> et <p>. La majorité des éléments sont sémantiques : ils décrivent clairement leur signification d'une manière lisible par l'homme et par la machine.

Si vous consultez la source d'une page web, vous remarquerez un grand nombre d'éléments <div> et <span> ; il s'agit d'éléments non sémantiques. Il s'agit d'éléments non sémantiques. Ces éléments sont des conteneurs génériques qui n'attribuent aucune signification à leur contenu.

Les lecteurs d'écran s'appuient fortement sur le HTML sémantique. Ils forment un arbre d'accessibilité basé sur la sémantique de la page. L'utilisateur d'un lecteur d'écran peut passer d'un élément à l'autre en utilisant des raccourcis. Il sait quels sont les boutons, quels sont les titres, où se trouve la navigation, comment les informations de la page sont liées à d'autres éléments de la page, etc.

Surutilisation d'éléments non sémantiques

Si vous utilisez des éléments <div> et <span> à la place d'un élément sémantique, des informations essentielles sont instantanément perdues. Les utilisateurs souffrant d'une déficience visuelle ne peuvent pas comprendre la structure du site web sur la base de ce qu'ils voient. Ils ne peuvent pas voir les boutons ou le menu de navigation. La page web devient un gros tas de contenu non structuré. Pire encore, les éléments interactifs, tels que les boutons, deviennent souvent complètement inutilisables. En surfant sur le web, je rencontre souvent des éléments <span> contrôlés par JavaScript, présentés comme des boutons. Le JavaScript est écrit pour être activé par un clic de souris. Cela fonctionne bien pour tous ceux qui peuvent utiliser une souris, mais il est impossible de le contrôler au moyen d'un clavier, et il est souvent impossible pour un utilisateur de lecteur d'écran de le trouver.

Conseil : utiliser le HTML sémantique

Si cela ressemble à un bouton et se comporte comme un bouton, cela doit être un bouton.

Mon conseil pour éviter ce comportement indésirable n'est probablement pas une surprise : utilisez autant que possible les éléments HTML sémantiques appropriés. Les seuls cas où vous devriez utiliser les éléments <div> et <span> sont ceux où il n'y a pas d'autre élément disponible pour transmettre le sens. Cela se résume généralement à des fins décoratives uniquement.

L'utilisation d'éléments sémantiques augmente de manière exponentielle l'accessibilité de votre page web. En effet, ces éléments contiennent des informations destinées au navigateur sur la manière dont ils doivent être utilisés. En outre, en tant que développeur ou ingénieur, vous gagnerez du temps. Vous n'avez pas besoin de penser à imiter le comportement d'un bouton, par exemple, parce qu'il fonctionne déjà de cette manière.

Utiliser les mauvais éléments sémantiques

Une autre erreur fréquente dans cette catégorie consiste à choisir le mauvais élément sémantique. C'est souvent le résultat du choix d'un élément pour son apparence plutôt que pour son comportement ou son objectif. Peut-être n'avez-vous pas utilisé un <button> natif parce que vous le trouviez laid. Ou peut-être avez-vous sauté quelques niveaux d'en-tête et choisi un <h4> au lieu d'un <h2>, parce que vous aimiez le fait que la taille de la police soit plus petite. Ce n'est pas la bonne façon de procéder ; nous avons le CSS pour cela.

Conseil : choisissez un élément pour sa signification

Utilisez les éléments HTML pour structurer votre contenu en fonction de la signification de chaque élément et non de son apparence. Appliquez ensuite des styles à votre convenance à l'aide de CSS.

Conseil : utiliser des outils automatisés

Un bon moyen de vous aider avec la sémantique est d'utiliser un outil de validation HTML. Certains outils incluent cela dans les tests d'accessibilité automatisés, tels que axe Tools. N'oubliez pas que les outils automatisés ne peuvent pas tout tester et qu'ils comportent souvent des faux positifs et des faux négatifs. Mais ils peuvent vous aider à repérer rapidement des erreurs que vous auriez pu négliger. La meilleure solution consiste à combiner les tests automatisés et manuels pour l'accessibilité.

Erreur 2 : étiquettes de formulaire mal structurées

Si cela ressemble à un bouton et se comporte comme un bouton, c'est qu'il doit s'agir d'un bouton.

Cette erreur a également beaucoup à voir avec le HTML sémantique. Ne vous y trompez pas : la conception et la mise en œuvre d'un formulaire utilisable, accessible et esthétique est un véritable défi !

Le formulaire de connexion d'Easy LMS. Les étiquettes se déplacent vers le haut lorsque vous remplissez un champ du formulaire, de sorte qu'elles restent visibles.

L'entrée et l'étiquette ne sont pas liées

Chaque formulaire comporte un champ de saisie et une étiquette décrivant ce champ de saisie. Par exemple, j'ai trois champs de saisie : "Nom", "Adresse électronique" et "Société". Je pourrais ajouter les noms au-dessus des entrées en texte brut (par exemple à l'intérieur d'un élément <span>). Malheureusement, un utilisateur de lecteur d'écran trouvera trois entrées de texte vides sans indication de ce qu'il doit remplir.

Conseil : associer l'étiquette et l'entrée

L'utilisation d'éléments HTML sémantiques pour les étiquettes est déjà une bonne chose, mais si vous voulez vraiment aider vos utilisateurs, vous devriez également pair your label and input. Le navigateur sait désormais que ces deux éléments vont de pair. Chez Easy LMS, nous dirions : profit !

Utilisation d'attributs de remplacement en tant qu'étiquettes

Une autre erreur d'accessibilité consiste à omettre les étiquettes et à utiliser à la place des placeholder attributes sur les entrées. Il s'agit d'une mauvaise pratique pour plusieurs raisons. Tout d'abord, de nombreuses technologies d'assistance n'y ont pas accès. Deuxièmement, dès qu'un utilisateur saisit une entrée (ou remplit automatiquement le formulaire), les étiquettes disparaissent. Il est difficile de vérifier si le formulaire ne contient pas d'erreurs. Enfin, un espace réservé est conçu comme un indice supplémentaire, et non comme une étiquette.

Conseil : Ne remplacez pas une étiquette par un espace réservé

N'omettez jamais les étiquettes dans un formulaire. Si vous devez le faire, n'utilisez des espaces réservés que pour fournir des indications supplémentaires aux utilisateurs (voyants) dans les formulaires. Mieux encore : n'utilisez pas du tout d'attributs de remplacement et veillez à ce que les informations importantes concernant le formulaire soient accessibles à tous.

Erreur 3 : Utiliser des liens non descriptifs

Combien de fois avez-vous rencontré des liens disant "cliquez ici", ou "lisez plus", ou "allez sur cette page" ? À mon avis, plus que vous ne pouvez en compter ! L'une des raisons pour lesquelles il s'agit d'une mauvaise pratique est qu'elle ne permet pas de comprendre l'objectif du lien en dehors de son contexte. Grâce aux technologies d'assistance, les utilisateurs peuvent naviguer rapidement parmi les liens d'une page. Imaginez qu'un lecteur d'écran vous communique ce qui suit : "Ici, lien. En savoir plus, lien. Cette page, lien". Cela ne vous dit pas grand-chose, n'est-ce pas ?

Conseil : inclure le sujet de la page dans le lien

Comment éviter cela ? Dans la plupart des cas, il suffit d'inclure le sujet ou le titre de la page à laquelle vous faites référence dans le lien. Laissez-moi vous donner un exemple : vous pouvez en savoir plus sur different types of disabilities dans cet article du W3C. Le lecteur d'écran va maintenant communiquer : "différents types de handicaps, lien". Profitez-en !

Conseil : optimiser les liens répétés

J'imagine que vous ne voudriez pas inclure le titre dans chaque lien "Lire la suite" sous une liste d'articles. Cela encombre beaucoup la page. Il existe un certain nombre de different approaches on how to make "read more" links accessible, et le cas d'utilisation diffère de celui qui conviendrait le mieux. Sur l'aperçu de ce blog, nous avons choisi d'optimiser les liens pour les lecteurs d'écran en ajoutant un aria-label qui inclut le titre de l'article.

Erreur 4 : Se fier aux images comme seul moyen de transmission de l'information

En tant que penseur visuel, je sais à quel point il est plus facile de comprendre quelque chose à partir d'une image qu'en lisant un texte. Je ne prétends pas que l'utilisation d'images pour expliquer ou se référer à une explication est mauvaise. En fait, j'encourage tout le monde à utiliser des images de cette manière, car pour certaines déficiences (comme la dyslexie), cela améliore réellement l'accessibilité. Cependant, l'utilisation d'images comme seul moyen de transmettre l'information est une mauvaise pratique.

Au niveau mondial, environ 43 millions de personnes sont aveugles et environ 295 millions de personnes ont une déficience visuelle modérée à sévère. Ce chiffre n'inclut pas seulement la cécité totale, mais aussi, par exemple, la perte de la vision centrale ou périphérique et la vision floue. Si vous dépendez d'images pour expliquer votre point de vue, vous risquez qu'une grande partie de l'information échappe à une partie de votre public.

Captures d'écran

Un exemple concret de ce problème est l'explication de l'utilisation d'une interface à l'aide de captures d'écran. Le texte dit simplement : "cliquez sur le bouton indiqué sur la capture d'écran" ou "établissez votre configuration comme indiqué sur la capture d'écran suivante". Sans ces images, il est impossible de savoir ce qu'il faut faire avec ces instructions. Si l'on considère que ce type d'articles se trouve souvent dans des banques de connaissances, des documentations ou des tutoriels, la situation est encore plus problématique.

Exemple de capture d'écran de notre centre d'aide. Le texte d'accompagnement de l'article d'aide se lit comme suit : Vous pouvez ajuster les paramètres de votre catégorie de laissez-passer en sélectionnant "Modifier".

Conseil : votre texte doit être compréhensible sans images

Votre public doit pouvoir comprendre les informations sans les images. Avec des instructions à la fois sous forme de texte et d'images, votre lecteur peut choisir la manière dont il préfère prendre l'information ou dispose d'une solution de repli en cas de déficience. Une astuce que j'utilise personnellement consiste à rédiger le texte dans son ensemble et à ajouter les images par la suite, comme je l'ai fait pour cet article de blog. Ainsi, je ne risque pas d'omettre une information parce qu'elle était visible sur une image pendant que j'écrivais.

Absence de texte alternatif

Souvent, les images informatives que vous trouverez sur les sites web ont un texte alternatif médiocre ou n'en ont pas du tout. L'objectif du texte alternatif est de décrire l'image pour les utilisateurs de lecteurs d'écran. Si ce texte est vide, les utilisateurs de lecteurs d'écran ne sauront pas ce que contient l'image ou s'ils ont manqué une information importante.

Conseil : ajouter des textes alternatifs aux images fonctionnelles et informatives

Le texte alternatif sera communiqué à un utilisateur qui ne peut pas voir l'image (correctement). J'encourage tout le monde à ne pas les ignorer mais à ajouter un clear descriptive alternative text pour l'image. Cela peut être fait dans le code source. Dans un CMS, il existe souvent un champ de saisie dédié à cet effet.

Conseil : traiter différemment les images décoratives pour les lecteurs d'écran

Parfois, les images ne sont ajoutées qu'à titre décoratif pour rendre une page plus attrayante sur le plan visuel. Dans d'autres cas, il est préférable que les images soient entièrement ignorées par un lecteur d'écran. Il existe différentes approches sur la manière de traiter les textes alternatifs en fonction de l'objectif de l'image.

Texte dans les images

Le texte dans les images n'est pas non plus compréhensible pour les personnes souffrant de déficience visuelle. Vous seriez surpris de constater la quantité de texte qui se trouve dans les images (il suffit de regarder n'importe quelle plateforme de médias sociaux). Encore une fois, ce n'est pas mauvais en soi, mais assurez-vous d'ajouter le texte dans une description ou comme texte alternatif.

Erreur 5 : Mauvais contraste des couleurs

Choisir un élément HTML en fonction de sa signification et non de son apparence

Le texte à faible contraste est le problème d'accessibilité le plus souvent détecté par les tests automatisés menés par WebAIM. Ce problème ne concerne pas seulement les personnes souffrant de basse vision, mais aussi les personnes souffrant de déficience de la vision des couleurs (différentes sortes de daltonisme). Environ 1 homme sur 12 et 1 femme sur 200 présentent un certain degré de déficience de la vision des couleurs. Certaines personnes n'en sont même pas conscientes. Si vous regardez l'image ci-dessous, quel chiffre voyez-vous ?

Which number do you see? Image source

Si vous voyez 74, votre vision des couleurs est normale. Si vous voyez 21 ou aucun chiffre, vous souffrez peut-être d'un déficience de la vision des couleurs rouge-vert. Dans ce cas, vous avez peut-être rencontré des sites web dont certaines parties étaient difficiles à lire.

Dans les WCAG un Success Criterion est défini lorsque le contraste entre le texte et son arrière-plan est suffisamment élevé pour que les personnes ayant une vision modérément basse puissent le lire. Les directives de WCAG sont classées en trois niveaux de conformité. Chez Easy LMS, nous visons le niveau AA. Ces rapports de contraste sont de 4,5:1 pour le petit texte et de 3:1 pour le grand texte.

Conseil : utilisez un outil pour vérifier le contraste des couleurs

Comment savoir si le contraste du texte est suffisant ? Il existe de nombreux outils de contraste des couleurs que vous pouvez utiliser pour effectuer des tests sur votre page web. Vous pouvez également tester le contraste des couleurs manuellement en saisissant les codes de couleur de l'avant-plan et de l'arrière-plan dans un vérificateur de contraste en ligne.

Conseil : utiliser des tons plus foncés ou plus clairs d'une couleur.

L'un des problèmes qui se posent souvent est que les couleurs utilisées dans l'interface utilisateur correspondent à celles du logo de la marque. Cela peut rendre le problème difficile à résoudre, car les couleurs donnent l'impression de faire partie de l'identité de la marque. Une bonne pratique consiste à utiliser une nuance plus foncée ou plus claire de la couleur souhaitée pour améliorer le contraste. Nous avons ajusté les couleurs d'Easy LMS pour cette raison il y a quelques années !

L'utilisation de la couleur comme seul moyen de transmission de l'information

J'ai évoqué plus haut les problèmes liés à l'utilisation d'images comme seul moyen de transmission de l'information. Il en va de même pour les couleurs. Les couleurs rouge et verte sont souvent utilisées comme seul moyen d'informer sur les états de réussite et d'erreur. Malheureusement, le daltonisme rouge-vert est le type de daltonisme le plus courant. Pour les utilisateurs concernés, le rouge et le vert se ressemblent.

Conseil : prévoir plusieurs moyens de communiquer les états

Vous pouvez toujours utiliser le rouge et le vert à ces fins, mais veillez à toujours prévoir un autre moyen de communiquer les états, tel que du texte, des formes différentes ou des icônes (étiquetées).

Erreur 6 : Ne pas fournir d'indication visuelle de l'objectif actuel

La plupart des utilisateurs naviguent sur leur ordinateur à l'aide d'un dispositif de pointage, tel qu'une souris ou un trackpad sur un ordinateur portable. Sur les appareils mobiles, nous utilisons nos doigts sur un écran tactile. Pour certains utilisateurs, cela est difficile ou impossible en raison de leur handicap. Il peut s'agir par exemple d'une paralysie, d'une partie du corps manquante, d'arthrite ou de microtraumatismes répétés. Dans ces cas, les utilisateurs utilisent souvent un clavier ou un autre dispositif d'entrée capable d'imiter le comportement d'un clavier. Les utilisateurs ayant une déficience visuelle utilisent généralement un clavier en même temps que leur lecteur d'écran ou des gestes sur leurs appareils mobiles.

En appuyant sur la touche Tab de votre clavier, vous pouvez passer d'un élément interactif à un autre sur une page web, comme des boutons ou des liens. Vous pouvez l'essayer sur cette page : après chaque tabulation, vous verrez une indication visuelle de votre position sur l'écran.

Styles de mise au point CSS

En CSS, vous pouvez ajouter un style pour plusieurs états différents des boutons, tels que le survol, le focus et l'actif. Souvent, tout ou partie de ces états ne sont pas pris en compte et le bouton ne change pas d'apparence en fonction de l'interaction. Dans ce cas, l'utilisateur du clavier est aveugle.

Conseil : appliquer les styles de mise au point en même temps que les styles de survol

Lorsque vous ajoutez des styles pour l'état de survol des boutons, il est conseillé d'en ajouter également pour l'état de mise au point. Idéalement, le style de mise au point devrait être plus apparent que le style de survol, vous pouvez donc les ajouter séparément dans une nuance différente.

Aperçu de la mise au point du navigateur

Un indicateur de mise au point de base est fourni automatiquement par le navigateur web et s'affiche généralement sous la forme d'une bordure. Si vous venez de parcourir cette page, vous l'avez peut-être vu. Malheureusement, ce contour est souvent désactivé par les feuilles de style CSS, pour des raisons esthétiques. Mais si le contour est désactivé et qu'il n'y a pas de style de mise au point, il est impossible de naviguer sur une page web uniquement à l'aide d'un clavier.

Conseil : ne pas désactiver le contour

Les utilisateurs de souris ne verront pas le contour du navigateur que vous voyez lorsque vous naviguez sur une page web à l'aide d'un clavier. Ne désactivez pas ce contour avec CSS, car il s'agit d'une aide essentielle pour les utilisateurs handicapés. Il constitue également une bonne solution de secours au cas où vos styles de mise au point ne seraient pas assez clairs ou seraient absents par accident.

N'oubliez pas que les indicateurs de focus clavier des navigateurs peuvent varier et prendre différentes formes. C'est pourquoi vous ne pouvez pas vous y fier complètement. D'autre part, il faudrait beaucoup de tests pour savoir avec certitude si vos styles de mise au point sont suffisamment clairs pour les utilisateurs handicapés. C'est pourquoi je conseille de toujours avoir les deux.

Erreur 7 : Utiliser des icônes non identifiées dans les boutons et les liens

Les icônes utilisées dans les logiciels deviennent reconnaissables après une utilisation répétée.

Les icônes sont un excellent moyen d'éviter l'encombrement de votre produit en ligne. Elles ont également le pouvoir d'améliorer l'accessibilité pour les personnes souffrant de divers handicaps, à condition qu'elles ne soient pas ambiguës. La plupart d'entre nous savent que l'icône d'un crayon signifie "modifier" et qu'une corbeille signifie "supprimer". Lorsque nous utilisons des icônes dans une interface utilisateur, il est préférable de s'en tenir à celles que nous connaissons pour éviter les devinettes. Mais même dans ce cas, en termes d'accessibilité, beaucoup de choses peuvent mal tourner.

Les icônes peuvent être utilisées à côté de leur étiquette textuelle correspondante ou seules. Le plus souvent, aucune étiquette n'est fournie lorsqu'elles sont utilisées seules. Par exemple, j'ajoute un bouton iconique pour une action d'édition, avec juste l'icône d'un crayon à l'intérieur. Si je n'ajoute pas d'étiquette textuelle pour cette icône, le bouton devient un bouton vide. C'est exact : un lecteur d'écran me communiquera : "Bouton". Ce n'est pas très utile.
Plus encore : Je pars du principe que l'utilisateur sait qu'une icône en forme de crayon signifie "modifier". Mais je n'en suis pas certain.

Conseil : ajouter une étiquette pour les icônes

Si l'icône est un élément important de votre interface utilisateur, il est préférable d'ajouter une étiquette. Vous pouvez le faire en ajoutant un aria-label sur l'icône. Une deuxième méthode consiste à ajouter un texte que vous cachez pour les écrans mais qui est visible pour les utilisateurs de lecteurs d'écran. Il est préférable d'ajouter un attribut de titre également. De cette façon, si un utilisateur de la souris survole l'étiquette, celle-ci s'affiche.

Boutons-icônes dans le tableau de bord d'Easy LMS qui affichent un titre lorsque vous les survolez.

Conseil : masquer les icônes décoratives

Si vous avez ajouté une icône purement symbolique et que l'information est compréhensible sans elle, il est préférable de cacher l'élément pour les utilisateurs de lecteurs d'écran.

Conclusion : ne travaillez pas plus dur, travaillez plus intelligemment

L'idée que vous devez changer ces choses peut encore être un peu écrasante. Lorsque j'ai découvert l'accessibilité, j'ai eu la même réaction. Il y a tant à apprendre et tant de types de handicaps différents. Il est difficile de créer une interface utilisateur parfaite pour tout le monde.

Mais je tiens à vous dire qu'il ne s'agit pas de revoir votre produit ou votre site web. J'ai découvert que la meilleure façon de procéder est d'intégrer l'accessibilité dans votre flux de travail. La prochaine fois que je crée ou modifie une partie du produit, j'applique immédiatement ce que j'ai appris sur l'accessibilité. De cette façon, nous pouvons améliorer l'accessibilité une étape à la fois. Comme le conseille l'un de mes héros en matière d'accessibilité, Léonie Watson : "Il n'est pas nécessaire que ce soit parfait ; il faut juste que ce soit un peu mieux qu'hier". Prêchez !