Marie n'a pas trouvé ton bouton
Marie est malvoyante. Elle navigue sur le web avec un lecteur d'écran : un logiciel qui lit la page à voix haute et la laisse circuler au clavier. Aujourd'hui, elle veut commander chez toi.
Elle arrive sur ta boutique. La fiche produit est belle, la photo charge, le prix s'affiche. Elle cherche le bouton « Ajouter au panier ». Son lecteur d'écran parcourt la page, annonce les titres, les liens, les vrais boutons. Mais ton « Ajouter au panier », tu l'as codé comme ça :
<div class="btn" onclick="addToCart()">Ajouter au panier</div>Pour le lecteur d'écran, ce div n'est pas un bouton. C'est un bout de texte inerte. Il ne l'annonce pas comme cliquable, le clavier ne s'arrête pas dessus. Marie ne sait même pas qu'il existe. Elle part, et elle commande ailleurs.
Pas de drame, pas de violons. C'est juste un bug, comme un autre. Un bug qui exclut une cliente, silencieusement, sans message d'erreur dans ta console. Tout ce cours sert à débusquer ces bugs-là.
« L'accessibilité, c'est pour les aveugles »
C'est l'idée reçue numéro un, et elle est fausse. L'accessibilité ne concerne pas une petite minorité « à part ». Elle te concerne, toi aussi, plus souvent que tu ne crois.
Le handicap, ce n'est pas seulement une situation permanente. Il y en a trois formes :
- Permanent : une personne aveugle, sourde, sans usage d'un bras, avec un trouble cognitif. La situation dure.
- Temporaire : un bras dans le plâtre pendant six semaines, une opération des yeux qui te force à grossir tout, une otite qui coupe le son.
- Situationnel : le soleil en plein sur ton écran de téléphone, un bébé endormi dans un bras donc une seule main libre, un open-space bruyant où tu regardes une vidéo en sous-titres.
Tout le monde, un jour. Le clavier seul, le contraste suffisant, les sous-titres, un bouton qui s'annonce comme un bouton : ce ne sont pas des faveurs pour « les autres ». Ce sont des filets qui rattrapent tes utilisateurs, y compris toi, le jour où le contexte coince. Coder accessible, c'est coder pour des humains réels, pas pour un navigateur parfait dans une pièce idéale.
Le web est massivement cassé
Chaque année, le projet WebAIM Million teste automatiquement la page d'accueil du million de sites les plus visités. Le résultat de l'édition 2025 est brutal : 94,8 % de ces pages présentent des échecs WCAG détectables (source : WebAIM Million 2025, webaim.org/projects/million). Des erreurs qu'un outil automatique repère tout seul, sans même le test humain qui en trouverait davantage.
Traduction : l'écrasante majorité du web est cassée sur l'accessibilité. C'est une mauvaise nouvelle pour les utilisateurs, mais une bonne nouvelle pour toi. Savoir faire mieux que 95 % des sites n'est pas un exploit réservé aux experts. Quelques réflexes solides suffisent à te distinguer nettement.
Le mécanisme : l'arbre d'accessibilité
Pour comprendre pourquoi le div de Marie disparaît, il faut voir ce que voit réellement un lecteur d'écran. Et la surprise, c'est qu'il ne lit pas ta page comme toi.
Quand le navigateur charge ton HTML, il construit le DOM : l'arbre des éléments qu'il va afficher. Mais il construit aussi un second arbre, dérivé du premier : l'arbre d'accessibilité. Pour chaque élément, cet arbre note trois choses : son nom (le texte annoncé), son rôle (bouton ? lien ? titre ?) et son état (focusable, coché, désactivé...).
C'est ce second arbre, et lui seul, que le navigateur expose aux technologies d'assistance, via une API du système d'exploitation. Le lecteur d'écran de Marie ne lit pas ton CSS ni tes jolies classes. Il lit cet arbre.
Maintenant, compare deux éléments qui s'affichent pareil à l'écran :
- Un
<button>natif arrive dans l'arbre avec le rôle « bouton », un nom (son texte), et l'état focusable. Le lecteur l'annonce, le clavier s'arrête dessus. Gratuit. - Un
<div onclick>arrive dans l'arbre comme... du texte. Pas de rôle bouton, pas d'état focusable. Le lecteur le lit comme une phrase ordinaire, le clavier passe à côté.
Voilà le mécanisme exact derrière le départ de Marie. Le div existe à l'écran, mais il se perd en route vers l'arbre d'accessibilité.
button traverse jusqu'au lecteur d'écran. Le div onclick se perd en chemin.Une vidéo de ton site a des sous-titres. À ton avis, qui en profite ? Liste tous les profils qui te viennent.
Voir la réponse
Bien plus de monde que prévu. Les personnes sourdes et malentendantes, bien sûr. Mais aussi : le voyageur dans un métro bruyant, la personne dans un open-space sans écouteurs, celui qui regarde en silence pour ne pas réveiller le bébé, et la personne non native qui lit mieux qu'elle n'entend la langue. Un seul effort, des bénéficiaires partout. C'est la règle de fond de l'accessibilité : ce qui aide une minorité finit par aider tout le monde.
Les 4 principes de WCAG, en français simple
WCAG, le standard international d'accessibilité, tient sur quatre principes. On les retient avec l'acronyme POUR. Garde-les en tête comme une boussole, le détail viendra dans les leçons suivantes.
- Perceptible : l'utilisateur doit pouvoir percevoir le contenu, par un canal ou un autre (texte alternatif sur les images, sous-titres sur les vidéos).
- Utilisable : l'utilisateur doit pouvoir s'en servir, y compris sans souris (tout doit marcher au clavier).
- Compréhensible : le contenu et le fonctionnement doivent être clairs et prévisibles (un libellé qui dit ce que fait le bouton).
- Robuste : le code doit rester lisible par les technologies d'assistance, aujourd'hui et demain (du HTML propre que le lecteur d'écran sait interpréter).
La carte du cours
Voici le chemin qu'on va suivre, dans cet ordre précis :
- Leçon 2, la sémantique : utiliser le bon HTML pour que l'arbre d'accessibilité soit bon tout seul.
- Leçon 3, le clavier et le focus visible : tout faire fonctionner sans souris.
- Leçon 4, le texte alternatif : décrire les images pour ceux qui ne les voient pas.
- Leçon 5, les formulaires accessibles : des champs qui s'annoncent et des erreurs lisibles.
- Leçon 6, le contraste et la couleur : un texte lisible, une info jamais portée par la couleur seule.
- Leçon 7, ARIA et tester pour de vrai : les attributs ARIA et les outils de test.
Tu remarques qu'ARIA arrive en dernier, et c'est voulu. Tu comprendras pourquoi en chemin : bien utilisé, ARIA est un outil de finition, pas la fondation. La fondation, c'est le bon HTML. On commence par là.
Marie couldn't find your button
Marie has low vision. She browses the web with a screen reader: software that reads the page aloud and lets her move through it with the keyboard. Today, she wants to order from you.
She lands on your shop. The product page is nice, the photo loads, the price shows. She looks for the "Add to cart" button. Her screen reader scans the page, announces the headings, the links, the real buttons. But your "Add to cart"? You coded it like this:
<div class="btn" onclick="addToCart()">Add to cart</div>To the screen reader, this div is not a button. It's an inert piece of text. It isn't announced as clickable, the keyboard never stops on it. Marie doesn't even know it exists. She leaves, and she orders elsewhere.
No drama, no violins. It's just a bug, like any other. A bug that excludes a customer, silently, with no error in your console. This whole course is about hunting down bugs like this one.
"Accessibility is for blind people"
That's misconception number one, and it's wrong. Accessibility isn't about a small, separate minority. It's about you too, more often than you think.
Disability isn't only a permanent condition. It comes in three forms:
- Permanent: a person who is blind, deaf, has no use of an arm, or has a cognitive impairment. The situation lasts.
- Temporary: an arm in a cast for six weeks, eye surgery that forces you to zoom everything, an ear infection that kills the sound.
- Situational: bright sun on your phone screen, a sleeping baby in one arm so only one hand free, a noisy open-plan office where you watch a video on captions.
Everyone, some day. Keyboard-only use, enough contrast, captions, a button that announces itself as a button: these aren't favours for "other people". They're safety nets that catch your users, you included, the day the context gets in the way. Coding accessibly means coding for real humans, not for a perfect browser in an ideal room.
The web is massively broken
Every year, the WebAIM Million project automatically tests the home page of the million most-visited sites. The 2025 result is brutal: 94.8% of those pages have detectable WCAG failures (source: WebAIM Million 2025, webaim.org/projects/million). Errors an automated tool spots on its own, before the human testing that would find even more.
Translation: the overwhelming majority of the web is broken on accessibility. That's bad news for users, but good news for you. Doing better than 95% of sites is not a feat reserved for experts. A few solid habits are enough to set you clearly apart.
The mechanism: the accessibility tree
To understand why Marie's div vanishes, you need to see what a screen reader actually sees. And the surprise is: it doesn't read your page the way you do.
When the browser loads your HTML, it builds the DOM: the tree of elements it will display. But it also builds a second tree, derived from the first: the accessibility tree. For each element, this tree notes three things: its name (the announced text), its role (button? link? heading?) and its state (focusable, checked, disabled...).
It's this second tree, and only this one, that the browser exposes to assistive technologies, through an operating-system API. Marie's screen reader doesn't read your CSS or your pretty classes. It reads this tree.
Now compare two elements that look identical on screen:
- A native
<button>arrives in the tree with the role "button", a name (its text), and the focusable state. The reader announces it, the keyboard stops on it. For free. - A
<div onclick>arrives in the tree as... text. No button role, no focusable state. The reader reads it like an ordinary sentence, the keyboard walks right past it.
There's the exact mechanism behind Marie leaving. The div exists on screen, but it gets lost on its way to the accessibility tree.
button travels all the way to the screen reader. The div onclick gets lost on the way.A video on your site has captions. Who do you think benefits? List every profile that comes to mind.
Show the answer
Far more people than expected. Deaf and hard-of-hearing people, of course. But also: the traveller in a noisy metro, the person in an open-plan office with no headphones, the one watching in silence so as not to wake the baby, and the non-native speaker who reads the language better than they hear it. One effort, beneficiaries everywhere. That's the core rule of accessibility: what helps a minority ends up helping everyone.
The 4 WCAG principles, in plain English
WCAG, the international accessibility standard, rests on four principles. We remember them with the acronym POUR. Keep them in mind as a compass; the detail comes in the following lessons.
- Perceivable: the user must be able to perceive the content, through one channel or another (alt text on images, captions on videos).
- Operable: the user must be able to operate it, including without a mouse (everything must work on the keyboard).
- Understandable: the content and the behaviour must be clear and predictable (a label that says what the button does).
- Robust: the code must stay readable by assistive technologies, today and tomorrow (clean HTML the screen reader can interpret).
The course map
Here's the path we'll follow, in this precise order:
- Lesson 2, semantics: use the right HTML so the accessibility tree is correct on its own.
- Lesson 3, keyboard and visible focus: make everything work without a mouse.
- Lesson 4, alt text: describe images for those who can't see them.
- Lesson 5, accessible forms: fields that announce themselves and readable errors.
- Lesson 6, contrast and color: readable text, and info never carried by color alone.
- Lesson 7, ARIA and real testing: ARIA attributes and the testing tools.
You'll notice ARIA comes last, and that's on purpose. You'll understand why along the way: used well, ARIA is a finishing tool, not the foundation. The foundation is good HTML. That's where we start.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
💬 Ré-explique sans regarder
Explique à un collègue pourquoi un <div onclick> et un <button> qui se ressemblent à l'écran ne sont pas pareils pour un lecteur d'écran.
<button> y arrive avec le rôle « bouton » et l'état focusable, donc le lecteur l'annonce et le clavier s'arrête dessus. Le <div onclick> y arrive comme du texte inerte : ni rôle, ni focus. Même rendu à l'écran, mais pas le même arbre, donc pas le même accès.🧠 Rappel libre
Sans remonter : cite les trois formes de handicap, avec un exemple de chaque.
⚖️ Juge le code de l'IA
Tu démarres un projet et tu demandes à l'IA de penser à l'accessibilité. Elle répond : « Bonne idée, mais on verra l'accessibilité à la fin, quand l'app marchera. Si on a le temps, on rajoutera ce qu'il faut. » Tu acceptes, ou tu rejettes ?
<div onclick> comme un bouton ?<button> et un <div onclick> stylé en bouton. Qu'est-ce qui décide vraiment si un lecteur d'écran les rend accessibles ?Marie left because of a div disguised as a button. The good news: 80% of the accessibility work is free. You just have to use HTML for what it already knows how to do. Lesson 2: semantics, and the find-the-5-problems lab where you hunt down a page's traps yourself.
Lesson 2: Semantic HTML: 80% of the work →