Accessibilité web : par quoi commencer
Le travail d'accessibilité a une longue liste de critères et une courte liste de choses qui expliquent l'essentiel des barrières réelles. Commencer par la liste courte met rapidement de vrais utilisateurs sur votre site ; commencer par un audit complet produit généralement un document que personne ne traite.
Ce guide couvre par quoi commencer, comment le tester vous-même en une après-midi, et pourquoi les widgets de surcouche ne sont pas le raccourci qu'on vous vend.
Les corrections à plus fort effet#
Ce sont les barrières qui empêchent complètement d'accomplir une tâche, plutôt que de la rendre un peu plus difficile. Corrigez-les avant tout ce qui figure sur une liste plus longue.
- Accès au clavier. Chaque élément interactif atteignable avec Tab et actionnable avec Entrée ou Espace, dans un ordre sensé, avec un indicateur de focus visible. Si le site ne s'utilise qu'à la souris, rien d'autre sur cette liste ne compte.
- Alternatives textuelles. Un texte alternatif utile sur les images porteuses d'information ; un alt vide sur les images décoratives. Un alt absent n'est pas la même chose qu'un alt vide.
- Libellés de formulaire. Un vrai <label> relié à chaque champ. Le texte d'exemple n'est pas un libellé : il disparaît à la saisie et n'est pas annoncé de façon fiable.
- Contraste. Texte courant à 4,5:1, grand texte et contrôles à 3:1, vérifiés sur le fond réel.
- Titres. Un H1, aucun niveau sauté. Les personnes utilisant un lecteur d'écran naviguent par titres plus que par tout autre moyen.
- Texte des liens. « Lire la suite » répété quatorze fois donne quatorze destinations identiques à un lecteur d'écran. Dites où cela mène.
- Messages d'erreur. À côté du champ, en texte, décrivant quoi faire — pas la couleur seule, pas une bordure rouge seule.
Testez vous-même en une après-midi#
Vous n'avez pas besoin de logiciel spécialisé pour trouver l'essentiel des problèmes. Ces cinq passages prennent une à deux heures sur un site moyen et trouvent la majorité des barrières réelles.
| Test | Comment | Ce qu'il détecte |
|---|---|---|
| Clavier uniquement | Débranchez la souris, parcourez chaque page avec Tab | Pièges, focus invisible, contrôles inatteignables |
| Zoom à 200 % | Taille de texte du navigateur, pas zoom de page | Texte tronqué, défilement horizontal, mises en page cassées |
| Lecteur d'écran | VoiceOver ou NVDA sur les gabarits principaux | Libellés manquants, liens sans signification, changements non annoncés |
| Analyse automatique | axe ou Lighthouse dans le navigateur | Contraste, alt manquant, mauvais usage d'ARIA : environ 30 % des problèmes |
| Niveaux de gris | Filtre du navigateur ou réglage système | Tout ce qui n'est transmis que par la couleur |
Les outils automatiques trouvent environ un tiers des problèmes d'accessibilité. C'est un point de départ, pas une note de passage : un site à 100 dans Lighthouse peut rester inutilisable au clavier.
Les motifs qui posent le plus de problèmes#
Les composants sur mesure sont l'endroit où l'accessibilité casse habituellement, car les éléments natifs apportent un comportement que les composants sur mesure doivent réimplémenter.
- Listes déroulantes sur mesure faites de div, sans support clavier ni rôles. Un <select> natif est gratuit et fonctionne partout.
- Fenêtres modales qui ne piègent pas le focus, ne se ferment pas avec Échap et laissent l'arrière-plan défiler.
- Carrousels qui avancent tout seuls sans commande de pause : ils sont hostiles à presque tout le monde, pas seulement aux personnes handicapées.
- Boutons uniquement iconographiques sans nom accessible. Une croix sans libellé est annoncée comme « bouton ».
- Défilement infini sans moyen d'atteindre le pied de page.
- Soupe de div : des div cliquables au lieu de boutons et de liens, ce qui supprime d'un coup le support clavier et la sémantique.
- Mouvement qui ignore prefers-reduced-motion.
La stratégie d'accessibilité la moins chère consiste à utiliser l'élément HTML natif prévu pour la tâche. Chaque remplacement sur mesure est une promesse de réimplémenter un comportement qui venait gratuitement.
Pourquoi les widgets de surcouche ne sont pas une solution#
Les surcouches d'accessibilité promettent la conformité par un simple script. Elles ne peuvent pas la livrer, car les problèmes de fond sont structurels : un script ne peut pas savoir ce que représente une image, ne peut pas écrire un libellé qui corresponde à la finalité d'un champ, et ne peut pas réparer un piège au clavier dans un composant sur mesure.
Elles interfèrent aussi avec les technologies d'assistance que les gens utilisent et ont configurées, raison pour laquelle plusieurs organisations de personnes handicapées les déconseillent. Il vaut surtout la peine de les connaître pour pouvoir les refuser avec un motif défendable.
- Elles ne peuvent pas générer un texte alternatif exact, car elles ignorent ce que l'image signifie en contexte.
- Elles ne peuvent pas corriger des pièges au clavier dans des composants qu'elles n'ont pas construits.
- Elles entrent souvent en conflit avec les réglages du lecteur d'écran de l'utilisateur.
- Elles ne suppriment pas l'exposition juridique : les barrières de fond sont toujours là.
- L'argent est mieux employé sur les sept corrections en haut de cette page.
Questions fréquentes
L'accessibilité est-elle une obligation légale ?
Dans de nombreuses juridictions oui, pour les organismes publics et de plus en plus pour les entreprises privées : la directive européenne sur l'accessibilité, l'ADA aux États-Unis appliqué aux sites web, et des équivalents ailleurs. Les obligations diffèrent selon le pays et le secteur, vérifiez donc localement. En pratique, WCAG 2.2 AA est la norme vers laquelle presque toute réglementation renvoie.
Combien l'accessibilité ajoute-t-elle à un projet ?
Pensée dès le départ, très peu : surtout de la rigueur sur la sémantique, le contraste et les états de focus. Ajoutée à un site sur mesure terminé, cela peut être un projet conséquent, car les corrections sont structurelles et non cosmétiques. Cette différence est tout l'argument pour l'évoquer dans le brief plutôt qu'après le lancement.
Quelle différence entre WCAG A, AA et AAA ?
Ce sont des niveaux de conformité. A est le minimum et laisse de vraies barrières en place ; AA est ce que la réglementation exige généralement et la cible de la plupart des organisations ; AAA comprend des critères impossibles à atteindre pour tout contenu, par exemple une exigence de contraste 7:1 que certaines palettes de marque ne peuvent pas respecter. Visez AA et traitez AAA comme une amélioration critère par critère plutôt que comme une cible.
L'accessibilité aide-t-elle le SEO ?
Indirectement et réellement. Une structure de titres correcte, des libellés de liens descriptifs, des attributs alt, une vraie sémantique et des pages rapides et stables aident les deux. Mais le recouvrement est partiel : un site peut bien se positionner et rester inutilisable au clavier. Faites de l'accessibilité parce que sinon des gens ne peuvent pas utiliser le site, et prenez le bénéfice SEO comme un effet secondaire.
accessibilité webwcagdesign web accessiblelecteur d'écrannavigation au claviertests d'accessibilité
