Un site e-commerce m'a appelé en panique : leur taux de conversion mobile s'était effondré de 3,1 % à 1,4 % en deux mois après une refonte. Le développeur avait tout misé sur l'esthétique. Formulaire d'inscription en trois étapes avec champs sans étiquette visible, boutons gris clair sur fond blanc, carrousel qui défilait tout seul. J'ai branché un lecteur d'écran sur leur page panier et j'ai éclaté de rire jaune. Le bouton "valider ma commande" annonçait à voix haute : "lien, lien, lien". Un aveugle ne pouvait tout simplement pas acheter. Et devinez quoi ? Les utilisateurs voyants galéraient aussi, mais ils ne se plaignaient pas, ils partaient.
L'accessibilité web, ce n'est pas une faveur qu'on fait à une minorité. C'est la qualité de base de votre code, de vos contrastes, de votre navigation. Quand vous respectez les bonnes pratiques, vous récupérez des clients que vous perdiez sans le savoir. Voici comment je procède concrètement, ce que j'ai appris en ratant des audits, et les pièges qui reviennent sur tous les projets.
Points clés à retenir
- Le RGAA et les WCAG 2.1 niveau AA ne sont pas des contraintes décoratives : ce sont des critères testables, un par un.
- 80 % des problèmes d'accessibilité se règlent avec du HTML correct, avant même de toucher au CSS.
- Un audit automatique détecte environ un tiers des blocages réels. Le reste se trouve au clavier et au lecteur d'écran.
- Depuis la loi française et l'article 47, les sites de service public et les grandes entreprises ont des obligations datées et une déclaration d'accessibilité à publier.
- Priorisez : navigation, formulaires, contrastes, alternatives textuelles. Le reste attend.
- Corriger un site existant coûte souvent moins cher qu'une refonte complète, sauf si le socle HTML est pourri.
Accessibilité web : les bonnes pratiques qui changent vraiment les choses
La plupart des articles sur le sujet vous noient sous vingt règles générales. Moi je fonctionne par ordre d'impact. Parce qu'un site parfaitement accessible prend des mois, et que vous n'avez pas des mois.
Commencez par le HTML. Toujours.
J'ai vu un développeur passer deux semaines sur des attributs ARIA pour un menu déroulant, alors que le menu était construit avec des div et des span cliquables. Il avait mis la charrue avant les bœufs. Un button natif gère le focus, l'activation au clavier, le rôle annoncé aux lecteurs d'écran. Gratuitement. Un div avec un onclick ne fait rien de tout ça.
Concrètement :
- Des titres hiérarchisés (
h1,h2,h3) sans sauter de niveau, pour que la structure soit comprise au lecteur d'écran. - Un seul
h1par page, qui décrit l'objet de la page. - Des listes (
ul,ol) pour tout ce qui est une énumération. Pas des paragraphes avec des tirets. - Des boutons pour les actions, des liens pour la navigation. Ce n'est pas la même chose, et les technologies d'assistance les annoncent différemment.
- Des régions landmarks (
header,nav,main,footer) pour permettre de sauter directement au contenu.
Je vous assure, ce seul paragraphe règle une bonne moitié des non-conformités qu'on trouve sur le terrain. Le reste, c'est du soin.
Alternatives textuelles et images : le piège du "logo société"
Une alternative textuelle, c'est le texte qu'un lecteur d'écran prononce à la place d'une image. Et là, je vois deux erreurs symétriques. Soit l'attribut alt manque complètement, soit il est rempli avec du remplissage inutile du style "image_banque_1234.jpg".
La règle que j'applique : si l'image porte une information, je la décris. Si elle est purement décorative, je mets un alt="" vide pour qu'elle soit ignorée. Un logo cliquable qui ramène à l'accueil aura un alt="Retour à l'accueil – Nom du site", pas juste alt="logo". Une icône de panier à côté du texte "Panier" n'a pas besoin d'alternative, le texte suffit.
Astuce que j'ai adoptée après avoir pesté plusieurs fois : fermez les yeux et faites-vous lire la page. Si vous entendez "image, image, image" à la suite, vous avez du travail.
Contrastes : le critère le plus simple à vérifier, le plus souvent raté
Le ratio de contraste minimum, c'est 4,5:1 pour le texte normal et 3:1 pour le grand texte, selon les WCAG 2.1 niveau AA. Un gris clair sur blanc, ça passe mal. Un blanc sur un jaune vif, ça ne passe pas du tout.
Le piège que personne n'anticipe : les états de survol et de focus. Un bouton bleu foncé sur fond blanc peut être parfaitement conforme au repos, et devenir illisible quand la souris passe dessus. Je vérifie systématiquement les quatre états : normal, survol, focus, actif. C'est fastidieux, mais c'est deux minutes par composant.
Formulaires : là où vous perdez réellement des gens
Les formulaires, c'est mon terrain de chasse préféré. Un champ sans label associé, c'est un champ muet pour un lecteur d'écran. Un message d'erreur uniquement signalé par une bordure rouge, c'est une erreur invisible pour qui ne distingue pas les couleurs.
Ma check-list :
- Chaque champ a un
labellié parfor/id. - Les erreurs sont annoncées par du texte, pas seulement par une couleur ou une icône.
- Le focus du clavier suit l'ordre logique de lecture.
- Les champs obligatoires sont indiqués textuellement, pas par un astérisque dont la signification n'est jamais donnée.
- Un groupe de boutons radio partage un
fieldsetet unlegend.
Sur un projet de réservation en ligne, corriger ces cinq points a fait remonter le taux de complétion du formulaire de 62 % à 79 % en trois semaines. Aucune refonte, juste des étiquettes et des messages clairs. Les utilisateurs valides voyants en ont profité autant que les autres.
RGAA, WCAG 2.1 : quel référentiel suivre, et quelles obligations ?
Deux référentiels cohabitent, et on me pose la question à chaque mission. La réponse courte : ils ne s'opposent pas, ils s'emboîtent.
| Référentiel | Origine | Usage | Niveau |
|---|---|---|---|
| WCAG 2.1 | W3C, international | Cadre de référence mondial | A, AA, AAA |
| RGAA | France, DGIP | Méthode de test et déclaration | Aligne la conformité sur le niveau AA |
| EN 301 549 | Union européenne | Cadre pour les marchés publics | Renvoie aux WCAG |
Le RGAA (Référentiel général d'amélioration de l'accessibilité) n'ajoute pas de règles techniques : il traduit les WCAG en une liste de critères testables, avec une méthode de test. C'est ce que vous utiliserez pour rédiger une déclaration d'accessibilité valable.
Qu'est-ce que la loi impose concrètement ?
En France, l'article 47 de la loi du 11 février 2005 sur l'égalité des droits et des chances a posé le principe. Le décret d'application a fixé les obligations : les services de communication publique en ligne de l'État, des collectivités, des établissements publics et des entreprises délégataires doivent être accessibles, avec une déclaration d'accessibilité publiée et un schéma pluriannuel.
Pour les entreprises privées, le cadre s'est étendu par étapes, notamment sur les obligations de mise en accessibilité des services au public et via la directive européenne sur l'accessibilité des produits et services. Si vous doutez de votre statut, le plus sûr est de consulter votre direction juridique avant d'engager des dépenses.
Comment tester sans se ruiner en outils ?
Je fais deux passes. La première automatique : un validateur de contraste, un détecteur d'attributs manquants, un analyseur de structure de titres. Rapide, utile, mais insuffisant. Ces outils attrapent environ un tiers des problèmes. Le reste ne se voit qu'à la main.
La deuxième passe, c'est la seule qui compte vraiment : je navigue exclusivement au clavier (Tab, Entrée, flèches). Puis je fais lire la page à un lecteur d'écran. Et si le budget le permet, je fais tester par une personne en situation de handicap réelle. Rien ne remplace ça. J'ai cru pendant longtemps que ma navigation au clavier suffisait. J'avais tort, et je l'ai découvert en regardant quelqu'un se battre pendant cinq minutes pour sortir d'un menu que je trouvais parfaitement logique.
Corriger un site existant ou tout refaire ?
Question à laquelle personne ne répond franchement. Mon avis, tranché : corriger d'abord, refondre seulement si le socle HTML est cassé. Quand la structure sémantique existe déjà, on répare en général avec un budget de plusieurs jours à quelques semaines selon la taille du site, pas de plusieurs mois.
Si tout est en div et en JavaScript qui reconstruit la page à la volée, alors une refonte ciblée des composants critiques (navigation, formulaires, modales) est souvent plus rentable que du rafistolage. J'ai fait les deux. Le rafistolage m'a coûté moins cher, mais il laisse des cicatrices dans le code.
Ce que j'ai fini par comprendre
L'accessibilité web n'est pas un chantier qu'on termine un jour et qu'on range. C'est une discipline qui s'intègre au processus : un alt écrit au moment où l'on pose l'image, un contraste vérifié au moment où l'on choisit la couleur, un test au clavier avant chaque mise en production.
La question que je vous laisse : combien de personnes ont abandonné votre dernier tunnel de commande sans que vous le sachiez, simplement parce qu'un bouton ne se laissait pas atteindre ? Vous ne le saurez jamais avec certitude. Par contre, vous pouvez le réduire à presque rien. Et ça commence par regarder votre propre site avec un clavier, pas une souris, ce soir.
