L'accessibilité web n'est plus une option : depuis le 28 juin 2025, l'European Accessibility Act la rend obligatoire pour la plupart des services numériques du privé. Voici un guide pratique pour développeurs : les principes WCAG, les erreurs les plus fréquentes, et comment les corriger avec du vrai code.
Pourquoi l'accessibilité, et pourquoi maintenant
Rendre un site accessible, c'est permettre à une personne aveugle, malvoyante, sourde, à mobilité réduite ou en situation de handicap cognitif d'utiliser le service comme tout le monde. C'est environ 20 % de la population, et au-delà du handicap permanent, tout le monde profite d'un site accessible : navigation au clavier, contrastes lisibles en plein soleil, sous-titres dans les transports.
Le contexte a changé en 2025. L'European Accessibility Act (directive 2019/882) s'applique depuis le 28 juin 2025 à de nombreux services numériques du secteur privé : e-commerce, banque, transport, services en ligne. En France, le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) reste la déclinaison officielle pour le secteur public et certaines entreprises. Les deux s'appuient sur le même socle technique : les WCAG.
À retenir : l'accessibilité n'est plus seulement une question d'éthique ou d'image. C'est une obligation légale, avec un risque de sanction, et elle améliore aussi le SEO et le taux de conversion. Autant la traiter dès la conception.
WCAG : les 4 principes et les 3 niveaux
Les Web Content Accessibility Guidelines (version 2.2, la plus récente) reposent sur 4 principes, résumés par l'acronyme POUR : Perceptible, Utilisable, Compréhensible, Robuste. Chaque critère est classé en trois niveaux de conformité.
| Niveau | Exigence | Cible légale |
|---|---|---|
| A | Minimum vital | Insuffisant seul |
| AA | Standard attendu | Oui (EAA, RGAA) |
| AAA | Renforcé | Optionnel, par cas |
Le niveau visé par la loi est le AA. C'est lui qui doit guider vos choix au quotidien.
Les 6 erreurs les plus fréquentes (et leurs correctifs)
1. Du HTML non sémantique (la div à tout faire)
L'erreur la plus répandue : un <div onclick> à la place d'un vrai bouton. Le lecteur d'écran ne l'annonce pas comme cliquable, et il n'est pas focusable au clavier. La solution est gratuite : utiliser le bon élément.
<!-- À éviter : invisible pour le clavier et le lecteur d'écran -->
<div class="btn" onclick="submit()">Envoyer</div>
<!-- Correct : focusable, activable au clavier, annoncé comme bouton -->
<button type="submit">Envoyer</button>
2. Des images sans alternative textuelle
Toute image porteuse de sens a besoin d'un attribut alt décrivant son contenu. Une image purement décorative prend un alt vide pour que le lecteur d'écran l'ignore.
<img src="graphique-ventes.png"
alt="Ventes en hausse de 30 % entre janvier et mars">
<!-- Image décorative : alt vide, jamais d'alt manquant -->
<img src="separateur.svg" alt="">
3. Un contraste insuffisant
Le gris clair sur fond blanc est joli en maquette, illisible en vrai. Le niveau AA exige un ratio de contraste d'au moins 4,5:1 pour le texte normal, et 3:1 pour le grand texte (à partir de 24px, ou 18,5px en gras).
| Type de texte | Ratio minimum AA |
|---|---|
| Texte normal | 4,5:1 |
| Grand texte | 3:1 |
| Composants et icônes | 3:1 |
4. Une navigation au clavier cassée
Un utilisateur qui ne peut pas se servir d'une souris doit pouvoir tout faire à la touche Tab. Deux règles : ne jamais supprimer le focus visible, et fournir un lien d'évitement pour sauter directement au contenu.
/* Ne supprimez JAMAIS l'outline sans le remplacer */
:focus-visible {
outline: 2px solid var(--tb-accent);
outline-offset: 2px;
}
<!-- Lien d'évitement, premier élément focusable de la page -->
<a href="#contenu" class="skip-link">Aller au contenu</a>
5. Des formulaires sans étiquettes liées
Un champ sans <label> associé est une zone de saisie muette pour le lecteur d'écran. L'association se fait avec for et id.
<label for="email">Adresse e-mail</label>
<input id="email" type="email" name="email"
autocomplete="email" required>
6. ARIA mal utilisé (pire que pas d'ARIA)
ARIA sert à combler ce que le HTML natif ne sait pas exprimer, pas à le remplacer. La première règle d'ARIA : si un élément HTML natif existe, utilisez-le. Un mauvais role casse plus qu'il ne répare. Réservez ARIA aux composants riches (onglets, modales, menus) et aux contenus dynamiques.
<!-- Annonce d'un message dynamique sans déplacer le focus -->
<div aria-live="polite" id="statut"></div>
Comment tester son accessibilité
Aucun outil automatique ne couvre tout. La bonne approche combine automatique et manuel.
- Au clavier : débranchez la souris et parcourez tout le site à la touche Tab. Si vous y arrivez, vous avez déjà réglé la moitié des problèmes.
- Au lecteur d'écran : testez avec VoiceOver (macOS/iOS), NVDA (Windows) ou TalkBack (Android).
- En automatique : axe DevTools, Lighthouse ou Pa11y détectent les erreurs mécaniques (contraste, alt manquant, labels).
- Le contraste : le panneau de contraste de Chrome DevTools ou un outil dédié.
À retenir : les outils automatiques attrapent environ 30 % à 40 % des problèmes. Le reste se découvre au clavier et au lecteur d'écran. Un audit sérieux fait toujours les deux.
La checklist accessibilité de base
- HTML sémantique (boutons, liens, titres
h1-h6hiérarchisés) - Attribut
altpertinent sur chaque image porteuse de sens - Contraste AA vérifié (4,5:1 texte normal)
- Navigation complète au clavier, focus visible conservé
- Lien d'évitement vers le contenu principal
- Étiquettes liées sur tous les champs de formulaire
- Messages d'erreur et contenus dynamiques annoncés (
aria-live) - Test au clavier et au lecteur d'écran avant mise en ligne
Pour aller plus loin
L'accessibilité fait partie de la qualité globale d'un site, au même titre que la performance. Voir aussi ma méthode d'audit : Audit de performance web, ma méthode en 5 étapes.
Votre site doit se mettre en conformité avec l'European Accessibility Act ? Parlons-en.