Un jour, un développeur m'a montré son formulaire d'inscription. Magnifique. Animations soignées, champs qui se colorent au focus, messages d'erreur qui glissent depuis le haut. Puis il a fermé les yeux, a posé la main sur son clavier, et a essayé de s'inscrire sans sa souris.
Il n'a jamais atteint le bouton de validation. Le focus partait dans le vide après le troisième champ. Là, en trente secondes, il venait de découvrir que la moitié de son travail était invisible pour une partie de ses utilisateurs.
L'accessibilité web, ce n'est pas une case à cocher en fin de sprint. C'est une façon d'écrire du HTML, de nommer ses composants et de penser ses interactions. Et la bonne nouvelle, c'est que 80 % des blocages viennent de cinq ou six habitudes qu'on peut corriger en une après-midi.
Je vais vous montrer lesquelles, avec le code avant/après. Parce qu'un principe sans exemple ne rentre jamais.
Points clés à retenir
- Le HTML sémantique règle plus de problèmes que n'importe quelle bibliothèque de composants.
- Le taux de contraste minimum pour du texte courant est de 4.5:1 (niveau AA).
- Une application entièrement pilotable au clavier est accessible à une majorité de profils.
- ARIA ne compense jamais un HTML mal choisi : mauvais ARIA, pire que pas d'ARIA.
- Tester avec un lecteur d'écran pendant cinq minutes vaut mieux que lire trois articles de blog.
- Le cadre légal vous rattrape tôt ou tard, mais c'est la qualité du produit qui devrait vous motiver d'abord.
Accessibilité web : cinq habitudes de code qui changent tout
Le RGAA, le référentiel français, se décline en 106 critères. Ça fait peur. Pourtant, quand j'audite un site, je retrouve toujours les mêmes fautes, dans le même ordre de fréquence. Corrigez celles-là et vous passez d'un site inutilisable à un site correct.
1. Arrêter de faire des div partout
Le réflexe du développeur pressé : tout est une div, on met un onClick dessus, et ça marche. Sauf que ça ne marche que pour ceux qui ont une souris.
Le problème n'est pas visuel. Il est structurel. Un lecteur d'écran parcourt le document en s'appuyant sur les rôles HTML. Une div cliquable n'a aucun rôle. Elle est muette. L'utilisateur ne sait même pas qu'il peut cliquer dessus.
<!-- Ce qui bloque -->
<div class="btn" onclick="envoyer()">Envoyer</div>
<!-- Ce qui fonctionne -->
<button type="submit">Envoyer</button>La différence tient en un mot. Le <button> arrive gratuitement avec le focus clavier, l'activation par Entrée et par Espace, l'annonce vocale « bouton », et un état désactivé correct. Vous n'avez rien à écrire. Vous avez juste arrêté de réinventer ce que le navigateur fait déjà.
En 2026, avec les composants headless qui pullulent, cette erreur revient en force sous une forme plus sournoise : le composant maison qui « ressemble » à un bouton mais n'en est pas un dans l'arbre d'accessibilité.
2. Soigner le contraste, pas seulement l'esthétique
Ici, je vais être direct : le gris clair sur fond blanc est l'ennemi public numéro un. Ce joli #AAA sur #FFF que votre designer adore, il tombe à un ratio de 2.3:1. Il en faut deux fois plus.
Les seuils WCAG niveau AA, ceux qu'on vise en pratique :
- 4.5:1 pour le texte courant
- 3:1 pour le grand texte (au-delà de 24 px, ou 18,66 px en gras)
- 3:1 pour les éléments d'interface : bordures de champs, icônes porteuses de sens, indicateur de focus
Ce dernier point, personne ne le respecte au début. Moi compris. J'ai longtemps cru qu'un contour de focus « moche » était un détail cosmétique. Puis j'ai vu quelqu'un naviguer au clavier avec un contour de focus supprimé par un outline: none. Il était complètement perdu, sans aucun repère visuel.
Ne supprimez jamais l'indicateur de focus. Restylez-le. C'est trois lignes de CSS.
3. Le focus, ce grand oublié
La navigation clavier, c'est le test le plus rapide et le plus impitoyable. Posez votre souris. Faites Tab. Si vous perdez le fil, votre site a un problème.
Les pièges classiques :
- Une modale qui s'ouvre mais ne capture pas le focus — l'utilisateur continue de tabuler derrière l'overlay, dans du contenu invisible.
- Un menu déroulant qui se ferme dès qu'on essaie de l'atteindre au clavier.
- Un ordre de tabulation qui part dans tous les sens parce que le CSS
ordera réorganisé visuellement la page sans toucher au DOM.
Ce dernier cas est vicieux. Le DOM suit un ordre, l'œil en voit un autre, et le clavier suit le DOM. Résultat : vous tabulez à droite, le focus visuel saute à gauche. Utilisez order avec parcimonie.
4. Les formulaires : là où tout se joue
Un formulaire accessible repose sur une seule règle : chaque champ est relié à un libellé. Pas un placeholder. Un vrai <label>.
Le placeholder disparaît dès qu'on tape. Pour quelqu'un qui utilise un lecteur d'écran, il n'a jamais existé. Pour quelqu'un qui a des troubles de la mémoire de travail, il s'évapore au moment précis où il en a besoin.
<!-- À éviter -->
<input type="email" placeholder="Votre email">
<!-- À faire -->
<label for="email">Adresse email</label>
<input type="email" id="email" name="email"
autocomplete="email" required>L'attribut autocomplete est le bonus qu'on oublie systématiquement. Il aide les personnes qui utilisent des aides à la saisie, et franchement, il fait gagner du temps à tout le monde.
5. ARIA : un supplément, pas une béquille
La première règle d'ARIA est contre-intuitive : ne pas utiliser ARIA. Tant qu'un élément HTML natif fait le travail, il le fait mieux.
J'ai vu des role="button" posés sur des div avec tout le tralala : tabindex="0", gestion manuelle du clavier, état aria-pressed mis à jour à la main. Trois cents lignes de JavaScript pour imiter un <button>. Et à chaque refactoring, quelqu'un oubliait une touche.
ARIA sert quand le HTML n'a pas d'équivalent : un onglet, une liste déroulante personnalisée, une zone live qui annonce une mise à jour. Pour le reste, il ne fait que masquer la vraie question : pourquoi ne pas avoir pris l'élément natif ?
Les quatre principes POUR, expliqués sans jargon
Les WCAG reposent sur quatre principes. On les résume par l'acronyme POUR, et je les ai longtemps trouvés abstraits. Voici ce qu'ils veulent dire quand on écrit du code.
| Principe | La question à se poser | Exemple concret |
|---|---|---|
| Perceptible | L'information est-elle atteignable si on ne voit pas, n'entend pas ? | Texte alternatif sur une image informative, sous-titres sur une vidéo |
| Utilisable | Peut-on tout faire sans souris, sans geste précis ? | Navigation clavier, cibles tactiles assez grandes |
| Compréhensible | Le fonctionnement est-il prévisible ? | Messages d'erreur explicites, ordre de navigation logique |
| Robuste | Ça tient la route avec les technologies d'assistance ? | HTML valide, ARIA correctement utilisé |
Le quatrième est le plus souvent négligé, et c'est celui qui coûte le plus cher. Un site conforme aujourd'hui peut devenir inutilisable demain parce qu'un lecteur d'écran a changé de comportement face à du code mal formé. Robuste, c'est la durabilité du travail.
Tester l'accessibilité sans y passer la semaine
Vous n'avez pas besoin de devenir expert. Vous avez besoin de trois gestes, répétés.
Le test des cinq minutes
- Débranchez la souris. Parcourez la page entière au clavier. Voyez-vous toujours où vous êtes ?
- Zoomez à 200 %. Le contenu reste-t-il lisible sans défilement horizontal ?
- Activez le mode contraste élevé de votre système. Rien ne disparaît ?
Ce triple test attrape la majorité des blocages réels. Pas tous, mais la majorité.
Les outils qui aident vraiment
Les extensions de navigateur qui traquent les problèmes de contraste et de structure sont utiles, à une condition : ne pas croire leurs scores. Un score automatique de 90 % ne veut pas dire « accessible ». Ces outils ne détectent qu'environ un tiers des critères réels. Ils ne savent pas si votre texte alternatif est pertinent, ni si votre ordre de lecture a du sens.
Le vrai test, celui qui ne ment pas : ouvrez un lecteur d'écran et essayez d'accomplir une tâche simple. Inscription, recherche, achat. Au bout de deux minutes, vous saurez.
Je me souviens d'un projet où nous avions tout vérifié à l'outil. Score parfait. Puis un collègue malvoyant a tenté de réserver un créneau. Le calendrier était un tableau de div sans en-têtes associés. Il entendait « bouton, bouton, bouton » en boucle. Nous avions perdu deux jours à optimiser des scores et zéro minute à faire le test qui compte.
Faut-il que l'accessibilité soit parfaite dès le premier jour ?
Non. Et cette injonction à la perfection décourage plus de développeurs qu'elle n'en aide.
L'accessibilité est un spectre, pas un interrupteur. Viser la conformité totale sur un produit existant, avec dix ans de dette technique, c'est un projet de plusieurs mois. Le bon plan, c'est de bloquer les régressions et d'améliorer par petites touches.
Concrètement, dans une équipe, ça ressemble à :
- Un linter qui refuse une
divcliquable en revue de code. - Une checklist de trois lignes dans la définition de « terminé » : libellés, clavier, contraste.
- Une revue trimestrielle d'une page critique avec un lecteur d'écran, pas tout le site d'un coup.
Et surtout, corriger le HTML à la source plutôt que d'empiler des correctifs après coup. C'est ce que la SERP ne vous dira pas, parce que ça ne se vend pas comme une astuce : l'accessibilité se gagne dans le code, pas dans les rapports d'audit.
Et le cadre légal dans tout ça ?
Il existe, il est réel, et il vous rattrapera si vous travaillez sur un site public. En France, la loi de 2005 a posé le principe d'accessibilité pour les services publics, avec le RGAA comme référentiel technique. Le secteur privé y arrive par d'autres chemins, notamment par la réglementation européenne.
Mais franchement, si le seul moteur est la peur du contrôle, le résultat sera bâclé. Les sites que j'ai vus réussir leur accessibilité avaient une autre motivation : ils voulaient que ça marche pour tout le monde, et ils avaient rencontré des utilisateurs réels qui bloquaient.
Combien de temps pour rendre un site accessible ?
Il n'y a pas de réponse unique. Sur un projet neuf, compter environ 10 à 15 % de temps de développement supplémentaire si les bases sont posées dès le début. Sur un site existant, tout dépend de la dette accumulée : j'ai vu des refontes de formulaires prendre deux jours, et des refontes de navigation en prendre deux mois.
L'accessibilité nuit-elle au design ?
Non, elle le contraint, et c'est souvent une bonne contrainte. Un contraste correct rend le texte plus lisible pour tout le monde, y compris sur un écran en plein soleil. Des cibles tactiles plus grandes réduisent les erreurs de clic pour tous. Le design accessible est rarement un design dégradé — c'est un design qui a résolu plus de cas.
La prochaine fois qu'un composant vous semble « fini », fermez les yeux et posez la main sur le clavier. Vous saurez en trente secondes ce qu'un audit de trois jours mettrait une semaine à conclure.
