Les notions essentielles d'accessibilité pour les sites internet

Un formulaire de contact où le champ « message » refuse le collage. Un menu déroulant qui se referme dès qu'on relâche la touche. Une image de bannière sans le moindre texte alternatif. Trois détails que personne ne remarque, sauf ceux qui naviguent au clavier, au lecteur d'écran ou avec une loupe logicielle — et pour qui le site devient tout simplement inutilisable.

C'est souvent là que ça coince. On me demande régulièrement de « rendre un site accessible » comme on demanderait une couche de peinture. Or l'accessibilité numérique n'est pas une finition qu'on applique à la fin : c'est une manière de construire dès le départ. Et les notions essentielles tiennent en quelques principes qu'on peut réellement retenir, pas en un pavé de normes.

Les notions essentielles d'accessibilité pour un site internet, sans jargon

Posons une définition simple, parce que le terme est souvent galvaudé. Rendre un site accessible, c'est faire en sorte que tout le monde puisse y accéder à l'information et aux fonctionnalités, quelle que soit la façon dont la personne perçoit, comprend ou interagit avec l'écran. Ça n'a rien d'une faveur accordée à une minorité : c'est le fonctionnement normal d'un service public ou d'un commerce.

Le handicap, d'ailleurs, ne se limite pas à ce qu'on imagine. Handicap visuel, moteur, auditif, cognitif, troubles de l'attention, dyslexie… et puis tout ce qui n'est pas « un handicap » mais produit les mêmes effets : une main dans le plâtre pendant six semaines, un écran en plein soleil, une connexion capricieuse, un utilisateur de 78 ans qui n'a jamais appris à double-cliquer.

L'accessibilité numérique, qui est concerné ?

Techniquement : tout le monde, à un moment ou à un autre de sa vie. La question « qui est concerné » cache souvent une arrière-pensée — « c'est un sujet de niche, non ? ». Réponse courte : non. Une personne sur six environ vit avec un handicap significatif. Ajoutez les aidants, les proches qui accompagnent, et vous obtenez une part de l'audience bien plus large que la plupart des segments marketing qu'on cible avec soin.

Quand on conçoit pour les cas les plus contraints, on améliore l'expérience de tous. Un sous-titrage aide la personne sourde et celle qui regarde une vidéo dans le métro. Un contraste de texte correct sauve les yeux de tout le monde. Un site rapide et lisible au clavier profite autant au power user qu'à celui qui utilise un lecteur d'écran.

Le problème, c'est que ce raisonnement arrive souvent trop tard. J'ai vu des équipes découvrir en phase de recette que leur composant de date-picker était totalement inutilisable au clavier. Refaire le composant à ce stade coûte dix fois le prix d'un composant conçu correctement dès le départ.

Les quatre principes POUR : la grille à garder en tête

Si vous ne devez retenir qu'une seule chose de cet article, gardez ceci. Les référentiels internationaux — les WCAG du W3C — reposent sur quatre piliers. On les résume par l'acronyme POUR.

• Perceptible : l'information doit être accessible aux sens. Un texte alternatif décrit une image, des sous-titres transcrivent une vidéo, le contraste est suffisant.
• Utilisable : tout doit être atteignable et actionnable, notamment au clavier. Pas de fonctionnalité piégée par une souris indispensable.
• Compréhensible : les messages d'erreur sont clairs, la navigation est prévisible, la langue de la page est déclarée.
• Robuste : le code reste interprétable par les technologies d'assistance, aujourd'hui comme demain. C'est là que le HTML sémantique fait toute la différence.

Chacun de ces piliers se décline en trois niveaux de conformité, notés A, AA et AAA. Le niveau AA est celui que visent la plupart des obligations légales — c'est le standard pragmatique, atteignable, qui couvre l'essentiel des besoins réels.

Les bonnes pratiques concrètes qui changent tout

Bon, et en pratique ? Voici les points sur lesquels je vois le plus de gains pour le moins d'effort, ceux qu'on corrige en priorité sur un audit.

1. Un texte alternatif utile pour chaque image porteuse de sens — et un alt vide pour les images purement décoratives, c'est important aussi.
2. Des contrastes de couleur vérifiés, pas estimés à l'œil.
3. Une navigation entièrement possible au clavier, avec un focus visible et logique.
4. Une hiérarchie de titres cohérente : un seul H1, des H2 qui structurent, pas des titres choisis pour leur taille de police.
5. Des formulaires dont chaque champ est associé à son étiquette, avec des erreurs explicites.
6. Des vidéos sous-titrées et, idéalement, une transcription.

Ce dernier point mérite un mot. L'accessibilité des PDF est un angle mort fréquent. Un PDF scanné sans couche de texte est illisible pour un lecteur d'écran, même si le site web autour est impeccable. Combien de collectivités publient leurs délibérations ou leurs formulaires dans des PDF non balisés ? Beaucoup. Corriger le site sans toucher aux documents, c'est repeindre la porte et laisser le mur s'effondrer.

L'accessibilité, une obligation légale qui monte en puissance

Est-ce réellement obligatoire ? Oui, et de plus en plus. En France, le Référentiel général d'amélioration de l'accessibilité, le RGAA, fixe les critères à respecter. Il ne s'invente pas de zéro : il traduit les WCAG en règles testables, adaptées au contexte juridique français.

Le secteur public est soumis à ces exigences depuis plusieurs années déjà, avec une déclaration d'accessibilité obligatoire et la possibilité, pour un usager qui constate un manquement, de saisir une autorité de régulation. Côté privé, le mouvement s'étend : au-delà d'un certain chiffre d'affaires, les grandes entreprises sont concernées, et la tendance générale pousse tout l'écosystème vers les mêmes standards.

Ce qui m'agace, franchement, c'est quand l'accessibilité est traitée comme un risque juridique à minimiser plutôt que comme un investissement. La conformité est une conséquence, pas un objectif. Un site conforme sur le papier mais pénible au quotidien pour un utilisateur de lecteur d'écran n'a rien réglé.

Comment tester l'accessibilité d'un site web ?

Trois niveaux, du plus rapide au plus fiable.

Méthode	Ce qu'elle détecte	Ce qu'elle rate
Outils automatiques (auditeurs intégrés au navigateur)	Contrastes, attributs manquants, structure évidente	Tout ce qui dépend du sens et du contexte
Test manuel au clavier et au lecteur d'écran	Parcours, ordre de tabulation, focus	Ne couvre pas tous les profils
Tests avec de vrais utilisateurs	Les vrais blocages, ceux qu'aucun outil ne voit	Demande du temps et de l'organisation

Les outils automatisés ne repèrent qu'une fraction des problèmes — souvent estimée à un tiers tout au plus. Ils sont utiles pour dégrossir, jamais pour conclure. Le test au clavier, lui, coûte cinq minutes et révèle des choses stupéfiantes : éléments focusables invisibles, ordre de navigation absurde, modales qu'on ne peut pas fermer.

Et puis il y a le test humain, celui qui compte vraiment. J'ai assisté à une session où une utilisatrice de lecteur d'écran a mis quarante secondes à accomplir une action que je pensais triviale, parce que le libellé du bouton disait « cliquez ici ». Quarante secondes. Sur un seul bouton. Ce jour-là, j'ai compris que mes audits « conformes » ne voulaient pas dire grand-chose.

Par où commencer concrètement

Si vous héritez d'un site existant et que le sujet vous tombe dessus, voici l'ordre que je recommande. D'abord un audit pour identifier les blocages majeurs, pas pour viser la conformité totale tout de suite. Ensuite, on traite les fondations : structure HTML, contrastes, navigation clavier, formulaires. Ce sont les corrections à plus fort impact et souvent les moins coûteuses.

Pour le neuf, la logique s'inverse. On intègre les contraintes dans les composants dès la conception, et on teste au fil de l'eau plutôt qu'en fin de projet. Le coût devient marginal. C'est la différence entre construire des rampes d'accès dès les plans et percer une façade après coup.

Reste une question que je me pose encore, après des années sur ce sujet. Pourquoi faut-il une loi pour qu'on se soucie d'utilisateurs qu'on croise tous les jours ? L'accessibilité numérique ne demande pas d'être généreux. Elle demande de se souvenir que derrière chaque écran, il y a quelqu'un qui n'a peut-être pas les mêmes mains, les mêmes yeux ou la même patience que le développeur qui a codé la page. Concevoir pour cet « autre-là », c'est rarement un sacrifice. C'est juste mieux fait.