Guides Next.js

Accessibilité Next.js : Image, Link, Head, SSR et bonnes pratiques RGAA

Next.js : le framework React avec des avantages natifs pour l'accessibilité

Next.js, le meta-framework React de Vercel, est devenu le choix dominant pour les applications React en production. Ses fonctionnalités de rendu serveur (SSR), génération statique (SSG) et composants optimisés (Image, Link) apportent des avantages natifs pour l'accessibilité.

Le composant Image et l'accessibilité

Le composant next/image optimise les images avec lazy loading, redimensionnement automatique et formats modernes (WebP, AVIF). Pour l'accessibilité :

  • Alt obligatoire : Next.js affiche un warning ESLint si la prop alt est manquante. C'est un garde-fou précieux pour le RGAA critère 1.1
  • Images de décoration : utilisez alt="" pour les images décoratives (RGAA 1.2)
  • Dimensions explicites : les props width et height évitent le layout shift (CLS), améliorant l'expérience pour tous les utilisateurs
  • Placeholder blur : le placeholder flou évite un contenu vide pendant le chargement, ce qui est préférable pour les utilisateurs de lecteurs d'écran

Le composant Link et la navigation

Le composant next/link gère les navigations côté client :

  • Rendu en <a> : depuis Next.js 13, le composant rend directement un <a> HTML natif, excellent pour l'accessibilité
  • Préchargement : le prefetch des pages améliore les performances sans impacter l'accessibilité
  • Focus : lors d'une navigation client, le focus doit être géré manuellement (pas natif dans Next.js)

Pour améliorer l'accessibilité de la navigation :

// Dans app/layout.tsx : gérer le focus après navigation useEffect(() => { const main = document.querySelector('main'); if (main) { main.setAttribute('tabindex', '-1'); main.focus(); main.removeAttribute('tabindex'); } }, [pathname]);

Métadonnées et Head

Next.js 13+ utilise l'API Metadata pour gérer les balises head. Pour l'accessibilité RGAA :

  • Title dynamique : chaque page doit avoir un titre unique et descriptif (RGAA 8.5/8.6)
  • Langue : l'attribut lang doit être défini sur <html> (RGAA 8.3). En Next.js : dans app/layout.tsx, ajoutez <html lang="fr">
  • Meta viewport : Next.js inclut par défaut une meta viewport correcte
  • Changements de langue : pour les sites multilingues, la langue doit changer avec la route

SSR et accessibilité

Le rendu côté serveur (SSR) apporte des avantages significatifs :

  • Contenu sans JavaScript : le HTML est envoyé depuis le serveur, accessible même si JavaScript échoue. C'est un avantage pour les technologies d'assistance anciennes
  • SEO et accessibilité alignés : le contenu est lisible par les moteurs de recherche ET par les lecteurs d'écran dès le premier rendu
  • Performance : le First Contentful Paint rapide réduit le temps d'attente pour les utilisateurs de technologies d'assistance

Cependant, l'hydratation (passage du HTML statique au React interactif) peut causer des problèmes : un élément peut apparaître interactif visuellement mais ne pas l'être encore. Utilisez useEffect pour gérer les fonctionnalités qui dépendent de l'hydratation.

App Router et accessibilité

Le nouveau App Router de Next.js introduit les Server Components. Implications pour l'accessibilité :

  • Layouts partagés : les layouts permettent de centraliser les landmarks (header, nav, main, footer) — excellent pour la cohérence RGAA
  • Loading states : le fichier loading.tsx doit être accessible (pas de spinner sans aria-label)
  • Error boundaries : le fichier error.tsx doit présenter les erreurs de manière accessible
  • Streaming : le streaming SSR avec Suspense doit annoncer le contenu chargé aux lecteurs d'écran

Middleware et accessibilité

Le middleware Next.js peut être utilisé pour des redirections basées sur la langue, la géolocalisation ou l'authentification. Assurez-vous que ces redirections ne créent pas de boucles ou de situations confuses pour les technologies d'assistance.

Tests d'accessibilité Next.js

  • next-axe : intégration axe-core dans le processus de build Next.js
  • Playwright + @axe-core/playwright : tests e2e avec vérification d'accessibilité sur les pages rendues côté serveur
  • Lighthouse CI : intégrez les scores Lighthouse Accessibility dans votre pipeline CI/CD
  • @next/eslint-plugin-next : inclut des règles a11y de base (alt sur Image)
Next.js offre des fondations solides pour l'accessibilité grâce au SSR et aux composants optimisés. Mais comme tout framework React, l'accessibilité finale dépend des choix du développeur.
Next.js apporte des avantages natifs : le SSR fournit du contenu sans JavaScript, le composant Image impose le texte alternatif, et les layouts centralisent les landmarks. Mais l'accessibilité des composants et interactions reste la responsabilité du développeur, comme avec React standard.
Utilisez le hook usePathname() pour détecter les changements de route et un useEffect pour déplacer le focus vers le main ou le h1. Next.js ne gère pas nativement le focus après navigation. Vous pouvez aussi utiliser un composant RouteAnnouncer avec aria-live pour annoncer les changements de page.
Le SSR est un avantage car il fournit du HTML dès le premier rendu, mais il ne suffit pas. Les composants interactifs nécessitent toujours une gestion correcte des attributs ARIA, de la navigation clavier et du focus. Le SSR résout le problème du « contenu vide sans JavaScript » mais pas les erreurs d'interaction.

Testez la conformité de votre site

Scannez votre site et obtenez un rapport détaillé avec recommandations IA.

Scanner mon site - 15€