Le robot d'un moteur de recherche est, sur le plan fonctionnel, un utilisateur aveugle doté d'une connexion rapide : il ne voit pas le design, il analyse la structure du document. C'est pourquoi presque tout ce qu'exige l'accessibilité (sémantique, hiérarchie, alternatives textuelles, noms de liens explicites) est aussi un signal SEO. Et depuis juin 2025, l'European Accessibility Act (EAA) fait de l'accessibilité une obligation légale pour la plupart des services numériques grand public dans l'UE : ce qui était un « plus » expose désormais à des sanctions.
Le terrain commun : une correction, deux bénéficiaires
- La hiérarchie des titres (
h1→h2→h3, sans saut, un seulh1) est le plan que suivent les lecteurs d'écran, et la structure dont les robots et les moteurs d'IA extraient et citent des sections. - Les repères sémantiques (
<nav>,<main>,<article>,<footer>) indiquent aux technologies d'assistance et aux parseurs la nature de chaque zone. Une soupe de<div>est plus difficile à interpréter pour les parseurs et fait échouer les audits. - Le texte alt sert les lecteurs d'écran et la recherche d'images avec la même chaîne de caractères.
- Les noms de liens : « cliquez ici » ne passe pas WCAG (un lien doit avoir du sens hors contexte) et gaspille le signal de l'ancre. Une seule reformulation règle les deux problèmes.
- Les attributs
lang, sur<html>comme sur les passages en langue étrangère, alimentent la prononciation des lecteurs d'écran et la détection de langue pour votre hreflang. - Le CLS est un problème d'accessibilité avant d'être une métrique : les sauts de mise en page pénalisent surtout les personnes ayant des limitations motrices et visuelles. Corriger les Core Web Vitals, c'est faire de l'accessibilité.
L'accessibilité n'est pas un facteur de classement direct. Certains éléments de sa mise en œuvre, comme la structure sémantique et le texte descriptif, facilitent aussi l'interprétation de la page par les systèmes de recherche.
Next.js : l'imposer dans le pipeline
// .eslintrc — jsx-a11y détecte les alt manquants, les mauvais rôles et les contrôles sans libellé dès la PR
{
"extends": ["next/core-web-vitals", "plugin:jsx-a11y/recommended"]
}
next/imageexige déjàalt: ne vous dédouanez pas avec unalt=""vide sur des images porteuses de sens.- Définissez
<html lang={locale}>à partir du paramètre de route dans le layout racine. - Lancez Lighthouse accessibility à côté de performance dans la CI : c'est le même outillage que celui dont vous disposez déjà pour la surveillance, juste un contrôle de plus.
- L'automatisation détecte ~30–40 % des problèmes WCAG ; parcourir les chemins principaux uniquement au clavier détecte l'essentiel du reste. Si vous n'atteignez pas un élément avec Tab, le robot risque de ne pas l'atteindre par les liens.
EAA : l'échéance qui clôt la discussion
Depuis le 28 juin 2025, l'EAA couvre le e-commerce, la banque, les transports, les livres numériques et la plupart des services numériques grand public vendus dans l'UE (les microentreprises de moins de 10 personnes et de 2 M€ sont exemptées). L'application est nationale et fondée sur les plaintes : un tunnel de paiement inaccessible est désormais une exposition juridique, pas une ligne dans le backlog. Le seuil pratique est WCAG 2.1 AA (via EN 301 549), précisément le standard que visent les corrections ci-dessus.
Checklist :
- Un seul
h1par page ; niveaux de titres sans saut ; repères sémantiques en place - Chaque image porteuse de sens a un vrai alt ; chaque lien a du sens hors contexte
-
langdéfini depuis la locale sur<html>et sur les passages en langue étrangère - jsx-a11y dans ESLint + contrôle Lighthouse a11y dans la CI ; parcours principaux testés au clavier
- Applicabilité de l'EAA évaluée ; parcours grand public conformes à WCAG 2.1 AA