Chapitre 1.5 — Mythes & réalités

⏱️ TL;DR — Six idées reçues sabotent l’accessibilité dans les équipes : « c’est cher », « ça enlaidit », « ça concerne peu de gens », « l’outil automatique gère », « c’est le job du designer/de la fin de projet », « il faut de l’ARIA partout ». Chacune est fausse, et il faut savoir y répondre — parce qu’un expert a11y passe une partie de son temps à convaincre, pas seulement à coder. Le principe qui les balaie toutes : l’accessibilité coûte peu quand on la fait tôt (shift-left) et cher quand on la repousse.

🎯 Objectifs

• Démonter les six mythes les plus courants, argument à l’appui.
• Comprendre le principe du shift-left (traiter l’a11y au plus tôt).
• Savoir répondre à un collègue ou un manager sceptique.
• Anticiper la première règle d’ARIA (préparée ici, détaillée en Partie 6).

Mythe 1 — « L’accessibilité coûte trop cher »

Réalité : elle coûte cher quand on la fait à la fin, comme un rattrapage. Intégrée dès la conception et le développement, elle ajoute très peu — parce que « accessible » recoupe largement « bien fait ». Utiliser un <button> au lieu d’une <div> ne coûte rien ; le refaire accessible après coup, sur 200 composants, coûte une fortune. Le vrai calcul n’est pas « a11y ou pas », c’est « maintenant, pas cher » ou « plus tard, très cher ».

Mythe 2 — « Ça rend le design moche/bridé »

Réalité : l’accessibilité n’impose ni laideur ni uniformité. Elle impose du contraste suffisant, des cibles cliquables correctes, un focus visible, un ordre logique — des contraintes que les meilleurs designs respectent déjà. Des produits superbes et primés sont accessibles. Ce qui est vrai : on ne peut plus faire n’importe quoi (texte gris clair à 2:1 sur fond blanc), mais ces limites améliorent le design plutôt qu’elles ne l’appauvrissent.

Mythe 3 — « Ça ne concerne qu’une poignée d’utilisateurs »

Réalité : environ une personne sur six vit avec un handicap, et tout le monde traverse des limitations temporaires ou situationnelles (chapitre 1.1). Ajoute l’effet trottoir abaissé (les correctifs profitent à tous) et le SEO. Le public réel de l’accessibilité, c’est presque tout le monde, à un moment donné.

Mythe 4 — « Notre outil automatique gère l’accessibilité »

Réalité : les outils automatiques (axe, Lighthouse, WAVE) sont indispensables mais ne détectent qu’une fraction des problèmes — de l’ordre de 30 à 40 %. Ils repèrent une image sans alt ou un contraste faible, mais pas si l’alt a du sens, si l’ordre de tabulation est logique, si le composant custom est utilisable au lecteur d’écran, si le message d’erreur est compréhensible. L’accessibilité réelle exige aussi des tests manuels : clavier, lecteur d’écran, jugement (Partie 14).

⚠️ Piège — Afficher « 100 % sur Lighthouse » et croire le site accessible. Un score de 100 signifie « aucune erreur automatiquement détectable » — pas « accessible ». On peut avoir 100/100 et une page inutilisable au clavier. Le score est un point de départ, jamais une preuve de conformité.

Mythe 5 — « C’est le job du designer / on verra à la fin »

Réalité : l’accessibilité est une responsabilité partagée et continue. Le designer choisit les contrastes et les parcours ; le dev implémente la sémantique, le clavier, les états ; le rédacteur écrit les alternatives et le langage clair ; le PO priorise. Et surtout : elle se traite tout au long du projet, pas dans un sprint « accessibilité » en fin de course. C’est le principe du shift-left : déplacer l’effort vers le début du cycle, là où il coûte le moins.

Mythe 6 — « Il faut mettre de l’ARIA partout »

Réalité : c’est l’inverse. La première règle d’ARIA, c’est de ne pas utiliser ARIA quand un élément HTML natif fait déjà le travail. Un <button>, un <nav>, un <label> bien utilisés apportent la sémantique gratuitement et sans bug. L’ARIA mal employée aggrave l’accessibilité (on le verra en Partie 6). L’expert n’est pas celui qui met le plus d’ARIA — c’est celui qui en met le moins possible parce qu’il maîtrise le HTML natif.

<!-- ❌ ARIA pour réinventer ce que HTML fait déjà -->
<div role="button" tabindex="0" aria-pressed="false">Menu</div>
 
<!-- ✅ Élément natif : rôle, focus et clavier gratuits, zéro bug -->
<button type="button">Menu</button>

💡 Réflexe — Avant d’ajouter un attribut ARIA, demande-toi : « existe-t-il un élément HTML natif qui fait ça ? ». Neuf fois sur dix, oui. L’ARIA est un complément pour les cas que le HTML ne couvre pas (composants complexes), pas un substitut au HTML sémantique.

Le principe qui balaie tous les mythes : shift-left

Tous ces mythes ont une même racine : traiter l’accessibilité trop tard, comme une couche externe. Le remède tient en un mot : shift-left — intégrer l’a11y dès la conception, l’écrire dans les composants dès le premier jour, la tester en continu. Faite tôt, elle est presque gratuite et invisible dans le budget. Repoussée, elle devient un chantier de remédiation coûteux et douloureux. Tout le reste du cours applique ce principe.

🧭 Sur A11yLearn — Pour A11yLearn, on adopte le shift-left : plutôt que de coder toute la plateforme puis de lancer un « audit-panique » avant la mise en conformité, on construit chaque brique accessible dès le départ (boutons natifs, formulaires étiquetés, vidéos sous-titrées). Le cours te montrera les deux : comment bien construire dès le début, et comment remédier à l’existant quand on hérite d’un projet qui a ignoré l’a11y.

✏️ Exercices

Exercice 1 — Réponds au sceptique. Un collègue lance : « On a 98 sur Lighthouse, l’accessibilité c’est bon. » Que réponds-tu, sans être arrogant ?

Exercice 2 — Repère le sur-ARIA. Pourquoi le premier extrait ci-dessous est-il pire que le second, alors qu’il « fait » plus de choses ?

<div role="button" tabindex="0" aria-pressed="false" onclick="toggle()">Filtrer</div>
<button type="button" aria-pressed="false" onclick="toggle()">Filtrer</button>

🧠 Quiz de révision

Partie suivante : Cadre légal & normatif — on entre dans le détail des WCAG, d’ARIA, du RGAA et de l’EAA, et de ce que « conforme » veut dire précisément.