La semaine dernière, une lectrice m'a écrit. Elle venait de recevoir un mail d'un cabinet de conseil : son site e-commerce allait « bientôt » devoir être conforme, sinon elle risquait une sanction. Elle voulait savoir si c'était vrai. C'était en partie vrai, en partie faux, et complètement déformé. Mais ça a eu le mérite de poser la bonne question : l'accessibilité web, c'est un sujet juridique ou un sujet d'usage ? Je pense que la réponse est : les deux, mais dans un ordre précis. On ne rend pas un site utilisable par tous pour cocher une case.
Quand j'ai commencé à m'intéresser à l'accessibilité numérique, je la voyais comme une contrainte technique. Un truc qu'on ajoute en fin de projet, à contrecœur, avec des attributs alt bâclés et des contrastes vérifiés à la va-vite. Trois ans plus tard, mon avis a basculé. Pas parce que la loi a changé. Parce que j'ai vu des utilisateurs se disputer avec mes interfaces.
Points clés à retenir
- L'accessibilité web consiste à rendre un site utilisable par tout le monde, y compris les personnes en situation de handicap, sur tous les supports et dans tous les contextes.
- Le cadre légal français s'appuie sur le RGAA, qui découle des WCAG internationaux.
- Les obligations concernent surtout le secteur public et les grandes entreprises, mais les bonnes pratiques profitent à tout le monde.
- Un audit d'accessibilité se fait en plusieurs passes : automatique, puis manuelle, puis tests utilisateurs.
- La majorité des problèmes détectés sont corrigeables en moins de deux heures chacun.
Accessibilité web : de quoi parle-t-on vraiment (et pas seulement pour les aveugles)
Le raccourci le plus répandu : « accessibilité = lecteur d'écran ». Faux. Le handicap visuel total ne représente qu'une fraction des situations concernées. Quand je fais passer un rapide questionnaire en début de projet à mes clients, je leur demande de lister qui, selon eux, est « handicapé numériquement ». Ils citent systématiquement les personnes aveugles. Rarement celles qui les concernent vraiment.
Qui est réellement concerné par l'accessibilité numérique ?
Tout le monde, à des degrés divers. Un utilisateur qui a une main dans le plâtre pendant six semaines. Quelqu'un qui porte des lunettes de soleil en plein soleil et ne distingue plus le gris sur gris de votre menu. Une personne dyslexique qui perd le fil après trois lignes trop serrées. Un cadre pressé qui navigue au clavier seul parce que sa souris est morte. Un senior dont la vue baisse, doucement, sans qu'aucun diagnostic ne tombe.
J'ajoute une catégorie qu'on oublie : les situations temporaires. Une coupure de connexion, un écran fissuré, un environnement bruyant. L'accessibilité, ce n'est pas un public séparé. C'est un spectre dans lequel vous entrez et sortez, plusieurs fois par jour, sans forcément le remarquer.
Cette réalité a une conséquence pratique : quand vous corrigez un problème pour une personne malvoyante, vous le corrigez souvent pour la moitié de vos visiteurs. Les contrastes renforcés, les libellés explicites, la navigation clavier propre — ce sont des améliorations universelles. Pas des concessions.
Accessibilité : ce que dit vraiment la loi (et ce qu'elle ne dit pas)
En France, le cadre repose sur la loi de 2005 pour le secteur public, élargie en 2019 aux entreprises privées réalisant un chiffre d'affaires supérieur à 250 millions d'euros. Le référentiel technique s'appelle le RGAA, pour Référentiel général d'amélioration de l'accessibilité. Il décline en critères vérifiables les quatre grands principes des WCAG : perceptible, utilisable, compréhensible, robuste.
Est-ce qu'on risque vraiment une sanction ?
Oui, mais le risque n'est pas là où on l'imagine. Les amendes existent dans les textes, elles tombent rarement. En revanche, deux choses se produisent régulièrement :
- Un appel d'offres public vous élimine parce qu'aucune déclaration d'accessibilité n'est publiée sur votre site.
- Un service client reçoit une réclamation d'un utilisateur qui ne peut pas accéder à sa facture en ligne — et là, c'est votre image qui prend le coup, pas votre compte bancaire.
J'ai vu ce scénario chez un client du secteur médico-social. Pas de sanction. Mais trois mois de mauvaise presse locale après qu'une association a publié un signalement. Le coût réel, ce n'est presque jamais l'amende. C'est le temps perdu à éteindre l'incendie.
Tester l'accessibilité de son site : la méthode que j'utilise
Un audit automatique ne trouve qu'à peu près un tiers des problèmes d'accessibilité réels. C'est la leçon la plus contre-intuitive de mes premières années. Les outils comme WAVE, Axe ou Lighthouse dénichent les erreurs simples — attributs manquants, contrastes insuffisants, hiérarchie de titres chaotique. Ils ne détectent pas un parcours clavier illogique, un piège au focus, une alternative textuelle techniquement présente mais sémantiquement vide.
Trois passes, dans cet ordre
- Passe automatique — cinq minutes, un plugin, une liste brute. Utile pour dégrossir, insuffisant pour conclure.
- Passe manuelle sur les parcours clés — connexion, recherche, achat, contact. Testez tout à la souris d'abord, puis clavier seul, puis avec un lecteur d'écran. C'est là que vous trouvez les vrais problèmes.
- Tests utilisateurs — deux ou trois personnes en situation de handicap sur vos parcours critiques. Ce que vous apprenez là vaut dix rapports d'audit.
Sur un projet de refonte de site institutionnel, la passe automatique avait sorti 87 alertes. J'ai passé deux jours à les traiter. La passe manuelle a fait remonter 11 problèmes supplémentaires que personne n'avait vus — dont un menu burger complètement inaccessible au clavier. Le problème n'était pas dans le code. Il était dans l'ordre d'apparition des éléments focusables. Aucun outil ne vous le dira.
Avouons-le : j'ai cru longtemps que l'audit automatique suffisait. J'ai livré un site « conforme » qui bloquait une utilisatrice non-voyante dès la page d'accueil. La honte. Depuis, je ne facture plus d'audit sans passe manuelle.
Les bonnes pratiques d'accessibilité qui changent tout (et qui coûtent peu)
Il n'existe pas de recette magique. Il existe des gestes simples, appliqués systématiquement. Voici ceux sur lesquels je reviens à chaque projet, dans l'ordre où ils créent le plus d'impact.
| Action | Temps moyen sur un site existant | Impact utilisateur |
|---|---|---|
| Alternatives textuelles sur les images porteuses de sens | 2 à 4 heures | Élevé (lecteurs d'écran, SEO) |
| Contraste minimum 4,5:1 sur les textes courants | 1 à 3 heures (charte CSS) | Très élevé (tous publics) |
| Navigation clavier complète et focus visible | 4 à 8 heures | Élevé, souvent oublié |
| Formulaires avec label associés et messages d'erreur explicites | 3 à 6 heures | Très élevé (conversion incluse) |
| Structure de titres hiérarchisée (h1, h2, h3 sans saut) | 1 à 2 heures | Moyen à élevé |
| Sous-titres et transcription sur les vidéos | Variable selon volume | Élevé (et contexte silencieux) |
L'erreur fréquente avec ARIA
ARIA, pour Accessible Rich Internet Applications, est une spécification qui permet de donner des rôles, des états et des propriétés aux éléments HTML. Elle est puissante. Elle est aussi piégeuse. La règle d'or, que je répète comme un mantra à mes développeurs : pas d'ARIA plutôt qu'un ARIA mal posé. Un role="button" sur une div qui n'écoute pas le clavier, c'est pire que rien. Vous annoncez à l'utilisateur un bouton qui ne fait rien.
Le HTML natif fait 90 % du travail. Un vrai <button>, un vrai <nav>, une vraie <label> attachée à son champ. Le reste, c'est de la décoration.
Pourquoi ça vaut le coup, même sans obligation légale
Trois ans après mes premiers audits, j'ai arrêté de présenter l'accessibilité comme un sujet de conformité. Je la présente comme un sujet de qualité. Voilà ce que j'observe, concrètement :
- Les formulaires deviennent plus clairs — et le taux d'abandon baisse mécaniquement.
- Les contrastes renforcés font remonter le temps passé sur page, en particulier sur mobile.
- Les structures de titres propres améliorent l'indexation, et donc la visibilité organique.
- Le code devient plus sémantique, plus maintenable, plus facile à reprendre par une autre équipe.
- Le support client reçoit moins de questions basiques parce que les interfaces s'expliquent d'elles-mêmes.
Aucune de ces améliorations ne relève de la magie. Elles relèvent de la rigueur. Et elles profitent à tout le monde, pas seulement aux personnes handicapées.
Par où commencer cette semaine
N'attendez pas un audit complet pour bouger. Prenez une heure. Ouvrez votre site. Débranchez votre souris. Essayez de créer un compte, de chercher un produit, de contacter le service client — uniquement au clavier. Vous verrez en dix minutes ce qu'un rapport de cent pages mettrait trois semaines à vous expliquer.
Ensuite, prenez trois pages critiques et faites-les passer au crible : contraste, alternatives textuelles, structure de titres. Corrigez ce que vous pouvez. Notez ce que vous ne pouvez pas. Recommencez dans un mois.
L'accessibilité web n'est pas un chantier qu'on termine. C'est une manière de construire. Et franchement, une fois qu'on a pris l'habitude, revenir en arrière devient impossible — pas par principe, par confort.
La vraie question n'est pas « suis-je conforme ? ». C'est : « qui, aujourd'hui, n'arrive pas à utiliser mon site ? ». Si vous ne savez pas répondre, vous avez votre prochaine tâche.
