Partie 11 — Accessibilité en React & Next.js

⏱️ TL;DR — React et Next.js n’empêchent pas l’accessibilité : ils la déplacent. Le HTML sémantique, l’ARIA, le clavier, les formulaires — tout ce que tu as appris reste vrai. Mais la stack introduit des pièges spécifiques : une navigation SPA muette pour le lecteur d’écran, un focus que plus personne ne gère à ta place, des alt oubliés dans du JSX, une hydratation qui casse le focus. Cette partie applique tout le cours à ta stack quotidienne, et te donne les réflexes React/Next qui font la différence.

Le problème qu’on résout

Beaucoup de devs pensent que « React gère l’accessibilité ». C’est faux. React génère du DOM : si tu écris une <div onClick>, React produit fidèlement une <div> inaccessible. Next.js ajoute une couche d’aides (annonceur de route, next/image qui impose alt), mais l’essentiel du travail reste à ta charge. Pire : le rendu côté client masque des problèmes qu’un site multipage n’avait pas — la page ne se recharge plus, donc le lecteur d’écran n’est plus relancé à chaque navigation, et le focus reste bloqué là où il était. On répare ça en reliant chaque notion du cours à la mécanique concrète de React et de Next.js.

Ce que tu sauras faire à la fin de cette partie

• Traduire les réflexes a11y en JSX : htmlFor, className, useId(), Fragments, refs.
• Installer et exploiter eslint-plugin-jsx-a11y — et connaître ses limites.
• Comprendre pourquoi une SPA est muette au changement de route, et la rendre annoncée.
• Gérer le focus proprement en React : useRef, useEffect, focus trap, restitution du focus.
• Choisir une librairie headless accessible (Radix, React Aria, Headless UI, Ariakit) au lieu de réinventer.
• Dérouler une checklist Next.js pour éliminer les pièges récurrents.

Les chapitres

On commence : Spécificités React — comment le JSX change tes réflexes a11y.