ARIA and real testing

Le piège qu'on garde pour la fin

Six leçons que tu construis tes pages avec du HTML natif. Et seulement maintenant on parle d'ARIA, ce vocabulaire qui sert justement à « rendre les choses accessibles ». Ce n'est pas un oubli. C'est volontaire.

Parce qu'ARIA, mal utilisé, casse plus qu'il ne répare. Le rapport WebAIM Million 2025 a analysé le million de pages d'accueil les plus visitées du web. Verdict : les pages qui utilisent ARIA ont en moyenne deux fois plus d'erreurs d'accessibilité que celles qui n'en utilisent pas. L'outil censé aider aggrave la situation entre des mains pressées.

D'où la toute première règle d'ARIA, écrite noir sur blanc par le W3C dans ses guides d'usage.

Première règle d'ARIA : si un élément HTML natif fait le travail, ne pas utiliser ARIA. Un <button>, un <nav>, un <label> donnent déjà tout : le rôle, le focus, la réponse au clavier, l'annonce au lecteur d'écran. Le natif te l'offre gratuitement, comme on l'a vu en leçon 2. ARIA ne devrait servir que là où le HTML, vraiment, ne sait pas faire.

Ce qu'ARIA fait, et surtout ce qu'il ne fait pas

Voici le fait mécanique à graver. ARIA n'ajoute que de la sémantique : il change ce que l'arbre d'accessibilité annonce (souviens-toi de la leçon 1 : l'arbre, c'est ce que le lecteur d'écran lit). ARIA ne change jamais le comportement.

Prends un simple <div>. Tu lui mets role="button". Le lecteur d'écran annoncera désormais « bouton ». Victoire ? Non. Ce div ne réagit toujours pas à la touche Entrée. Il ne réagit pas à Espace. Il n'est même pas focusable au clavier. ARIA a changé l'étiquette, pas la machine derrière.

Pour qu'un div imite vraiment un bouton, tu dois tout recoder à la main, ce que <button> donnait pour rien :

<div role="button" tabindex="0"
     onclick="valider()"
     onkeydown="if(event.key==='Enter'||event.key===' ')valider()">
  Valider
</div>

Le rôle, plus tabindex="0" pour le rendre focusable, plus un écouteur clavier qui gère Entrée et Espace. Et la même chose en natif :

<button onclick="valider()">Valider</button>

Huit lignes fragiles contre une ligne solide. Tu vois pourquoi la première règle existe.

Quand ARIA est, lui, indispensable

ARIA a sa place exacte : là où le HTML n'a aucune balise pour décrire un état dynamique. Voici les usages légitimes, ceux que tu rencontreras vraiment.

aria-expanded="true|false" : sur le bouton d'un accordéon ou d'un menu déroulant. Il annonce « ouvert » ou « fermé ». Le HTML n'a pas de balise pour cet état, ARIA le porte.
aria-current="page" : sur le lien actif d'un menu de navigation. Le lecteur d'écran annonce « page courante » et l'utilisateur sait où il est.
aria-describedby : tu l'as déjà utilisé en leçon 5, pour relier un message d'erreur à son champ. C'est de l'ARIA, et c'est exactement son bon usage.
Les live regions : aria-live="polite" annonce un changement sans interrompre l'utilisateur. Idéal pour un « 3 résultats trouvés » qui apparaît après un filtre. La valeur assertive existe aussi, mais elle coupe la parole : réserve-la aux vraies urgences (une erreur bloquante).

Règle d'or : ARIA décrit un état que le HTML ne sait pas exprimer (ouvert/fermé, page courante, zone qui se met à jour). Il ne remplace jamais un élément natif. Si tu écris role="button", demande-toi d'abord : pourquoi pas un vrai <button> ?

Prédis avant de lire

Un dev a écrit <div role="button" onclick="payer()">Payer</div>. Marie navigue au clavier, arrive (croit-elle) sur ce bouton et appuie sur Entrée. Que se passe-t-il ?

Voir la réponse

Rien. Et pire : Marie n'a même pas pu s'arrêter dessus. Sans tabindex="0", le div n'est pas focusable : la tabulation l'a sauté. Et même si elle l'atteignait, role="button" n'a changé que l'annonce, pas le comportement : aucun écouteur ne gère la touche Entrée, donc payer() ne se déclenche pas. ARIA a posé une étiquette « bouton » sur un objet qui n'en est pas un. Avec un vrai <button>, Marie aurait payé sans y penser.

Tester pour de vrai, sans rien dépenser

Tu peux auditer une page sérieusement avec des outils 100 % gratuits. Voici-les par ordre de rendement : du plus rentable au plus engageant.

1. Le test clavier (30 secondes, énorme)

Celui de la leçon 3. Range la souris. Tab, Tab, Tab à travers la page. Tu vérifies trois choses : tout ce qui est interactif est atteignable, l'anneau de focus est toujours visible, et l'ordre suit la logique de lecture. Ce test gratuit attrape une part énorme des problèmes en une demi-minute. C'est le meilleur rapport effort/résultat de tout le métier.

2. axe DevTools ou Lighthouse (automatique)

Une extension de navigateur (axe DevTools) ou l'onglet Lighthouse de Chrome scanne ta page et liste des erreurs : contraste insuffisant, image sans alt, label manquant. Pratique. Mais attention au faux sentiment de sécurité.

Un score Lighthouse 100 ne veut pas dire « accessible ». Les outils automatiques ne détectent qu'environ 30 à 40 % des problèmes d'accessibilité (source : The A11Y Project). Ils repèrent ce qui se mesure machinalement (un alt absent, un ratio de contraste) mais sont aveugles à l'essentiel : un alt présent mais faux, un ordre de tabulation absurde, un label qui ment. Le vert de l'outil dit « pas d'erreur évidente », jamais « accessible ».

3. Le lecteur d'écran (le vrai test)

Le seul moyen d'entendre ta page comme un utilisateur aveugle. Et c'est gratuit : NVDA sur Windows (open source, à télécharger), VoiceOver déjà intégré sur Mac (active-le avec Cmd+F5). Cinq commandes suffisent pour démarrer :

Tab : passer d'un élément interactif au suivant (liens, boutons, champs).
Flèches : lire le contenu mot à mot, ligne à ligne.
H : sauter de titre en titre (tu entends ta hiérarchie de la leçon 2).
D : sauter de landmark en landmark (les régions de la page).
Ctrl : couper la voix quand elle parle trop.

Ferme les yeux. Essaie d'accomplir une tâche sur ta propre page : trouver un produit, remplir un champ. Tester soi-même une seule page au lecteur d'écran t'apprendra plus que dix articles. C'est inconfortable au début, puis ça devient une évidence.

Labo final : l'audit complet

Voici une page récapitulative. Elle concentre les six erreurs vues tout au long du cours, une par leçon. Lis le code, repère-les, puis déplie la correction. Chaque problème renvoie à sa leçon : c'est ta révision finale.

<div onclick="ouvrir()">Voir le panier</div>

<h1>Ma boutique</h1>
<h3>Nos produits</h3>

<img src="promo.jpg">

<input type="text" placeholder="Votre email">

<p style="color:#bbb">Champ obligatoire</p>

<div role="button">Payer</div>

Voir les 6 problèmes corrigés

Le div cliquable (leçon 2) : <div onclick> n'est ni focusable ni annoncé comme bouton. → <button onclick="ouvrir()">Voir le panier</button>.
Le saut de titre (leçon 2) : on passe de <h1> à <h3>, le <h2> manque. La hiérarchie est cassée. → utiliser <h2>Nos produits</h2>.
L'image sans alt (leçon 4) : <img> sans attribut alt est annoncée par son nom de fichier ou ignorée. → alt="Promotion : -20 % sur tout le rayon" (ou alt="" si purement décorative).
Le placeholder-label (leçon 5) : le placeholder n'est pas un label, il disparaît à la saisie. → un vrai <label for="email">Votre email</label> relié au champ.
Le gris trop pâle (leçon 6) : #bbb sur blanc tombe sous le ratio 4.5:1 exigé. → un gris foncé qui passe le contraste, par exemple #595959.
Le faux bouton ARIA (leçon 7) : role="button" sur un div annonce « bouton » mais ne réagit pas au clavier. → un vrai <button>Payer</button>.

Six erreurs, six leçons. Si tu les as toutes vues, tu as les réflexes du cours.

Le cadre légal en 2026

L'accessibilité n'est plus seulement une bonne pratique : c'est une obligation qui se renforce. Les faits, sans dramatiser.

Ce qu'il faut savoir (faits vérifiés) :

European Accessibility Act (directive UE 2019/882) : applicable depuis le 28 juin 2025 aux produits et services neufs (e-commerce, banque en ligne, livres numériques, billetterie...). Les micro-entreprises de services (moins de 10 personnes et moins de 2 millions d'euros de chiffre d'affaires) bénéficient d'une exemption.
En France, le RGAA (Référentiel général d'amélioration de l'accessibilité), aujourd'hui en version 4.1.2 : c'est la déclinaison opérationnelle de WCAG 2.1 en 106 critères de contrôle. Une version RGAA 5, alignée sur WCAG 2.2 et sous contrôle de l'Arcom, est annoncée pour fin 2026.
La référence technique reste WCAG (Web Content Accessibility Guidelines). Le niveau AA est la cible standard visée par la réglementation.

Tes sept réflexes, en une boucle

Tu as fait le tour. Voici le cours résumé en sept réflexes, un par leçon, dans l'ordre où tu les appliques quand tu codes.

Penser à tout le monde (leçon 1) : handicaps permanents, temporaires, situationnels. Tu codes pour l'arbre d'accessibilité, pas seulement pour l'écran.
Du HTML sémantique d'abord (leçon 2) : le bon élément natif fait 80 % du travail, gratuitement.
Tester au clavier (leçon 3) : tout atteignable, focus visible, ordre logique.
Décrire les images (leçon 4) : un alt utile, ou un alt vide si décoratif.
Lier label et champ (leçon 5) : chaque champ a son vrai label, les erreurs sont reliées.
Vérifier le contraste (leçon 6) : 4.5:1 minimum, la couleur n'est jamais seule à porter l'info.
ARIA en dernier recours (leçon 7) : le natif d'abord, ARIA seulement pour ce qu'il sait dire de plus.

La boucle, maintenant. Reprends ton journal de la leçon 1 : tu y notais que l'accessibilité semblait être une couche à ajouter à la fin. Tu sais désormais que c'est l'inverse. L'accessibilité n'est pas une checklist de fin de projet. C'est une façon d'écrire le HTML dès la première ligne. Le bon élément, le bon label, le bon contraste, posés au moment où tu écris : voilà le métier.

The trap we keep for the end

Six lessons spent building your pages with native HTML. And only now do we talk about ARIA, the very vocabulary meant to "make things accessible". That's not an oversight. It's deliberate.

Because ARIA, misused, breaks more than it fixes. The WebAIM Million 2025 report analysed the million most-visited home pages on the web. Verdict: pages that use ARIA average twice as many accessibility errors as pages that don't. The tool meant to help makes things worse in rushed hands.

Hence the very first rule of ARIA, spelled out by the W3C in its authoring guidance.

First rule of ARIA: if a native HTML element does the job, do not use ARIA. A <button>, a <nav>, a <label> already give you everything: the role, the focus, the keyboard response, the screen-reader announcement. Native gives it for free, as we saw in lesson 2. ARIA should only step in where HTML genuinely can't.

What ARIA does, and above all what it doesn't

Here's the mechanical fact to engrave. ARIA only adds semantics: it changes what the accessibility tree announces (remember lesson 1: the tree is what the screen reader reads). ARIA never changes behaviour.

Take a plain <div>. You add role="button". The screen reader will now announce "button". Victory? No. That div still doesn't respond to the Enter key. It doesn't respond to Space. It isn't even keyboard-focusable. ARIA changed the label, not the machine behind it.

For a div to truly imitate a button, you must hand-code everything <button> gave you for nothing:

<div role="button" tabindex="0"
     onclick="submit()"
     onkeydown="if(event.key==='Enter'||event.key===' ')submit()">
  Submit
</div>

The role, plus tabindex="0" to make it focusable, plus a keyboard listener that handles Enter and Space. And the same thing, native:

<button onclick="submit()">Submit</button>

Eight fragile lines against one solid line. You see why the first rule exists.

When ARIA is, in fact, essential

ARIA has its exact place: where HTML has no tag to describe a dynamic state. Here are the legitimate uses, the ones you'll really meet.

aria-expanded="true|false": on the trigger of an accordion or a dropdown menu. It announces "expanded" or "collapsed". HTML has no tag for that state, ARIA carries it.
aria-current="page": on the active link of a navigation menu. The screen reader announces "current page" and the user knows where they are.
aria-describedby: you already used it in lesson 5, to tie an error message to its field. That's ARIA, and it's exactly its right use.
Live regions: aria-live="polite" announces a change without interrupting the user. Perfect for a "3 results found" that appears after a filter. The value assertive also exists, but it cuts in: reserve it for true emergencies (a blocking error).

Golden rule: ARIA describes a state HTML can't express (open/closed, current page, a region that updates). It never replaces a native element. If you're writing role="button", ask yourself first: why not a real <button>?

Predict before reading on

A dev wrote <div role="button" onclick="pay()">Pay</div>. Marie navigates by keyboard, reaches (she thinks) this button and presses Enter. What happens?

Show the answer

Nothing. And worse: Marie couldn't even stop on it. Without tabindex="0", the div isn't focusable: tabbing skipped right past it. And even if she reached it, role="button" only changed the announcement, not the behaviour: no listener handles the Enter key, so pay() never fires. ARIA stuck a "button" label on something that isn't one. With a real <button>, Marie would have paid without a thought.

Real testing, without spending a thing

You can seriously audit a page with 100% free tools. Here they are by return on effort: from most rewarding to most demanding.

1. The keyboard test (30 seconds, huge)

The one from lesson 3. Put the mouse away. Tab, Tab, Tab through the page. You check three things: everything interactive is reachable, the focus ring is always visible, and the order follows the reading logic. This free test catches a huge share of problems in half a minute. It's the best effort-to-result ratio in the whole field.

2. axe DevTools or Lighthouse (automated)

A browser extension (axe DevTools) or Chrome's Lighthouse tab scans your page and lists errors: insufficient contrast, image without alt, missing label. Handy. But beware the false sense of security.

A Lighthouse score of 100 does not mean "accessible". Automated tools only detect roughly 30 to 40% of accessibility problems (source: The A11Y Project). They catch what can be measured mechanically (a missing alt, a contrast ratio) but are blind to the essentials: an alt that's present but wrong, an absurd tab order, a label that lies. The tool's green says "no obvious error", never "accessible".

3. The screen reader (the real test)

The only way to hear your page as a blind user does. And it's free: NVDA on Windows (open source, download it), VoiceOver already built into Mac (turn it on with Cmd+F5). Five commands are enough to start:

Tab: move from one interactive element to the next (links, buttons, fields).
Arrows: read the content word by word, line by line.
H: jump from heading to heading (you hear your lesson-2 hierarchy).
D: jump from landmark to landmark (the page regions).
Ctrl: silence the voice when it talks too much.

Close your eyes. Try to complete a task on your own page: find a product, fill a field. Testing one single page yourself with a screen reader will teach you more than ten articles. It's uncomfortable at first, then it becomes obvious.

Final lab: the full audit

Here's a summary page. It packs the six mistakes seen across the course, one per lesson. Read the code, spot them, then unfold the fix. Each problem points back to its lesson: this is your final review.

<div onclick="open()">View cart</div>

<h1>My shop</h1>
<h3>Our products</h3>

<img src="promo.jpg">

<input type="text" placeholder="Your email">

<p style="color:#bbb">Required field</p>

<div role="button">Pay</div>

Show the 6 problems, fixed

The clickable div (lesson 2): <div onclick> is neither focusable nor announced as a button. → <button onclick="open()">View cart</button>.
The heading skip (lesson 2): it jumps from <h1> to <h3>, the <h2> is missing. The hierarchy is broken. → use <h2>Our products</h2>.
The image with no alt (lesson 4): <img> with no alt is announced by its filename or ignored. → alt="Promotion: 20% off the whole range" (or alt="" if purely decorative).
The placeholder-as-label (lesson 5): the placeholder is not a label, it disappears on typing. → a real <label for="email">Your email</label> tied to the field.
The too-pale grey (lesson 6): #bbb on white falls below the required 4.5:1 ratio. → a dark grey that passes contrast, for example #595959.
The fake ARIA button (lesson 7): role="button" on a div announces "button" but doesn't respond to the keyboard. → a real <button>Pay</button>.

Six mistakes, six lessons. If you spotted them all, you have the course reflexes.

The legal framework in 2026

Accessibility is no longer just a best practice: it's an obligation that keeps tightening. The facts, without drama.

What to know (verified facts):

European Accessibility Act (EU directive 2019/882): applicable since 28 June 2025 to new products and services (e-commerce, online banking, e-books, ticketing...). Service micro-enterprises (fewer than 10 people and under 2 million euros in turnover) get an exemption.
In France, the RGAA (general accessibility reference), currently version 4.1.2: it's the operational form of WCAG 2.1 in 106 control criteria. An RGAA 5, aligned with WCAG 2.2 and under Arcom oversight, is announced for late 2026.
The technical reference stays WCAG (Web Content Accessibility Guidelines). Level AA is the standard target set by regulation.

Your seven reflexes, in one loop

You've done the full tour. Here's the course summed up in seven reflexes, one per lesson, in the order you apply them as you code.

Think of everyone (lesson 1): permanent, temporary, situational disabilities. You code for the accessibility tree, not only for the screen.
Semantic HTML first (lesson 2): the right native element does 80% of the work, for free.
Test by keyboard (lesson 3): everything reachable, focus visible, logical order.
Describe images (lesson 4): a useful alt, or an empty alt if decorative.
Tie label to field (lesson 5): every field has its real label, errors are linked.
Check contrast (lesson 6): 4.5:1 minimum, colour never carries the info alone.
ARIA as a last resort (lesson 7): native first, ARIA only for what it can say extra.

Now the loop. Pick up your journal from lesson 1: you noted there that accessibility felt like a layer to add at the end. You now know it's the opposite. Accessibility is not an end-of-project checklist. It's a way of writing HTML from the very first line. The right element, the right label, the right contrast, laid down as you write: that's the craft.

Next step

You've got the reflexes. The site's applied Projects put them into practice: every project includes an accessibility review, just like in real life. That's where you stop learning the rules and start applying them on something concrete.

The applied projects →