European Accessibility Act : ce qui change le 28 juin 2025 pour les développeurs

Le 28 juin 2025, l'European Accessibility Act (directive européenne 2019/882) entre en application. Jusqu'ici, l'obligation d'accessibilité numérique concernait surtout le secteur public. Désormais, de nombreux services privés doivent eux aussi être utilisables par les personnes en situation de handicap. Pour les équipes produit et les développeurs, c'est un changement majeur.

Cet article est une synthèse technique, pas un avis juridique : pour votre situation précise, rapprochez-vous d'un juriste.

Qui est concerné ?

La directive couvre des produits (ordinateurs, smartphones, terminaux de paiement, liseuses…) et surtout des services, dont :

• Le commerce en ligne : sites et applications de vente aux consommateurs.
• Les services bancaires aux particuliers.
• Le transport de voyageurs : sites, applications, billetterie en ligne.
• Les livres numériques et les communications électroniques.

Les micro-entreprises de services (moins de 10 salariés et moins de 2 millions d'euros de chiffre d'affaires ou de bilan) sont exemptées. Des périodes de transition existent pour certains services et contrats déjà en place.

Le référentiel technique : WCAG 2.1 niveau AA

Concrètement, la conformité s'appuie sur la norme européenne EN 301 549, qui reprend pour le web les critères des WCAG 2.1 niveau AA. Ces règles sont organisées autour de quatre principes.

Les erreurs les plus fréquentes (et comment les corriger)

1. Des images sans alternative textuelle

Toute image porteuse d'information a besoin d'un attribut alt descriptif. Une image purement décorative doit avoir alt="" pour être ignorée par les lecteurs d'écran.

2. Des contrastes insuffisants

Le texte courant doit avoir un ratio de contraste d'au moins 4,5:1 avec son arrière-plan (3:1 pour le grand texte et les éléments d'interface). Le gris clair sur fond blanc, très à la mode, échoue souvent.

3. Des éléments cliquables qui ne sont pas des boutons

// ❌ Inaccessible au clavier et invisible pour un lecteur d'écran
<div onClick={openMenu}>Menu</div>

// ✅ Focusable, activable avec Entrée/Espace, annoncé comme bouton
<button type="button" onClick={openMenu} aria-expanded={isOpen}>
  Menu
</button>

4. Des formulaires sans libellés

Un placeholder n'est pas un libellé : il disparaît à la saisie et n'est pas toujours annoncé. Chaque champ doit avoir un <label> associé, et les erreurs doivent être liées au champ.

<label htmlFor="email">Adresse e-mail</label>
<input
  id="email"
  type="email"
  aria-invalid={!!error}
  aria-describedby={error ? "email-error" : undefined}
/>
{error && <p id="email-error">{error}</p>}

5. Un focus invisible

Supprimer le contour de focus (outline: none) sans le remplacer rend la navigation au clavier impossible. Utilisez :focus-visible pour afficher un indicateur clair uniquement lors de la navigation au clavier.

Une méthode pour se mettre en conformité

• Auditer : commencez par les parcours critiques (inscription, achat, paiement) plutôt que par l'ensemble du site.
• Automatiser ce qui peut l'être : axe-core (via @axe-core/playwright ou l'extension navigateur) et Lighthouse détectent environ un tiers à la moitié des problèmes.
• Tester à la main : navigation au clavier seul, lecteur d'écran (VoiceOver, NVDA), zoom à 200 %.
• Corriger dans le design system : un composant corrigé une fois l'est partout. Des primitives comme Radix UI gèrent déjà le focus et les attributs ARIA.
• Publier une déclaration d'accessibilité et un moyen de contact pour signaler un problème.

Conclusion

L'European Accessibility Act transforme l'accessibilité d'une bonne pratique en obligation. La bonne nouvelle : l'essentiel repose sur du HTML sémantique, des contrastes suffisants et une navigation au clavier fonctionnelle. Intégrée dès la conception et dans le design system, l'accessibilité coûte peu ; ajoutée à la fin, elle coûte cher.