Accessibilite Next.js : guide RGAA complet

1. Introduction : Next.js et les défis d'accessibilité

Next.js se distingue des applications React classiques par son architecture hybride. Contrairement à une SPA (Single Page Application) pure où tout le rendu est côté client, Next.js propose plusieurs stratégies de rendu : SSR (Server-Side Rendering), SSG (Static Site Generation), ISR (Incremental Static Regeneration) et streaming avec React Suspense.

Cette flexibilité est un atout pour la performance et le SEO, mais elle crée des situations complexes pour l'accessibilité. Quand le HTML est généré côté serveur, les technologies d'assistance reçoivent un document complet dès le chargement initial — c'est un avantage. Mais les navigations subséquentes sont gérées côté client par le router Next.js, ce qui signifie que les lecteurs d'écran ne sont pas informés du changement de page.

L'introduction de l' App Router dans Next.js 13 a modifié en profondeur la façon de structurer les applications. Les Server Components, les layouts imbriqués, les fichiers spéciaux (loading.tsx, error.tsx, not-found.tsx) et le streaming introduisent de nouveaux patterns qui ont chacun des implications pour l'accessibilité.

Le Pages Router, encore largement utilisé, présente d'autres défis : l'absence de metadata API native oblige à utiliser des packages tiers comme next-seo, et la gestion du focus entre les pages nécessite une configuration manuelle via le composant _app.tsx.

Enfin, le streaming (activé par défaut avec l'App Router et Suspense) fait apparaître le contenu progressivement. Si un lecteur d'écran commence à lire une page dont le contenu n'est pas encore entièrement chargé, l'utilisateur peut manquer des informations. Il est essentiel de signaler les états de chargement avec les attributs ARIA appropriés.

2. Erreurs d'accessibilité courantes en Next.js

Voici les problèmes d'accessibilité les plus fréquents dans les projets Next.js, et pourquoi ils posent problème.

2.1. next/image sans attribut alt pertinent

Le composant

rend l'attribut alt obligatoire en TypeScript, mais beaucoup de développeurs passent une chaîne vide (alt="") ou un texte générique ("image", "photo") pour supprimer l'erreur de compilation. Une image informative sans alternative textuelle pertinente est invisible pour les utilisateurs de lecteurs d'écran, ce qui viole le critère RGAA 1.1.

2.2. Attribut lang manquant ou incorrect sur la balise html

Dans l'App Router, l'attribut lang se définit dans le fichier

racine. Oublier cet attribut ou le définir de manière incohérente (par exemple "en" pour un contenu en français) empêche les lecteurs d'écran de prononcer correctement le texte. Un lecteur d'écran configuré en français qui rencontre un document déclaré en anglais va tenter de lire le texte avec une prononciation anglaise, rendant le contenu incompréhensible.

2.3. Layout shift perturbant les lecteurs d'écran

Les Cumulative Layout Shifts (CLS) ne sont pas seulement un problème de performance. Quand le contenu se déplace pendant le chargement (images sans dimensions, polices qui changent, composants chargés dynamiquement), les technologies d'assistance peuvent perdre le contexte. L'utilisateur qui naviguait dans une section se retrouve soudainement dans une autre partie de la page sans comprendre ce qui s'est passé. Next.js génère automatiquement les dimensions des images avec next/image, mais les composants chargés dynamiquement avec

sans placeholder peuvent provoquer des shifts importants.

2.4. Changement de route sans gestion du focus

C'est le problème d'accessibilité le plus critique et le plus ignoré dans les applications Next.js. Lors d'une navigation client-side (clic sur un

), le contenu de la page change mais le focus reste sur le lien cliqué ou se perd complètement. Un utilisateur de lecteur d'écran ne reçoit aucune indication qu'une nouvelle page a été chargée. Il doit naviguer manuellement pour découvrir le nouveau contenu. C'est équivalent à ouvrir un livre à une nouvelle page sans le dire à quelqu'un qui ne voit pas.

2.5. Server Components et logique d'accessibilité

Les React Server Components ne peuvent pas utiliser d'état, d'effets ou de refs. Or, de nombreux patterns d'accessibilité nécessitent de la logique côté client : gestion du focus, toggle aria-expanded, trap du focus dans une modale, annonces live regions. L'erreur courante est de tenter d'implémenter ces patterns dans un Server Component, ce qui échoue silencieusement ou provoque une erreur de compilation. La solution n'est pas de tout transformer en Client Components, mais d'identifier précisément quelles parties de l'interface nécessitent de l'interactivité et de les isoler dans des composants marqués

.

3. Bonnes pratiques avec exemples de code

3.1. next/image avec texte alternatif

Le composant Image de Next.js optimise automatiquement les images (formats, tailles, lazy loading), mais l'accessibilité dépend entièrement de l'attribut alt que vous fournissez. Distinguez toujours les images informatives des images décoratives.

3.2. Metadata API pour des titres de page accessibles

Le titre de la page est le premier élément lu par un lecteur d'écran. Il doit être unique, descriptif et suivre un schéma cohérent. La Metadata API de Next.js (App Router) simplifie cette gestion avec l'export statique ou la fonction generateMetadata pour les pages dynamiques.

3.3. Gestion du focus au changement de route

Note : le Pages Router de Next.js incluait un route announcer intégré (next-route-announcer). L'App Router ne l'inclut pas encore — vous devez donc implémenter votre propre composant. Placez-le dans votre layout racine pour qu'il s'applique à toutes les navigations.

3.4. États de chargement accessibles avec loading.tsx

Le fichier loading.tsx de Next.js affiche automatiquement un fallback pendant le chargement d'une page. Pour que les technologies d'assistance informent l'utilisateur, utilisez aria-busy et une annonce live region.

3.5. Gestion d'erreur accessible avec error.tsx

Le fichier error.tsx capture les erreurs de rendu. L'erreur doit être annoncée aux technologies d'assistance et proposer une action de récupération accessible.

3.6. next/link et navigation client-side accessible

Le composant Link de Next.js effectue une navigation côté client (prefetching + changement de route sans rechargement complet). Pour l'accessibilité, assurez-vous que chaque lien a un intitulé explicite et que les liens ouvrant un nouvel onglet le signalent.

3.7. Server vs Client Components pour l'accessibilité

La règle est simple : gardez la structure sémantique HTML dans les Server Components et isolez la logique interactive dans les Client Components. Cela réduit la quantité de JavaScript côté client tout en conservant les patterns d'accessibilité nécessaires.

4. Critères RGAA clés pour Next.js

Parmi les 106 critères du RGAA 4.1.2, voici ceux qui sont particulièrement impactés par l'architecture Next.js et les choix techniques du framework.

5. Outils et packages recommandés

Un écosystème d'outils permet de détecter, tester et prévenir les problèmes d'accessibilité dans vos projets Next.js. Voici les indispensables.

6. Checklist accessibilité Next.js

Utilisez cette checklist pour vérifier l'accessibilité de votre application Next.js avant chaque mise en production.