Ah bon ? Tu l’as testé avec un lecteur d’écran ?

“Euh… non… mais j’ai mis des aria-label partout. Et alt="logo" aussi. Donc bon.”

Spoiler : c’est pas parce que tu mets trois aria-* que ton site devient accessible. Sinon on mettrait juste aria-sustainable="true" et on sauverait la planète.

Le test qui fait mal

Tu veux savoir si ton site est vraiment utilisable sans la vue ? Fais le test :

1. Active VoiceOver (Mac : Cmd + F5) ou NVDA (Windows, gratuit)
2. Ferme les yeux
3. Tente de faire le parcours critique : trouver un produit, remplir un formulaire, passer une commande

Et quand t’entends “bouton… bouton… lien… bouton…”, tu comprendras que t’as codé un labyrinthe vocal.

Le syndrome du aria-label partout

<!-- ❌ aria-label en doublon du texte visible -->
<button aria-label="Rechercher">Rechercher</button>
<!-- Le lecteur d'écran lit "Rechercher" deux fois
     ou ignore le texte visible. Confusion. -->

<!-- ✅ Le texte visible suffit -->
<button>Rechercher</button>

<!-- ❌ aria-label sur un div qui n'a pas de rôle -->
<div aria-label="Section contact">
  <h2>Contact</h2>
</div>
<!-- aria-label est ignoré ici. Purement inutile. -->

<!-- ✅ Si tu veux labelliser une région -->
<section aria-labelledby="contact-heading">
  <h2 id="contact-heading">Contact</h2>
</section>

La règle d’or de ARIA : pas de ARIA vaut mieux que du mauvais ARIA. Un HTML sémantique propre fait 90% du travail sans un seul attribut aria-*.

C’est pas juste les non-voyants

On pense souvent accessibilité = lecteur d’écran. Mais c’est bien plus large :

• Troubles moteurs — navigation au clavier, au switch, à la commande vocale. Ton menu hamburger qui ne s’ouvre qu’au survol souris ? Inaccessible.
• Troubles cognitifs — langage simple, navigation prévisible, pas de timeout arbitraire. Ton formulaire en 12 étapes avec un timer de 3 minutes ? Stressant et exclusif.
• Daltonisme — ton lien bleu sur fond bleu, ton erreur signalée uniquement en rouge. Invisible pour 8% des hommes.
• Basse vision — zoom à 200%, texte redimensionnable, contraste suffisant. Ton texte en 10px gris clair sur blanc ? Illisible.
• Surdité — sous-titres sur les vidéos, transcriptions des podcasts.

Le vrai test d’accessibilité

Pas besoin d’un audit de 200 pages pour commencer. Fais ces 5 tests en 10 minutes :

1. Navigation clavier

Débranche ta souris. Navigue avec Tab. Tu vois où tu es ? Tu peux tout atteindre ? Tu peux en sortir (pas de piège clavier) ?

2. Zoom 200%

Ctrl + + jusqu’à 200%. Rien ne se chevauche ? Tout est lisible ? Le contenu ne déborde pas ?

3. Lecteur d’écran

Active VoiceOver/NVDA. Les boutons ont-ils un nom ? Les images informatives sont-elles décrites ? Les formulaires sont-ils compréhensibles ?

4. Contraste

Utilise un outil comme l’extension RGAA Lab. Le contraste texte/fond est-il suffisant (4.5:1 pour le texte normal, 3:1 pour le gros texte) ?

5. Structure

Inspecte le DOM. Y a-t-il des <h1> à <h6> ordonnés ? Des landmarks (<nav>, <main>, <footer>) ? Des labels sur les champs de formulaire ?

L’accessibilité, c’est pour tout le monde

Un bon site, c’est pas un site qui marche sur ton MacBook avec la fibre. C’est un site qui marche pour les vrais gens, partout :

• Dans le métro avec une connexion lente
• Sur un téléphone avec un écran cassé
• Avec un bras dans le plâtre
• À 50 ans avec des lunettes qui ne corrigent plus assez
• En plein soleil avec les reflets sur l’écran

L’accessibilité, c’est pas “pour une minorité”. C’est pour tout le monde qui, un jour ou l’autre, ne sera pas dans des conditions idéales.

Et ce jour-là, tu seras content que quelqu’un ait pensé à toi.

Pour aller plus loin

• Les outils indispensables pour tester l’accessibilité — ARC Toolkit, Tanaguru, RGAA Lab…
• Le :focus-visible, c’est vital — un exemple concret de critère souvent raté
• Découvrir l’extension RGAA Lab — pour auditer les 106 critères dans votre navigateur