On imagine souvent l'accessibilité comme un sujet de niche : quelque chose qu'on traite « si on a le temps », pour une petite minorité de visiteurs. C'est une erreur de cadrage. Un site accessible, c'est d'abord un site qui fonctionne quand les conditions ne sont pas idéales — écran en plein soleil, souris cassée, connexion lente, main occupée, fatigue en fin de journée. Autrement dit : tout le monde, régulièrement.
Et c'est aussi un site plus simple. La plupart des corrections d'accessibilité consistent à retirer des complications, pas à en ajouter. Voici les bases qui produisent le plus d'effet, dans l'ordre où je les traite.
Le contraste : la correction la moins chère
C'est le problème le plus répandu, et le plus facile à régler. Le gris clair sur fond blanc est joli sur l'écran calibré d'un designer, illisible sur un téléphone dans le train.
Les règles WCAG donnent des seuils précis : un rapport de contraste d'au moins 4,5:1 pour le texte courant, et 3:1 pour le grand texte ainsi que pour les éléments d'interface (bordures de champs, icônes porteuses de sens). Ce ne sont pas des recommandations vagues — ce sont des nombres qu'on vérifie en quelques secondes avec un outil de contraste, ou directement dans l'onglet inspecteur du navigateur.
Le piège classique : le texte des boutons secondaires et des mentions légales, systématiquement trop pâle. Personne ne le remarque en interne, parce que tout le monde connaît déjà le contenu.
Le focus visible : ne le supprimez pas
Beaucoup de gens naviguent au clavier. Certains n'ont pas le choix, d'autres vont simplement plus vite ainsi. Ils appuient sur Tab pour passer d'un lien à l'autre — et le navigateur affiche un contour autour de l'élément actif.
Ce contour est souvent supprimé en CSS parce qu'il ne plaît pas visuellement. C'est probablement le geste le plus dommageable qu'on puisse faire à un site : l'utilisateur au clavier navigue alors à l'aveugle, sans savoir où il se trouve.
La bonne approche n'est pas de le supprimer, mais de le dessiner : un contour net, contrasté, cohérent avec l'identité du site. Testez-le vous-même — ouvrez votre page d'accueil, appuyez sur Tab une dizaine de fois, et regardez si vous suivez le parcours sans effort. Si vous perdez le fil, vos visiteurs aussi.
Les textes alternatifs : décrire l'intention
Une image sans attribut alt est un trou dans la page pour un lecteur d'écran. Mais un alt mal écrit n'aide pas davantage. La question à se poser n'est pas « qu'y a-t-il sur cette image ? » mais « pourquoi cette image est-elle là ? ».
Une photo d'illustration décorative n'a rien à dire : alt="" est la bonne réponse, elle sera ignorée. Un logo dans un lien vers l'accueil doit annoncer la destination, pas décrire un dessin. Un graphique doit transmettre l'information qu'il porte — si le chiffre compte, il doit apparaître en texte quelque part.
Les formulaires : des étiquettes, pas des placeholders
Le formulaire de contact est souvent la page la plus importante d'un site vitrine. C'est aussi celle qui accumule le plus de problèmes d'accessibilité.
Le plus fréquent : remplacer les étiquettes par des textes d'invite (placeholder). C'est élégant tant que le champ est vide — puis l'indication disparaît dès qu'on tape, le contraste est généralement trop faible, et les lecteurs d'écran ne l'interprètent pas de façon fiable. Une vraie balise <label> associée au champ résout tout cela d'un coup, et agrandit au passage la zone cliquable.
Deux autres réflexes utiles : indiquer les erreurs en texte, pas seulement par une bordure rouge (la couleur seule n'est jamais un message), et ne pas imposer de contraintes de format inutiles sur les numéros de téléphone ou les adresses.
La structure : du HTML qui dit ce qu'il est
Un lecteur d'écran ne voit pas votre mise en page, il lit votre structure. Un titre qui n'est qu'un <div> en gras n'est pas un titre pour lui. Un bouton fabriqué avec une <div> cliquable ne se déclenche pas au clavier.
Les bases tiennent en peu de choses : un seul <h1> par page, des niveaux de titres dans l'ordre, <button> pour une action et <a> pour une destination, l'attribut lang correct sur la balise <html> — c'est lui qui indique au lecteur d'écran quelle prononciation utiliser, et il est particulièrement important sur un site bilingue comme celui-ci.
Le HTML natif fait déjà presque tout le travail. Les attributs ARIA servent à combler ce qui manque, pas à réparer du balisage mal choisi.
Ce que ça coûte, et ce que ça rapporte
Traitées dès la conception, ces cinq bases ne coûtent presque rien : ce sont des décisions, pas du développement supplémentaire. Rattrapées après coup sur un site terminé, elles deviennent un chantier — d'où l'intérêt de les poser au départ.
Le bénéfice ne se limite pas aux visiteurs en situation de handicap. Une structure de titres propre aide aussi les moteurs de recherche. Des libellés explicites réduisent les abandons de formulaire. Un contraste correct rend le site lisible en mobilité. Et selon votre marché, l'accessibilité numérique relève de plus en plus d'obligations réglementaires — le cadre européen s'est notablement durci ces dernières années, et vaut la peine d'être vérifié pour votre secteur.
Un test rapide pour situer votre site : naviguez une page entière au clavier uniquement, puis relisez-la en plein soleil sur votre téléphone. Ce que vous découvrirez sera probablement corrigeable en une journée.
Vous voulez un regard sur l'accessibilité de votre site, ou un site pensé accessible dès la première maquette ? Parlons-en.