← retour aux articles

Accessibilité web : 6 erreurs à corriger en 10 minutes

par @elo · BordTech · · #dev-web

Lecture : 5 min

On croit souvent que rendre un site accessible, c'est un énorme chantier réservé aux grosses boîtes avec un budget dédié. En réalité, la plupart des problèmes viennent de six oublis, toujours les mêmes. Chaque année, l'étude WebAIM Million passe un million de pages d'accueil à la moulinette : plus de 95 % ont au moins une erreur détectable automatiquement, et ce sont presque toujours les mêmes qui reviennent.

Bonne nouvelle : elles se corrigent vite. Prends ton site, ouvre ton éditeur, on y va.

Avant de commencer : le test du clavier

Débranche ta souris (ou fais semblant) et navigue sur ton site avec Tab, Maj+Tab, Entrée et Espace. Trois questions :

Ce test prend deux minutes et il en dit plus que n'importe quel outil automatique. Si tu ne vois rien quand tu tabules, c'est probablement que quelqu'un a mis outline: none dans le CSS « parce que c'était moche ». Ne le supprime pas sans le remplacer : 

:focus-visible {
  outline: 3px solid #1a5fd0;
  outline-offset: 2px;
}

:focus-visible n'affiche le contour que pour la navigation au clavier, donc les utilisateurs de souris ne voient aucune différence.

1. Le contraste insuffisant

C'est l'erreur numéro un, détectée sur environ 80 % des pages. Le gris clair sur fond blanc fait élégant dans Figma, beaucoup moins en plein soleil sur un téléphone, ou pour quelqu'un dont la vue baisse (c'est-à-dire à peu près tout le monde, un jour).

Le seuil à viser : un ratio de 4,5:1 pour le texte normal, 3:1 pour le gros texte. Pour vérifier, l'onglet Accessibilité des DevTools de Chrome ou Firefox affiche le ratio quand tu cliques sur un élément. Il propose même une couleur de remplacement.

Les coupables habituels : les placeholders, les textes secondaires (« il y a 3 jours »), les liens de pied de page et les boutons désactivés.

2. Les images sans texte alternatif

Une image sans attribut alt, c'est un trou pour un lecteur d'écran. Il va souvent lire le nom du fichier, du genre « IMG underscore 4032 point jpg ». Pas terrible. 

<!-- Image porteuse d'information -->
<img src="graphique-ventes.png" alt="Les ventes ont doublé entre 2023 et 2025">

<!-- Image purement décorative -->
<img src="separateur.svg" alt="">

Le point que beaucoup ratent : un alt vide n'est pas une erreur. Si l'image est décorative, alt="" dit au lecteur d'écran de passer son chemin. C'est mieux que d'écrire « décoration » ou « image ». Pour les autres, décris ce que l'image apporte au contenu, pas ce qu'elle montre au pixel près.

3. Les champs de formulaire sans label

Un placeholder n'est pas un label. Il disparaît dès qu'on tape, il est souvent trop pâle (voir point 1), et certains lecteurs d'écran ne l'annoncent pas de manière fiable. 

<label for="email">Adresse e-mail</label>
<input id="email" type="email" autocomplete="email">

Avec for et id qui correspondent, cliquer sur le texte met aussi le focus dans le champ, ce qui profite à tout le monde, notamment sur mobile où les zones de toucher sont petites. Et ajoute autocomplete : ça évite de retaper son adresse trente fois.

Si le design interdit vraiment un label visible, cache-le proprement (une classe visually-hidden) au lieu de le supprimer.

4. Les liens vides

Le classique : une icône réseau social, un lien qui n'entoure qu'une image sans alt, un <a> généré par un composant et resté sans contenu. Pour un lecteur d'écran, c'est « lien », point. 

<a href="https://mastodon.example/@bordtech" aria-label="BordTech sur Mastodon">
  <svg aria-hidden="true">…</svg>
</a>

Pense aussi aux « cliquez ici » et « en savoir plus ». Les utilisateurs de lecteurs d'écran listent souvent tous les liens de la page à la suite : une liste de douze « en savoir plus » ne leur sert à rien.

5. Les boutons vides (ou qui ne sont pas des boutons)

Même problème que les liens : un bouton burger avec trois barres en CSS et rien d'autre. Ajoute un nom : 

<button aria-label="Ouvrir le menu" aria-expanded="false">☰</button>

Et surtout, utilise de vrais <button>. Un <div onclick="…"> n'est pas focusable, ne répond pas à Entrée ni à Espace, et n'est pas annoncé comme un bouton. Tu peux le rattraper avec des tabindex, des role et des gestionnaires de touches, ou tu peux écrire <button> et avoir tout ça gratuitement. La première règle d'ARIA, c'est d'ailleurs de ne pas l'utiliser quand un élément HTML natif fait le travail.

6. La langue de la page non déclarée

Une seule ligne, qui concerne environ une page sur six :

<html lang="fr">

Sans elle, un lecteur d'écran peut lire ton texte français avec l'accent et la prononciation de l'anglais. Le résultat est comique les trois premières secondes, puis inutilisable. Si une citation est dans une autre langue, tu peux la marquer à part : <q lang="en">…</q>.

Et ensuite ?

Ces six points couvrent l'essentiel de ce que les outils détectent. Ils ne couvrent pas tout : un outil automatique ne repère qu'une partie des problèmes (on cite souvent entre 30 et 40 %). Il ne sait pas si ton alt est pertinent, si l'ordre de lecture a du sens ou si ta modale piège le focus.

Pour continuer :

L'accessibilité n'est pas une case à cocher en fin de projet. C'est une habitude qu'on prend en écrivant du HTML correct dès le départ, et c'est aussi ce qui aide le SEO, le mobile et la maintenance. Commence par la touche Tab.