Accessibilité web : 12 bonnes pratiques à appliquer dès maintenant

Accessibilité web : les bonnes pratiques qui tiennent vraiment en production

Un jour, une utilisatrice m'a envoyé un mail court, presque sec : « votre formulaire de contact, je ne peux pas l'utiliser ». Elle naviguait au clavier, sans souris, et mon menu déroulant de sélection de pays ne s'ouvrait tout simplement pas. Trois ans de développement, des tests à la pelle, et personne n'avait jamais appuyé sur Tab pour vérifier. Ce jour-là, j'ai compris un truc que la plupart des articles sur l'accessibilité web ne disent pas clairement : le problème n'est presque jamais la connaissance des règles, c'est qu'on ne teste pas comme un humain qui n'a pas de souris.

L'accessibilité numérique, concrètement, c'est la capacité d'un site à rester utilisable quand on navigue au clavier, avec un lecteur d'écran, en zoom 200 %, ou avec une connexion médiocre. Le RGAA et les WCAG donnent le cadre. Le reste, c'est de la méthode.

RGAA, WCAG, EN 301 549 : qui impose quoi, et à qui

On me pose souvent la question en réunion, et la réponse tient en une phrase : ce sont trois étages du même immeuble.

Accessibilité numérique : qui est concerné ?

Le cadre français oblige d'abord le secteur public : services de l'État, collectivités, établissements publics, et depuis quelques années les entreprises délégataires de service public. Ces organismes doivent publier une déclaration d'accessibilité et un schéma pluriannuel. Ce n'est pas une recommandation, c'est une obligation avec un recours possible pour l'usager.

Pour le privé, la pression vient d'ailleurs. Le European Accessibility Act a étendu les obligations à de nombreux produits et services vendus dans l'Union (e-commerce, banque, transport, télécommunications), et il est entré en application. Traduction pratique : si vous vendez en ligne à des consommateurs européens, l'accessibilité de votre parcours d'achat n'est plus un sujet de nice-to-have. J'ai vu deux clients refaire leur tunnel de paiement en urgence à cause de ça. Aucun des deux n'était mécontent du résultat, d'ailleurs.

WCAG 2.2 en français : ce qui change vraiment par rapport à 2.1

La version française de la traduction des WCAG 2.2 est disponible, et beaucoup de gens la résument à « neuf nouveaux critères ». En réalité, la grande nouveauté est ailleurs : le critère de taille des cibles (les zones cliquables doivent être assez grandes) et celui sur le focus visible, qui oblige à ne pas supprimer l'indicateur de focus sans le remplacer par quelque chose d'au moins aussi visible.

Et là, franchement, c'est une bonne nouvelle. Parce que le outline: none balancé dans une feuille de style, c'est l'erreur numéro un que je retrouve dans les projets que j'audite. Ça vient presque toujours d'une demande de design du type « le contour bleu autour des boutons est moche ».

Le calendrier que personne ne lit

Le RGAA évolue au rythme des WCAG. La version suivante est annoncée pour fin 2026, avec une phase de consultation et d'harmonisation. Si vous lancez un chantier d'accessibilité maintenant, ne visez pas une conformité figée à un référentiel : visez une base solide qui absorbera les changements. Les critères qui bougent sont marginaux. Les fondations, elles, ne bougent pas.

Les bonnes pratiques d'accessibilité qui rapportent le plus, dans l'ordre

Si vous ne devez traiter que cinq chantiers cette année, prenez ceux-là. Je les classe par ratio effort/impact, pas par ordre d'apparition dans le référentiel.

1. Contrastes et lisibilité : le gain le plus rapide

Le contraste texte/fond est le point où je trouve le plus de non-conformités, et c'est aussi le plus simple à corriger. Une nuance de gris sur blanc qui paraît élégante sur l'écran du designer devient illisible pour une personne malvoyante. Le seuil de référence pour du texte courant est un rapport de 4,5:1, et de 3:1 pour les grands caractères et les éléments d'interface.

J'ai corrigé ça sur un site de presse locale : trois variables CSS, deux heures de travail, et le taux de rebond sur mobile a baissé de 7 % sur les articles longs. Je ne dis pas que c'est uniquement l'accessibilité qui a produit cet effet. Mais l'amélioration de lisibilité y est pour quelque chose, c'est certain.

2. Structure de titres et navigation au clavier

Un lecteur d'écran ne « voit » pas la page : il la parcourt par sauts. Si vos titres sont des <div> stylés en gras plutôt que des <h2>, l'utilisateur n'a aucun point d'ancrage.

Testez ceci sur votre propre site, aujourd'hui :

1. Débranchez la souris. Naviguez jusqu'au menu principal avec Tab uniquement.
2. Faites attention à l'ordre de tabulation : suit-il la logique visuelle, ou part-il dans tous les sens ?
3. Essayez d'ouvrir un sous-menu, de remplir un formulaire, de fermer une modale.
4. Regardez si vous voyez toujours où vous êtes. C'est le critère de focus visible.

Spoiler : sur la majorité des sites que je teste, on se perd au bout de dix secondes. Pas parce que les développeurs sont mauvais, mais parce que personne ne fait ce test.

3. Alternatives textuelles et qualité du contenu

L'alt d'une image n'est pas une case à remplir pour faire plaisir à un audit. « image-1.jpg » ne dit rien, et « photo d'illustration » non plus. Décrivez la fonction de l'image : si elle porte une information, décrivez l'information ; si elle est purement décorative, laissez l'attribut vide pour que le lecteur d'écran l'ignore.

Bon, et ce point concerne directement les rédacteurs, pas seulement les développeurs. C'est d'ailleurs une remarque que je répète à chaque formation : l'accessibilité n'est pas un sujet technique, c'est un sujet d'équipe.

Profil	Ce qui le concerne en priorité	Piège fréquent
Développeur	Structure HTML sémantique, focus, formulaires, ARIA	Utiliser ARIA là où du HTML natif suffit
Designer	Contrastes, taille des cibles, états de focus, zoom 200 %	Supprimer le focus au nom de l'esthétique
Rédacteur	Alternatives textuelles, intitulés de liens, titres clairs	Écrire « cliquez ici » comme libellé de lien
Chef de projet	Priorisation, déclaration d'accessibilité, recette	Traiter l'accessibilité en fin de projet

Tester son site : ce que les outils ne verront jamais

Lighthouse, Axe, Wave. Ces outils sont utiles. Ils sont aussi la principale source de fausse confiance que je rencontre.

Tests automatisés ou tests utilisateurs ?

Un outil automatique repère les problèmes mécaniques : une image sans alt, un contraste insuffisant calculable, un champ sans étiquette. En pratique, sur les audits que j'ai menés, ça représente environ un tiers des non-conformités réelles. Le reste demande un jugement humain.

Un exemple concret : aucun outil ne vous dira qu'un intitulé de bouton « Valider » est ambigu quand trois formulaires différents de la même page utilisent le même mot. Un lecteur d'écran énumère les boutons hors contexte. L'utilisateur entend « Valider, Valider, Valider » et ne sait plus lequel correspond à quoi. Il faut un test manuel pour s'en rendre compte.

Ma méthode, quand j'audite, tient en trois passages :

• Automatique, pour dégager le bruit de fond en une heure.
• Clavier seul, sur les parcours critiques uniquement (accueil, recherche, panier, contact).
• Lecteur d'écran — NVDA côté Windows, VoiceOver côté macOS et iOS — sur une seule tâche, mais jusqu'au bout.

Le troisième passage est celui qui change votre façon de concevoir. Je n'ai jamais vu quelqu'un tester au lecteur d'écran une fois et continuer à coder comme avant. C'est un peu brutal, mais c'est efficace.

Comment prioriser quand tout semble urgent

Un rapport d'audit, ça fait facilement quarante pages. Personne ne le lit en entier. Ce qui marche, c'est de transformer chaque non-conformité en ticket avec un impact utilisateur, un effort estimé, et un critère de recette. Trois colonnes, pas plus.

Ce qui ne marche pas : livrer un PDF de quarante pages à une équipe et attendre. J'ai fait cette erreur une fois. Le document a dormi six mois dans un drive partagé. Depuis, je livre toujours un fichier de tickets importable, trié par sévérité.

Les erreurs que je vois (et refais) encore

L'ARIA mal utilisé est probablement la plus vicieuse. La règle est simple, même si elle est souvent ignorée : la première règle d'ARIA, c'est de ne pas utiliser ARIA. Un <button> natif gère le clavier, le focus et les annonces tout seul. Un <div role="button"> vous oblige à réimplémenter tout ça à la main, et vous oublierez la touche Entrée. Je l'ai fait. Plusieurs fois.

Deuxième erreur : croire qu'un audit ponctuel suffit. L'accessibilité se dégrade en production, silencieusement. Une nouvelle modale non testée, une refonte de formulaire, un composant importé d'une bibliothèque externe. Sans test de non-régression dans la recette, vous revenez au point de départ en un trimestre.

Troisième erreur, plus insidieuse : traiter l'accessibilité comme un chantier. Ce n'est pas un projet avec une date de fin. C'est une contrainte de qualité, comme la sécurité ou la performance. Personne ne dit « on a fini la sécurité ». Eh bien, l'accessibilité, c'est pareil.

Par où commencer demain matin

Ne lancez pas un audit complet de trois cents pages. Prenez votre parcours le plus utilisé, celui qui convertit, et testez-le au clavier. Notez tout ce qui bloque. Corrigez les trois points les plus graves. Recommencez le mois suivant sur un autre parcours.

Et si vous ne faites qu'une seule chose : installez un lecteur d'écran gratuit et parcourez votre page d'accueil. Dix minutes, pas plus. Ce que vous entendrez vous marquera plus que n'importe quel référentiel.

Il reste une question que je n'arrive pas à trancher, d'ailleurs. Est-ce qu'un site réellement accessible à 100 % existe quelque part ? Je n'en ai jamais vu. J'ai vu des sites honnêtes, qui publient leur déclaration, listent leurs non-conformités restantes et les corrigent une par une. C'est peut-être ça, la bonne pratique qui compte le plus : arrêter de prétendre que c'est fait, et montrer où ça ne l'est pas encore.