L’accessibilité arrive presque toujours en fin de projet, sous forme de liste de reproches. À ce stade, elle coûte cher et frustre tout le monde. Prise au début, elle ne coûte quasiment rien — et elle rend l’interface meilleure pour tout le monde.
Ce que l’accessibilité corrige pour les autres
Le sous-titrage sert d’abord aux gens dans le métro. Le contraste élevé sert d’abord à ceux qui consultent leur téléphone en plein soleil. La navigation au clavier sert d’abord aux utilisateurs avancés. Les gains dits « d’accessibilité » sont massivement consommés par des utilisateurs sans handicap.
Quatre gestes qui couvrent l’essentiel
- HTML sémantique — un
<button>est un bouton. Une<div>avec unonclickn’en est pas un, et ne le sera jamais tout à fait. - Focus visible — ne jamais écrire
outline: nonesans poser un remplaçant au moins aussi lisible. - Contrastes — 4,5:1 pour le texte courant. Cela se vérifie à la conception, pas à la recette.
- Alternatives textuelles — une image décorative prend un
altvide ; une image porteuse d’information prend une description. Les deux sont des décisions, pas des oublis.
Une interface accessible n’est pas une interface bridée. C’est une interface qui a été pensée.
Ce qu’on aimerait ne plus avoir à dire
L’outil ne remplace pas le test
Les validateurs automatiques détectent environ un tiers des non-conformités. Le reste — la pertinence d’une alternative, la logique de l’ordre de tabulation, la clarté d’un intitulé de lien — demande un humain. Dix minutes au clavier, sans souris, en apprennent plus que n’importe quel rapport.