WebAIM Million : une analyse de l’accessibilité des pages d’accueil d’un million de sites web
Publié le 7 avril 2024
À retenir
- Les problèmes d’accessibilité les plus fréquents dans l’analyse de WebAIM pourraient être assez facilement corrigés s’ils étaient considérés dès la phase de conception d’un projet numérique
- Tous les intervenants dans un projet numérique, de la conception à la production, ont une part de responsabilité pour s’assurer que l’accessibilité soit prise en compte correctement
- Les problèmes d’accessibilité sur les sites en français ont augmenté de 9,6% depuis l’année précédente (2023)
Chaque année, WebAIM met à jour son analyse de l’accessibilité des pages d’accueil d’un million de sites web. Malgré de subtiles améliorations, les mêmes erreurs sont présentes depuis des années, et ce malgré la multiplication de conférences, d’articles et de vidéos qui vulgarisent le sujet.
Plusieurs dans les différentes industries numériques croient qu’un « spécialiste de l’accessibilité » est responsable de résoudre tous les problèmes potentiels liés à l’accessibilité. Il s’agit d’une grande mécompréhension du sujet : tous les intervenants dans un projet numérique, de la conception à la production, ont une part de responsabilité pour s’assurer que l’accessibilité soit prise en compte correctement.
Dans cet article, je décortique les points principaux listés dans l’analyse de WebAIM et je souligne quelles sont les responsabilités de chaque intervenant.
Comme pour d’autres articles que j’ai rédigés sur l’accessibilité et sur l’expérience utilisateur, j’ai noté que la majorité des informations qui circulent à ce sujet sont en anglais. Je ne sais pas si c’est par incompréhension de la langue, ou par paresse, mais j’ai remarqué que de partager des publications en anglais avec des collaborateurs francophones reste souvent lettre morte.
C’est ce qui ce qui me mène à publier ces articles en français : pour s’assurer que l’information soit plus facilement comprise, et pour s’assurer que designers et autres créateurs de contenu francophones aient une référence en main lorsqu’ils en ont besoin.
Analyse du WebAIM
Aperçu
Designers, développeurs et gestionnaires de projets semblent souvent avoir de la difficulté à percevoir l’accessibilité comme autre chose qu’une liste de cases à cocher pour passer à autre chose.
Rendre ces problèmes d’accessibilité plus compréhensibles en tant que l’expérience des utilisateurs ayant un handicap pourrait peut-être rendre l’effet de ces problèmes moins abstrait. L’article de WebAIM montre à quel point la fréquence des erreurs en accessibilité affecte beaucoup d’utilisateurs :
Les utilisateurs ayant un handicap sont susceptibles de faire face à des erreurs sur 1 élément de page d’accueil sur 21 avec lesquels ils interagissent. Les pages comportant davantage d’éléments présentent une proportion d’erreurs par élément encore plus élevée que les pages plus simples.
— Traduit de l’article « WebAIM Million » de WebAIM
Lorsque nous concevons des expériences numériques, nous mettons un temps fou à peaufiner une multitude de détails — souvent insignifiants pour les utilisateurs. Pourtant, les erreurs les plus fréquentes — qui elles, affectent et parfois ruinent l’expérience des utilisateurs ayant un handicap — sont souvent assez simples à régler si on les considère durant la phase de design.
| Type d’erreur WCAG v2 | 2024 | 2023 | 2022 | 2021 | 2020 | 2019 |
|---|---|---|---|---|---|---|
| Contraste insuffisant | 81.0% | 83.6% | 83.9% | 86.4% | 86.3% | 85.3% |
| Texte alternatif manquant pour images |
54.5% | 58.2% | 55.4% | 60.6% | 66.0% | 68.0% |
| Libellés manquants pour champs de formulaires |
48.6% | 45.9% | 46.1% | 54.4% | 53.8% | 52.8% |
| Liens vides | 44.6% | 50.1% | 49.7% | 51.3% | 59.9% | 58.1% |
| Boutons vides | 28.2% | 27.5% | 27.2% | 26.9% | 28.7% | 25.0% |
| Langue manquante pour document HTML |
17.1% | 18.6% | 22.3% | 28.9% | 28.0% | 33.1% |
(tableau et données tirés de l’article de WebAIM)
Le tableau ci-haut montre à quel point certaines erreurs sont fréquentes sur les sites web. Même si toutes ces erreurs ne concernent pas nécessairement les mêmes intervenants, il est bon pour tous de savoir ce qu’elles signifient pour nos collègues. Dans les sections qui suivent je mentionne qui sont les intervenants les plus à mêmes de s’assurer de régler ces problèmes.
Contraste insuffisant
Dans mon article S’assurer d’utiliser des couleurs suffisamment contrastées, j’offre beaucoup de détails sur ce sujet. En gros :
- Créez des contrastes appropriés entre les couleurs lors des phases de conception : stratégie de marque, documentation du système de design et mise en page
- Utilisez des outils pour tester le contraste des combinaisons de couleurs pendant la conception et en contexte (par exemple dans le navigateur)
Intervenants concernés
Ce travail tombe dans la cours des gens qui sont responsables de l’image de marque :
- designers graphiques
- directeurs artistiques
- directeurs de création
Mentionnons que les designers de produit et les designers UX pourraient également contribuer à s’assurer que les contrastes entre les couleurs soient suffisants, mais ce n’est pas leur mission première.
Le corollaire est donc qu’il n’est pas du ressort unique des développeurs de valider le contraste de couleurs. Comme tous leurs collègues, ils peuvent bien sûr garder un oeil ouvert.
Un gestionnaire de projet avisé devrait s’assurer que ses collègues aient validé les contrastes de couleur utilisés.
Texte alternatif manquant pour images
Dans mon autre article S’assurer de fournir un texte alternatif pour les images, j’analyse plus en détail ce qu’est le texte alternatif. En somme :
- Le texte alternatif (« alt text ») est nécessaire pour les utilisateurs qui dépendent de lecteurs d’écran pour leur fournir une description de l’image
- La même image dans un contexte différent peut nécessiter un texte alternatif différent
- Certaines images peuvent être considérées comme des décorations et ne pas nécessiter de texte alternatif
- Les images publiées sur les médias sociaux doivent également inclure un texte alternatif
Intervenants concernés
Comme mentionné dans l’article en question, plusieurs intervenants sont responsables de s’assurer que les images publiées soient accompagnées de texte alternatif :
- Les designers UX devraient analyser le type d’image utilisé dans le contexte des interface créées pour mentionner si ces images ont besoin de texte alternatif.
- Les rédacteurs devraient s’assurer de jeter un oeil aux interfaces créées ou publiées pour rédiger ou traduire les textes alternatifs.
- Les développeurs devraient porter attention lorsqu’ils intègrent des images dans les produits numériques pour s’assurer qu’ils utilisent le bon code pour ajouter le texte alternatif.
Ces développeurs devraient également mentionner à leurs collègues (designers, rédacteurs, gestionnaires de projet) quand il leur manque un texte alternatif. - Les gestionnaires de projet devraient communiquer avec les intervenants mentionnés plus haut durant la phase de conception ou durant la production, pour s’assurer que les textes alternatifs n’ont pas été oubliés.
On peut voir que dans ce cas, il s’agit réellement d’un travail d’équipe. Personne ne peut se décharger de cette responsabilité.
Libellés manquants pour champs de formulaires
Sans s’en rendre compte, la plupart des activités que les utilisateurs effectuent sur un site web consiste à remplir des formulaires, même si ceux-ci n’ont pas toujours l’aspect qu’on associe traditionnellement à un formulaire.
Dans mon article Chaque champ de formulaire doit avoir un libellé, qu’il soit visible ou non, je décortique en détail de bonnes stratégies à ce sujet.
Intervenants concernés
Comme dans le cas de textes alternatifs des images, la responsabilité est partagée entre différents intervenants :
- Les designers devraient annoter leurs designs pour s’assurer que leurs collègues et d’autres intervenants puissent savoir qu’il y a du travail à effectuer, même s’il n’y a pas de résultat visuel.
- Les rédacteurs devraient s’assurer de jeter un oeil aux interfaces créées ou publiées pour rédiger ou traduire les libellés.
- Les développeurs devraient porter attention lorsqu’ils intègrent des champs ou des éléments de formulaires pour s’assurer qu’ils utilisent le bon code pour les libellés.
Ces développeurs devraient également mentionner à leurs collègues (designers, rédacteurs, gestionnaires de projet) quand il leur manque un texte pour ces libellés. - Les gestionnaires de projet devraient communiquer avec les intervenants mentionnés plus haut durant la phase de conception ou durant la production, pour s’assurer que les libellés des champs de formulaires n’ont pas été oubliés.
Liens vides
Les hyperliens sont la base de la navigation sur le web. Des liens qui n’indiquent pas correctement où ils vont ou qui ne marchent pas sont un gros bloquant à un expérience plaisante lorsqu’on utilise un produit numérique.
Liens ambigus
On parle de lien ambigu quand il est simplement libellé « cliquez ici », « voyez en plus », « continuez », etc. Ce type de libellé est couramment utilisé dans une multitude de sites web, par exemple sur les pages d’accueil des journaux.
Il faudrait un article complet à ce sujet pour expliquer en détails pourquoi ce type de libellé est ambigu et insuffisant. Contentons-nous, pour les besoins de cette article, de cette courte explication : les utilisateurs de lecteurs d’écran naviguent souvent simplement par type de contenu (e.g. liens, boutons, titres). Un lecteur d’écran liste sans contexte tous les liens de la page d’un coup. Si ceux-ci sont tous libellés « cliquez ici », ils n’offrent absolument aucun indice sur où ils mènent, et sont donc complètement inutiles.
Intervenants concernés
Pour corriger ce type de problème, une collaboration entre designers et rédacteurs est nécessaire.
Liens pour sauter directement au contenu principal manquants ou non fonctionnels
La majorité, sinon la totalité, des sites web ont une en-tête à partir de laquelle on peut naviguer d’une section à l’autre du site. La présence de cet en-tête sur toutes les pages est pratique : elle nous permet de ne pas avoir à apprendre la structure du site par coeur, elle est répétée sur chaque page.
Par contre, pour des gens qui naviguent avec un lecteur d’écran, cette répétition de contenu lors de la navigation peut être fastidieuse. Il faut alors concevoir un mécanisme pour sauter les blocs de contenu répétitifs, souvent nommé « skip link » (lien pour sauter une section). Puisque cet élément est habituellement invisible jusqu’à ce que les utilisateurs y placent leur focus, il est souvent oublié.
Intervenants concernés
- Une partie de la responsabilité pour créer cette fonction tombe dans la cours des designers — plus souvent celle des designers UX
- Les développeurs sont également responsables de s’assurer de les intégrer correctement sur chaque page
Liens avec du code JavaScript qui devraient plutôt être des boutons
Le code publié sur le web est très flexible contrairement à d’autres environnements de programmation plus stricts. Par contre, il est également facile de mal programmer un élément, ce qui mène à des problèmes d’accessibilité. L’utilisation des boutons et des liens est un exemple qui mène fréquemment à des inconvénients pour les gens qui dépendent d’un lecteur d’écran.
Pour faire court :
- Un lien (ou ancre) doit être utilisé quand l’élément mène à une nouvelle page une fois activé
- Un bouton doit être utilisé quand l’élément a un effet sur la page actuelle
C’est tout, pas d’exception : peu importe l’apparence de l’élément dans la mise en page, les instructions ci-haut indiquent quel élément HTML utiliser.
Évitez cette mauvaise pratique
Il arrive souvent que des développeurs ajoutent à tort du code JavaScript (e.g. href="javascript: void(0);") pour forcer qu’un lien se comporte comme un bouton.
Ce type de design cause des problèmes d’accessibilité, utilisez un bouton à la place d’ajouter du code pour changer la fonctionnalité d’un lien.
Intervenants concernés
Ce cas concerne principalement les développeurs qui doivent s’assurer d’utiliser le bon élément HTML — un lien ou un bouton — dépendant de l’attente fonctionnelle du design.
Boutons vides
Tout comme pour les champs de formulaires, les boutons doivent être libellés correctement afin qu’ils soient utilisables correctement pour les gens qui naviguent avec un lecteur d’écran, entre autre.
Dans mon article Chaque bouton doit avoir un libellé, qu’il soit visible ou non, j’explore plus en profondeur les tenants et aboutissants de ce sujet.
Intervenants concernés
- Les designers sont responsables d’identifier quel élément nécessite quel type de texte et de le communiquer à leurs collègues.
- Les rédacteurs doivent rédiger ou traduire les libellés et les messages que le lecteur d’écran doit annoncer.
- Les développeurs devraient porter attention lorsqu’ils intègrent des boutons pour s’assurer qu’ils utilisent le bon code pour les libellés.
Ces développeurs devraient également mentionner à leurs collègues (designers, rédacteurs, gestionnaires de projet) quand il leur manque un texte pour ces libellés. - Les gestionnaires de projet devraient communiquer avec les intervenants mentionnés plus haut durant la phase de conception ou durant la production, pour s’assurer que les libellés des boutons n’ont pas été oubliés.
Langue manquante pour document HTML
Pour qu’un lecteur d’écran puisse lire le contenu correctement, la langue d’une page HTML doit être correctement identifiée au niveau du code.
Dans son article Using the correct ISO language marker matters (« Le choix du bon marqueur de langue ISO est important »), le spécialiste Nicolas Steenhout nous rappelle qu’il faut faire attention de ne pas non plus être trop précis dans le choix de la région d’une langue, parce que ça affecterait négativement l’expérience des utilisateurs de lecteur d’écran :
Un utilisateur de lecteur d’écran m’a un jour expliqué quels problèmes pouvaient survenir si on utilise un code ISO localisé. Par exemple, si au lieu d’utiliser
lang="en", on utiliselang="en-us"oulang="en-gb". Cela détermine une localisation spécifique de la langue. Comme l’a expliqué cet utilisateur, il a l’habitude d’écouter les pages à un débit très élevé. Si on oblige son lecteur d’écran à lire et à prononcer les choses légèrement différemment parce qu’on choisit une localisation spécifique, cela le perturbera. Il devra ralentir son lecteur d’écran.— Traduit de « Using the correct ISO language marker matters », Nicolas Steenhout
Intervenants concernés
- Les rédacteurs doivent s’assurer d’identifier correctement la langue à utiliser pour les pages d’un site web
- Les développeurs doivent s’assurer que la bonne langue a été attribué à chaque page d’un site web
Conclusion
L’analyse de WebAIM est encore beaucoup plus détaillée que ce que j’ai mentionné dans cet article :
- D’autres points, tels les titres (« headings ») ou l’utilisation d’ARIA sont analysés
- L’évolution de la présence des erreurs selon les catégories, par exemple la technologie choisie, la catégorie de site web, ou le type de domaine
Parmi ces points, WebAIM a également fait une analyse selon la langue des pages, et il est triste de constater que les pages en français (20 670 pages) analysées ont présenté une augmentation de 9.6% d’erreurs depuis l’année précédente (moyenne de 62,3 erreurs par page).
J’ai fait ici une analyse de la recherche que WebAIM met à jour annuellement depuis quelques années. J’ai listé clairement les intervenants avec l’intention qu’ils se sentent interpelés de prendre action afin de régler les problèmes d’accessibilité présents dans leurs produits numériques. Les gestionnaires de projet devraient se sentir particulièrement visés, puisqu’ils sont responsables d’allouer suffisamment de temps durant les phases de conception et de production pour que les gens d’une équipe puissent s’informer sur l’accessibilité et collaborer pour régler les problèmes listés plus haut.
Nous avons encore beaucoup de travail à faire du côté des produits numériques en français pour offrir une expérience utilisateur de qualité pour tous, surtout au niveau des gens qui ont des besoins plus spécifiques ou qui ont besoin d’appareils d’assistance pour naviguer.
Références et lectures additionnelles
Articles
The WebAIM Million – The 2023 report on the accessibility of the top 1,000,000 home pages | WebAIM
S’assurer d’utiliser des couleurs suffisamment contrastées | Mat Janson Blanchet
S’assurer de fournir un texte alternatif pour les images | Mat Janson Blanchet
Buttons vs. Links | Eric Eggert
Chaque champ de formulaire doit avoir un libellé, qu’il soit visible ou non | Mat Janson Blanchet
A Complete Guide to Links and Buttons Chris Coyier – CSS Tricks
Documenter l’accessibilité en phase de design ! | Stéphanie Walter
The Links vs. Buttons Showdown — Marcy Sutton: #id24 Nov 2017 | Inclusive Design 24 #id24 – YouTube
Using the correct ISO language marker matters | Nic Steenhout – Substack
When to Use Buttons and Links | Balsamiq
Accessibilité
Understanding [Success Criterion] 2.4.1: Bypass Blocks (Level A) | WCAG Understanding Docs – W3C
Articles techniques
<a> : l’élément d’ancre | MDN Web Docs
<button> : l’élément représentant un bouton | MDN Web Docs