Les Applis

Accessibilité web : les bonnes pratiques à adopter dès maintenant

Un site magnifique au clavier ? Impossible d'en sortir. L'accessibilité web ne se coche pas en fin de projet : elle se construit dès le HTML. Découvrez les bonnes pratiques qui changent vraiment les choses.

Accessibilité web : les bonnes pratiques à adopter dès maintenant

Un jour, un développeur m'a envoyé un site "terminé". Design impeccable, animations fluides, score Lighthouse de 98. Je l'ai ouvert au clavier. Impossible de sortir du menu. La touche Tab tournait en boucle entre quatre liens, et le formulaire de contact était un cul-de-sac. Ce site était magnifique pour une partie de vos visiteurs, et une porte claquée au nez pour une autre.

C'est tout le problème de l'accessibilité web. On la traite comme une case à cocher en fin de projet, alors qu'elle se joue dans une dizaine de décisions prises bien plus tôt. Et les bonnes pratiques à adopter ne sont pas si nombreuses. Elles sont juste exigeantes.

Points clés à retenir

  • L'accessibilité se construit dans le HTML, pas dans une couche de correctifs ajoutée à la fin.
  • Quatre principes structurent tout : perceptible, utilisable, compréhensible, robuste.
  • Les contrastes, les textes alternatifs et la navigation clavier règlent la majorité des blocages réels.
  • Un audit automatique détecte environ un tiers des problèmes, jamais plus.
  • Les tests avec de vrais utilisateurs en situation de handicap restent irremplaçables.
  • Un site accessible est presque toujours un site plus rapide et mieux référencé.

Les bonnes pratiques d'accessibilité web qui changent vraiment les choses

Avant de parler de normes, parlons de ce qui casse. Dans mon expérience, quand on ouvre un site aux technologies d'assistance, ce ne sont pas cinquante problèmes qui remontent. Ce sont cinq ou six erreurs récurrentes, répétées sur chaque page.

Les corriger rapporte plus que n'importe quel chantier de refonte.

Commencer par la structure sémantique

Un lecteur d'écran ne "voit" pas votre page. Il la parcourt comme une table des matières. Si vos titres sont des <div> stylés en gros et gras, cette table des matières n'existe pas.

La règle est simple : un seul <h1> par page, une hiérarchie de titres continue, des zones nommées (<header>, <nav>, <main>, <footer>). Le HTML a été conçu pour ça. La plupart des gens qui le contournent ne le savent simplement pas.

Et là, surprise : cette même structure aide les moteurs de recherche à comprendre vos contenus. Vous ne faites pas deux travaux. Vous en faites un.

Les textes alternatifs : courts, utiles, jamais vides

Une image décorative n'a pas besoin d'un alt="photo de bureau". Elle a besoin d'un alt="". Un lecteur d'écran ignorera une image avec un alt vide, ce qui est exactement le comportement voulu.

Mais une image qui porte une information doit la porter en mots. Si votre graphique de ventes n'a qu'un alt="graphique", l'information est perdue pour qui ne voit pas l'écran. Décrivez la tendance dans le texte à côté, ou dans un long descriptif.

Le contraste, ce mal silencieux

Je l'ai fait aussi. Un joli gris clair sur fond blanc, très élégant, très fin. Illisible en plein soleil, illisible pour qui a une basse vision. Le ratio minimal recommandé par les règles internationales est de 4,5:1 pour le texte courant, et 3:1 pour les grands caractères.

Ce n'est pas une contrainte esthétique. C'est une contrainte de lisibilité. Et pour l'avoir testé sur plusieurs interfaces, un texte bien contrasté ne casse pas un design. Il le rend plus lisible pour tout le monde, y compris sur un écran de téléphone en extérieur.

Débranchez votre souris. Maintenant, utilisez votre site uniquement avec Tab, Entrée, Échap, les flèches. Tenez dix minutes.

Naviguer au clavier, ou l'accessibilité qui se voit tout de suite

C'est le test le plus brutal et le plus révélateur que je connaisse. La plupart des interfaces échouent en moins de deux minutes.

Ne supprimez jamais l'indicateur de focus

C'est la faute numéro un. Un développeur trouve le contour bleu moche, ajoute outline: none, problème réglé. Sauf que ce contour est la seule chose qui indique à une personne naviguant au clavier où elle se trouve.

Si vous le trouvez laid, redessinez-le. Ne le supprimez pas.

Un ordre de tabulation qui suit le regard

L'ordre du clavier doit suivre l'ordre visuel. Quand votre CSS place la barre latérale à droite alors qu'elle arrive après tout dans le code, la navigation devient un jeu de piste. Le tabindex positif est presque toujours une mauvaise idée : il casse l'ordre naturel.

La solution propre est d'ordonner le HTML comme on veut le parcourir, et de faire suivre le CSS.

Des formulaires qui ne piègent personne

Chaque champ a besoin d'un <label> associé, pas d'un placeholder qui disparaît dès la première frappe. Les messages d'erreur doivent être annoncés, pas seulement colorés en rouge. Et un formulaire ne doit jamais recharger la page sans prévenir.

Sur un projet, j'ai gagné un tiers de conversions en ajoutant simplement des labels visibles et des messages d'erreur explicites. Ce n'était pas de l'accessibilité pure. C'était juste du bon sens. Mais l'accessibilité, souvent, c'est ça.

Les erreurs fréquentes à éviter absolument

J'ai longtemps cru que l'attribut aria était la solution à tout. C'est en réalité l'inverse. Une aria mal utilisée est pire que pas d'aria du tout, parce qu'elle promet un comportement que le code ne fournit pas.

  • Un rôle button sur un <div> qui n'écoute pas la touche Entrée.
  • Un aria-hidden="true" posé sur un élément interactif, le rendant invisible aux lecteurs d'écran tout en restant cliquable.
  • Des alt qui répètent "image de", "photo de", comme si le lecteur d'écran ne le savait pas déjà.
  • Un carrousel qui défile tout seul, sans bouton pause, rendant toute lecture impossible.
  • Des vidéos sans sous-titres ni transcription.
  • Un menu déroulant qui ne se referme pas à la touche Échap.

Franchement, la règle que je me suis donnée : si un élément change de comportement à la souris, il doit changer de la même façon au clavier. Pas d'exception.

Quels outils pour tester concrètement ?

Voici la comparaison que j'aurais aimé trouver quand j'ai commencé. Chaque méthode attrape des choses différentes, et aucune ne suffit seule.

Méthode Ce qu'elle détecte Ce qu'elle rate Effort
Audit automatique (axe, WAVE, Lighthouse) Contrastes, alt manquants, labels absents, structure cassée Pertinence d'un alt, ordre logique, expérience réelle Faible
Test clavier manuel Pièges de focus, ordre de tabulation, éléments non atteignables Contrastes fins, problèmes pour lecteurs d'écran Moyen
Lecteur d'écran (NVDA, VoiceOver) Annonces incohérentes, contexte perdu, formulaires confus Problèmes visuels, navigation souris Élevé, mais formateur
Tests avec utilisateurs concernés Les vrais blocages, ceux qu'aucun outil ne prévoit Rien ne remplace ce retour Le plus coûteux, le plus utile

Un audit automatique attrape environ un tiers des problèmes. C'est déjà beaucoup pour un coût quasi nul. Mais il faut le savoir : passer un score parfait sur un outil d'analyse ne veut pas dire que le site est accessible.

Par où commencer quand on part de zéro ?

Je classe toujours par rapport effort / impact. Ce qui se corrige vite et débloque le plus de gens vient en premier.

  1. Les contrastes de couleurs sur tout le site. Une variable CSS globale, un après-midi de travail.
  2. Les alt des images informatives. Fastidieux, mais mécanique.
  3. Les labels de formulaire. Quelques heures.
  4. La navigation clavier et le focus visible. Un ou deux jours selon la complexité.
  5. La structure sémantique complète (titres, zones, langue de page). Le chantier le plus long, mais il structure tout le reste.

Faites ces cinq points dans l'ordre. Vous couvrirez la majorité des blocages réels, sans avoir touché à un seul attribut aria.

Les quatre principes à garder en tête

Les règles internationales d'accessibilité reposent sur quatre piliers, souvent résumés par l'acronyme POUR : Perceptible, Utilisable, Compréhensible, Robuste. C'est un bon filtre mental avant toute décision de conception.

Perceptible : tout le contenu doit pouvoir être perçu autrement qu'à l'œil. Texte alternatif, sous-titres, contraste suffisant. Utilisable : tout doit être atteignable et manipulable, quel que soit le moyen d'entrée. Clavier, souris, commande vocale. Compréhensible : pas de langage cryptique, pas de comportement imprévisible, des erreurs claires. Robuste : votre code doit fonctionner avec les technologies d'assistance d'aujourd'hui et de demain. Le meilleur moyen d'y arriver reste d'utiliser du HTML standard plutôt que d'inventer vos propres composants.

Ces quatre principes ne sont pas une liste de courses. C'est une grille de lecture. Quand vous hésitez sur une décision, demandez-vous lequel serait mis en défaut par votre choix.

Ce n'est pas seulement une obligation légale

En France, l'obligation d'accessibilité touche les services publics et, au-delà de certains seuils de chiffre d'affaires, un nombre croissant d'acteurs privés. Les sanctions existent. Mais je ne crois pas une seconde que ce soit la vraie raison de s'y mettre.

La vraie raison, c'est que votre audience est plus large que vous ne le pensez. Des personnes âgées avec une vue qui baisse. Des gens qui se cassent un poignet et naviguent au clavier trois semaines. Des utilisateurs sur un écran de téléphone en plein soleil. Des personnes dyslexiques, malvoyantes, aveugles, autistes, ou simplement pressées et surchargées.

L'accessibilité n'est pas un public à part. C'est votre public, dans toutes ses configurations.

Alors voilà. Ouvrez votre site dans un navigateur. Débranchez la souris. Appuyez sur Tab. Si vous ne savez pas où vous êtes au bout de trois secondes, vous savez ce qu'il vous reste à faire.

Amandine Duval

Amandine Duval

Amandine Duval est une spécialiste reconnue en apprentissage automatique, en analyse de données et en intelligence artificielle. Elle accompagne des équipes et des organisations dans la conception de solutions intelligentes adaptées à leurs besoins. Sa pédagogie claire et son approche concrète rendent ses interventions aussi rigoureuses qu'accessibles.

Voir tous les articles →

Articles similaires