Accessibilité web : rendez votre site utilisable par tous

Accessibilité web : et si votre site excluait une personne sur cinq sans que vous le sachiez ?

La scène se répète à chaque audit que je mène. Un client m'invite à tester son site flambant neuf, refonte à 40 000 euros, animations subtiles, palette de couleurs signée par une agence. Je branche un lecteur d'écran. Je navigue au clavier. Au bout de deux minutes, le directeur me regarde et me dit, un peu pâle : « Donc une personne aveugle ne peut pas commander chez nous ? » Non. Elle ne peut pas. Et elle n'est pas la seule.

L'accessibilité numérique n'est pas un supplément d'âme qu'on ajoute en fin de projet quand il reste du budget. C'est la différence entre un site que tout le monde peut utiliser et un site qui trie ses visiteurs à l'entrée. Le problème, c'est que ce tri se fait silencieusement. Personne ne se plaint. Les gens partent, tout simplement.

Accessibilité d'un site internet et handicap : qui est vraiment concerné ?

On m'oppose souvent le même argument : « Mon audience n'a pas de handicap. » Je réponds toujours la même chose. Vous n'en savez rien. Et même si c'était vrai, vous passez à côté du sujet.

Handicap permanent, temporaire, situationnel : la distinction qu'on oublie

C'est le point que je vois le moins bien traité, et pourtant c'est celui qui débloque les réticences en réunion. Le handicap n'est pas une catégorie fixe. Il se décline en trois couches.

• Permanent : cécité, surdité, paralysie, troubles dys, daltonisme.
• Temporaire : un bras cassé pendant six semaines, une opération de la cataracte, une sinusite qui bouche les oreilles. Personne ne se considère « handicapé » — et pourtant, personne ne peut utiliser votre menu déroulant.
• Situationnel : vous êtes dans le métro, une main sur la barre, l'autre sur le téléphone. Vous êtes en plein soleil, écran illisible. Vous êtes dans un open space bruyant et vous ne pouvez pas lancer le son d'une vidéo.

Ce dernier cas concerne tout le monde. Absolument tout le monde. Quand j'explique ça, la conversation change de ton. L'accessibilité n'est plus une obligation morale abstraite, c'est de la robustesse produit.

Qui est concerné par l'accessibilité numérique ?

La réponse honnête : vous, vos collègues, vos clients, votre famille. Les personnes en situation de handicap représentent une part importante de la population — plusieurs millions en France — mais si on ajoute le temporaire et le situationnel, on parle de la quasi-totalité des internautes à un moment ou à un autre de leur journée.

Un exemple que je donne souvent en formation : un formulaire de contact avec un champ obligatoire marqué uniquement par une bordure rouge. Une personne daltonienne ne voit rien. Une personne sur mobile en extérieur ne voit rien non plus. Le correctif est identique pour les deux : ajouter un texte, une icône, un message clair. Un seul fix, deux publics servis.

Accessibilité d'un site web : quelle est votre obligation réelle ?

Beaucoup de dirigeants vivent avec une idée floue. « Il y a une loi, un truc avec le RGAA, ça concerne le public, on verra plus tard. » Voyons ça précisément, parce que le flou coûte cher.

Le RGAA : ce que dit le cadre français

Le RGAA — Référentiel général d'amélioration de l'accessibilité — est la déclinaison française des WCAG, les règles internationales du W3C. Il fournit une grille de critères testables. C'est important : le RGAA ne dit pas « soyez gentil avec les utilisateurs », il dit « ce critère est conforme ou non », avec une méthode de test pour chaque point.

L'obligation a d'abord visé le secteur public, il y a une vingtaine d'années. Elle s'est ensuite étendue à certaines entreprises privées, notamment au-delà d'un seuil de chiffre d'affaires. Le calendrier d'application s'étale, et c'est là que beaucoup se trompent : ils croient avoir le temps, alors que le texte est déjà en vigueur pour une partie des acteurs.

Le RGAA évolue : ne suspendez pas vos chantiers

Voilà un angle que je n'ai vu nulle part ailleurs, et il m'agace à chaque fois. Une nouvelle version du référentiel est en préparation, avec une publication attendue à l'horizon de la fin 2026. J'ai vu des équipes s'en servir comme prétexte pour geler leur mise en conformité : « On attend la nouvelle version, sinon on va devoir tout refaire. »

C'est une erreur coûteuse. Les fondamentaux ne bougeront pas. Contraste, navigation clavier, alternatives textuelles, structure de titres : ces bases restent identiques d'une version à l'autre. Ce qui change, ce sont des critères à la marge et la méthode de test. Si vous attendez, vous accumulez de la dette sur des points qui ne changeront jamais.

Mon conseil, et je le répète à chaque client : commencez maintenant sur les fondamentaux. Vous ajusterez la marge plus tard.

Les bonnes pratiques d'accessibilité web qui changent vraiment la donne

Je ne vais pas vous livrer une liste de 50 points. Vous n'en retiendrez aucun. Je préfère celles qui, sur mes propres projets, ont produit le plus d'effet pour le moins d'effort — et une ou deux qui m'ont donné du fil à retordre.

Le contraste : le gain le plus rapide, et le plus négligé

Sur un site que j'ai repris, un texte gris clair sur fond blanc affichait un ratio de contraste autour de 2,5 pour 1. Le minimum recommandé est nettement plus élevé pour du texte courant. Correction : j'ai assombri deux variables CSS. Durée de l'intervention : vingt minutes. Résultat : les retours utilisateurs sur la lisibilité ont augmenté de façon nette dans les semaines suivantes, y compris de la part de personnes sans aucun handicap déclaré.

Vingt minutes. C'est tout.

La navigation au clavier : le test que tout le monde saute

Débranchez votre souris. Essayez de commander un produit, de remplir un formulaire, de fermer une fenêtre modale. Si vous êtes bloqué, un utilisateur qui navigue au clavier l'est aussi — et il y en a beaucoup plus que vous ne le pensez, ne serait-ce que parce que le clavier reste parfois plus rapide que la souris pour les utilisateurs experts.

Le piège classique : le focus qui disparaît. Une équipe avait supprimé l'outline du focus parce que « c'était moche ». Résultat, impossible de savoir où on se trouvait dans la page. La correction n'a pas consisté à le remettre tel quel, mais à créer un style de focus visible et esthétique. On peut faire les deux.

La structure de titres : invisible à l'œil, essentielle au lecteur d'écran

Un lecteur d'écran ne « voit » pas votre mise en page. Il lit la structure sémantique. Si vous utilisez un div stylé en gros gras pour faire un titre, il ne comprend rien. Si vous enchaînez les niveaux de titre n'importe comment — un niveau 1, puis un niveau 4 — il perd la carte.

La bonne pratique tient en une phrase : un seul titre principal par page, une hiérarchie qui descend sans sauter d'étape, et des titres qui décrivent réellement le contenu. Un titre qui dit « Bienvenue » n'informe personne.

Tester l'accessibilité de son site : la méthode que j'utilise

Question qu'on me pose systématiquement en fin de mission : « On est conformes à combien de pourcents ? » Ma réponse déçoit souvent. Le pourcentage seul ne veut rien dire si on ne précise pas la méthode.

Ce que les outils automatiques détectent — et ce qu'ils ratent

Les extensions de navigateur et les analyseurs automatiques repèrent une partie des problèmes : contrastes faibles, attributs d'image manquants, labels de formulaire absents. C'est utile pour dégrossir, et rapide. Mais ces outils ne savent pas si une alternative textuelle a du sens. Ils ne savent pas si l'ordre de tabulation suit une logique. Ils ne savent pas si un message d'erreur est compréhensible.

Je compare souvent ça à un détecteur de fumée. Il vous prévient qu'il y a un problème. Il ne vous dit pas pourquoi la maison a brûlé.

L'audit manuel et le test avec de vrais utilisateurs

La partie qui compte vraiment se fait à la main. Navigation clavier sur tous les parcours critiques. Lecture d'écran sur les pages clés. Zoom à 200 % pour vérifier que rien ne se chevauche. Et, quand c'est possible, un test avec des personnes en situation de handicap — c'est là que tombent les problèmes que personne n'avait anticipés.

Sur un projet, nous avions passé tous les tests automatiques. Score excellent. Un test utilisateur avec une personne aveugle a révélé qu'un carrousel d'accueil était techniquement accessible mais comportait onze diapositives qui défilaient automatiquement, sans possibilité de pause. Techniquement conforme. Inutilisable en pratique.

Comparatif des méthodes de test

Méthode	Ce qu'elle détecte	Temps nécessaire	Limite principale
Outil automatique	Contrastes, attributs manquants, structure HTML basique	Quelques minutes	Ne juge jamais la pertinence du contenu
Test clavier manuel	Ordre de tabulation, focus visible, pièges au clavier	Une à deux heures selon le site	Ne couvre pas les utilisateurs de lecteurs d'écran
Lecture d'écran	Structure sémantique, sens des alternatives, cohérence de navigation	Une demi-journée par parcours complexe	Demande une vraie maîtrise de l'outil
Test utilisateur réel	Problèmes d'usage imprévus, frustrations concrètes	Plusieurs jours d'organisation	Coût et logistique

Les erreurs que je vois le plus souvent (et que j'ai commises)

Je ne vais pas faire semblant d'avoir toujours bien fait. Sur mon premier gros projet accessible, j'étais persuadé que cocher la case « alt » sur toutes les images suffisait. J'avais tort, et de loin.

Confondre alternative textuelle et remplissage

Une image décorative doit avoir un attribut alternatif vide — pour que le lecteur d'écran l'ignore. Une image informative doit décrire l'information, pas l'image. « Image de graphique » n'aide personne. « Ventes en hausse de 30 % au dernier trimestre » informe. J'ai mis des mois à comprendre cette distinction, et je vois encore des sites qui écrivent « logo » comme alternative pour un logo cliquable menant à l'accueil.

Traiter l'accessibilité à la fin

C'est l'erreur la plus chère. Quand l'accessibilité arrive après la livraison, chaque correction rouvre des arbitrages de design, de code et de contenu. Quand elle arrive dès la conception, elle coûte une fraction du prix. J'ai chiffré l'écart sur un projet : environ trois fois plus cher en correction tardive qu'en intégration en amont. Ce n'est pas une donnée universelle, c'est mon relevé de mission — mais il est cohérent à chaque fois que je le refais.

Croire que l'outil remplace la compétence

Acheter une licence d'audit automatique ne rend pas une équipe accessible. La compétence s'installe par la pratique, la formation, et une personne référente qui connaît le sujet. Sans ça, les problèmes reviennent dès la prochaine mise en production.

Et si l'accessibilité était votre meilleur argument de qualité ?

Un site accessible est un site plus rapide, mieux structuré, plus lisible, mieux référencé, plus simple à maintenir. Ce n'est pas une coïncidence : les contraintes de l'accessibilité forcent les bonnes décisions techniques que l'on repousse d'habitude.

La vraie question n'est donc pas « combien ça coûte ». Elle est : combien de visiteurs ont déjà renoncé sans rien dire, et combien continueront tant que la mise en conformité reste un projet « pour plus tard ».

Fermez votre souris. Naviguez dans votre propre tunnel de commande. Vous saurez en cinq minutes si la mise en conformité risque d'être un chantier… ou une formalité.