Comment améliorer l'accessibilité d'un site web : guide pratique

Un site web accessible est un site que chacun peut utiliser, quel que soit son handicap ou sa façon de naviguer : avec un lecteur d'écran, au clavier uniquement, avec un texte agrandi, avec une perception limitée des couleurs ou avec un tremblement de la main. Les mêmes améliorations profitent aussi à ceux qui ont un bras cassé, un petit écran de téléphone en plein soleil ou une connexion lente.

La référence la plus répandue est celle des Web Content Accessibility Guidelines (WCAG), actuellement en version 2.2. De nombreuses lois sur l'accessibilité et règles de commande publique renvoient aux WCAG, le plus souvent au niveau AA. Ce guide se concentre sur les correctifs qui lèvent les obstacles les plus fréquents, puis montre comment les tester.

Commencez par un contrôle automatique, puis testez à la main

Une analyse automatique est le moyen le plus rapide de repérer les problèmes évidents. L'outil de test d'accessibilité gratuit de Rudra charge votre page dans un vrai navigateur et exécute axe-core, le moteur de test open source le plus utilisé. Il liste chaque règle en échec, le nombre d'éléments concernés et la gravité de l'impact : texte alternatif manquant, champs de formulaire sans étiquette, contraste insuffisant, langue de la page non déclarée, boutons et liens vides, entre autres.

Les correctifs qui comptent le plus

1. Donnez aux images des alternatives textuelles pertinentes

Chaque <img> doit avoir un attribut alt. Pour les images porteuses d'information, décrivez ce que l'image apporte dans son contexte, et pas seulement ce qu'elle représente : alt="Line chart: sign-ups doubled after the March redesign" est plus utile que alt="chart". Pour les images purement décoratives, utilisez un alt="" vide afin que les lecteurs d'écran les ignorent. Pour une image qui sert de lien ou de bouton, décrivez l'action (« Rechercher », « Télécharger le rapport »). Les graphiques complexes exigent en outre que les données clés figurent dans un texte ou un tableau à proximité.

2. Étiquetez chaque champ de formulaire

Chaque champ doit avoir une étiquette visible, reliée à lui dans le code : <label for="email">Email address</label> suivi de <input id="email" type="email" autocomplete="email">. Le texte d'un placeholder n'est pas une étiquette : il disparaît dès la première frappe et son contraste est souvent faible. Affichez les erreurs sous forme de texte à côté du champ (et pas seulement par une bordure rouge), expliquez comment les corriger et reliez-les au champ avec aria-describedby.

3. Soignez le contraste des couleurs

• Texte normal : un rapport de contraste d'au moins 4,5:1 avec son arrière-plan (WCAG 1.4.3, niveau AA).
• Grand texte (au moins 24 px, ou environ 18,7 px en gras) : au moins 3:1.
• Composants d'interface et éléments graphiques porteurs de sens, comme les bordures de champs, les indicateurs de focus et les icônes signifiantes : au moins 3:1 avec les couleurs adjacentes (WCAG 1.4.11).
• Ne vous reposez pas sur la seule couleur (WCAG 1.4.1). Un lien dans un paragraphe doit se distinguer autrement que par sa couleur, en général par un soulignement, et une erreur ne doit pas être signalée uniquement en rouge.

Les outils de développement des navigateurs affichent le rapport de contraste lorsque vous inspectez un élément de texte : vous pouvez ainsi vérifier et ajuster les couleurs au fil de l'eau. Méfiez-vous du texte gris clair, du texte posé sur des photos et du texte des placeholders.

4. Rendez tout utilisable au clavier

Tout ce que l'on fait à la souris doit pouvoir se faire avec Tab, Maj+Tab, Entrée, Espace, les touches fléchées et Échap. Utilisez de vrais éléments <button> et <a href> plutôt que des <div> cliquables, qui ne peuvent ni recevoir le focus ni être activés au clavier sans travail supplémentaire. Ne supprimez jamais le contour de focus sans le remplacer par un indicateur bien visible ; :focus-visible permet de ne le styler que pour les utilisateurs du clavier. Veillez à ce qu'un en-tête fixe ou un bandeau cookies ne masque pas l'élément qui a le focus (nouveau critère des WCAG 2.2, le 2.4.11), à ce que les boîtes de dialogue retiennent le focus tant qu'elles sont ouvertes et le restituent à la fermeture, et ajoutez un lien « Aller au contenu principal » en haut de page.

5. Structurez les pages avec des titres et des régions

Les utilisateurs de lecteurs d'écran naviguent souvent en sautant de titre en titre. Utilisez un seul <h1> qui décrit la page, puis des <h2> et des <h3> dans un ordre logique, et choisissez les niveaux de titre pour la structure, pas pour leur taille de police. Encadrez les différentes zones avec <header>, <nav>, <main> et <footer> afin que chacun puisse accéder directement au contenu.

6. Déclarez la langue de la page et un titre unique

<html lang="en"> (ou le code de votre langue) indique aux lecteurs d'écran comment prononcer le texte. Un <title> unique et descriptif est la première chose annoncée à l'ouverture d'une page, et ce qui permet de la reconnaître parmi les onglets du navigateur.

7. Rédigez des liens et des boutons compréhensibles hors contexte

Les utilisateurs de lecteurs d'écran peuvent afficher la liste de tous les liens d'une page ; « Cliquez ici » et « Lire la suite » répétés dix fois n'y ont aucun sens. Préférez un intitulé comme « Lire le guide des tarifs ». Les boutons réduits à une icône, une loupe ou un « × » de fermeture par exemple, ont besoin d'un nom accessible : <button aria-label="Close">.

8. Prévoyez des cibles assez grandes pour être atteintes

Les WCAG 2.2 ont ajouté une exigence de niveau AA (2.5.8) : les cibles de pointeur doivent mesurer au moins 24 × 24 pixels CSS, ou être espacées de sorte qu'un cercle de 24 pixels tracé autour de chacune n'en chevauche aucune autre. Des cibles plus grandes, de l'ordre de 44 × 44 pixels (la recommandation de niveau AAA), sont encore préférables sur les écrans tactiles.

9. Prenez en charge le zoom et la redistribution du contenu

Ne désactivez jamais le zoom avec user-scalable=no ou maximum-scale=1. Le contenu doit se réorganiser en une seule colonne, sans défilement horizontal, à une largeur de 320 pixels CSS, ce qui correspond à un zoom de 400 % sur un écran d'ordinateur classique (WCAG 1.4.10). Une mise en page responsive fait l'essentiel du chemin ; voir comment rendre un site web adapté aux mobiles.

10. Traitez les médias et les animations avec soin

Proposez des sous-titres pour les vidéos et des transcriptions pour les contenus audio. Ne lancez pas de son automatiquement. Dotez les carrousels et les animations d'un bouton de pause, et respectez la media query prefers-reduced-motion en réduisant ou en supprimant les animations non essentielles pour ceux qui en ont fait la demande.

11. Préférez le HTML natif à ARIA

Les attributs ARIA modifient ce qu'annoncent les technologies d'assistance, pas le comportement d'un élément. Un <div role="button"> nécessite toujours une gestion du clavier que vous devez écrire vous-même ; un <button> l'intègre d'origine. Utilisez les éléments natifs partout où c'est possible, et n'ajoutez ARIA que lorsque HTML n'offre aucun équivalent, en suivant les modèles de l'ARIA Authoring Practices Guide du W3C.

Un test manuel en 15 minutes

1. Débranchez la souris. Parcourez la page à la touche Tab depuis le haut. Voyez-vous où se trouve le focus à chaque étape ? Pouvez-vous atteindre et actionner chaque lien, bouton, menu et champ de formulaire ? Pouvez-vous fermer les fenêtres pop-up avec Échap ?
2. Zoomez à 200 %, puis à 400 %. Le texte se réorganise-t-il, ou faut-il faire défiler la page horizontalement ? Des éléments se chevauchent-ils ou disparaissent-ils ?
3. Essayez un lecteur d'écran pendant quelques minutes : NVDA (gratuit, Windows), VoiceOver (intégré à macOS et iOS) ou TalkBack (Android). Affichez la liste des titres et des liens, et remplissez un formulaire. Tout est-il annoncé clairement ?
4. Vérifiez les images. Lisez les textes alternatifs (le lecteur d'écran, ou l'inspecteur d'accessibilité de votre navigateur, les affiche). Décrivent-ils ce qui compte ?
5. Regardez la page en niveaux de gris (la plupart des systèmes d'exploitation proposent un réglage de filtre de couleur). Une information est-elle transmise uniquement par la couleur ?

Intégrez l'accessibilité à vos processus

• Corrigez d'abord les problèmes dans les composants et gabarits partagés ; un composant d'en-tête ou de formulaire corrigé, ce sont toutes les pages qui l'utilisent qui le sont.
• Ajoutez des contrôles automatiques à votre chaîne de développement, par exemple axe-core avec vos tests de bout en bout, afin de repérer les régressions avant la mise en production.
• Incluez les vérifications du clavier et des contrastes dans votre « definition of done » pour les nouvelles fonctionnalités.
• Publiez une déclaration d'accessibilité assortie d'un moyen de signaler les obstacles rencontrés, et donnez suite à ce que l'on vous remonte.

Les erreurs courantes

• Compter sur un widget de surcouche pour régler l'accessibilité. Un script ajouté par-dessus la page ne peut pas réparer le balisage sous-jacent, et de nombreux utilisateurs en situation de handicap indiquent que ces surcouches les gênent.
• Bourrer les textes alternatifs de mots-clés, ou les faire commencer par « Image de » (les lecteurs d'écran annoncent déjà qu'il s'agit d'une image).
• Utiliser le texte d'un placeholder à la place des étiquettes.
• Supprimer les contours de focus pour des raisons esthétiques.
• Ajouter aria-label partout, au point parfois d'écraser un texte visible tout à fait correct.
• Considérer un rapport automatique sans erreur comme la preuve qu'un site est accessible.