Accessibilité (a11y)

Pourquoi l’accessibilité est importante

L’accessibilité consiste à concevoir des produits pour les personnes qui utilisent des technologies d’assistance, naviguent au clavier, ont besoin d’un contraste plus élevé ou préfèrent une réduction des animations. Environ une personne sur six vit avec un handicap, et presque tout le monde bénéficie de l’accessibilité à un moment ou à un autre — qu’il s’agisse d’un bras cassé, d’un écran trop lumineux ou d’un train bruyant.

C’est également une exigence croissante. La législation et les règles de passation de marchés dans de nombreux pays se réfèrent aux WCAG ; l’accessibilité est donc un standard professionnel et non une simple option. Le point rassurant est que la majeure partie du travail consiste simplement à bien maîtriser les bases.

WCAG et POUR

Les Web Content Accessibility Guidelines définissent la norme. Leurs quatre principes sont :

• Perceptible — le contenu peut être perçu, par exemple via des alternatives textuelles pour les images et un contraste suffisant.
• Utilisable — tout fonctionne au clavier et ne nécessite pas un pointage précis.
• Compréhensible — le contenu et le comportement sont prévisibles et clairs.
• Robuste — le contenu fonctionne avec les agents utilisateurs et les technologies d’assistance actuels et futurs.

Chaque principe possède des critères de succès testables aux niveaux A, AA et AAA. La plupart des équipes visent le niveau AA.

Le HTML sémantique est la base

L’essentiel de l’accessibilité repose sur l’utilisation des bons éléments. Les éléments natifs intègrent nativement des rôles, des états et des comportements clavier.

<!-- semantics.html -->
<header>
  <nav aria-label="Main">
    <a href="/">Home</a>
  </nav>
</header>
<main>
  <h1>Dashboard</h1>
  <button type="button" aria-expanded="false">Filters</button>
</main>

Un <button> peut recevoir le focus, répond aux touches Enter et Espace, et est annoncé comme un bouton. Un <div onclick> ne possède aucune de ces propriétés. C’est pourquoi le guide du HTML sémantique précède celui-ci : la sémantique est le moyen le plus simple et le plus efficace d’améliorer l’accessibilité.

Support du clavier

Chaque élément interactif doit être accessible et utilisable uniquement avec un clavier.

• Utilisez des contrôles natifs, qui sont focalisables par défaut.
• Maintenez un ordre de tabulation logique ; celui-ci doit suivre l’ordre visuel.
• Fournissez un lien d’évitement (skip link) pour permettre aux utilisateurs de passer la navigation répétitive.
• Ne bloquez jamais le focus à l’intérieur d’un composant sans possibilité d’en sortir.
• Affichez un indicateur de focus clair et ne supprimez jamais les contours (outlines) sans proposer de remplacement visible.

<!-- skip.html -->
<a href="#main" class="skip-link">Skip to content</a>
<main id="main" tabindex="-1">...</main>

Gestion du focus

Le focus est l’équivalent du curseur pour l’utilisateur du clavier. Gérez-le avec précision :

• Lorsqu’un dialogue s’ouvre, déplacez le focus à l’intérieur et verrouillez-le (focus trap).
• Lorsqu’il se ferme, renvoyez le focus vers l’élément qui l’a ouvert.
• Lors d’une navigation côté client, déplacez le focus vers le nouveau contenu.
• Après des erreurs de validation, placez le focus sur le premier champ invalide.

Les dialogues modernes peuvent utiliser l’élément <dialog> avec showModal(), qui gère une grande partie de ces aspects pour vous.

Alternatives textuelles

Les images doivent disposer d’alternatives textuelles qui transmettent leur intention selon le contexte.

• Les images informatives reçoivent une description de ce qu’elles communiquent.
• Les images décoratives reçoivent alt="" afin qu’elles soient ignorées.
• Les images fonctionnelles, comme une icône à l’intérieur d’un lien, décrivent l’action.
• Les images complexes nécessitent une description plus détaillée à proximité.

Le même principe s’applique aux médias : prévoyez des sous-titres pour les vidéos, des transcriptions pour l’audio et des labels pour chaque contrôle de formulaire.

L’ARIA, à utiliser avec prudence

L’ARIA ajoute une sémantique que le HTML ne peut pas exprimer, mais il est facile de mal l’utiliser. La première règle de l’ARIA est la suivante : n’utilisez pas l’ARIA si un élément natif remplit déjà cette fonction. Un <div role="button"> est pire qu’un <button> sur presque tous les plans.

Lorsque vous en avez réellement besoin :

• aria-label nomme un élément qui n’a pas de texte visible.
• aria-labelledby fait référence à un texte visible qui nomme l’élément.
• aria-describedby lie un contrôle à un indice ou à un message d’erreur.
• aria-expanded, aria-controls et aria-live décrivent l’état et les mises à jour dynamiques.

Testez l’ARIA avec un véritable lecteur d’écran ; un ARIA incorrect est souvent pire qu’une absence totale d’ARIA.

Couleur et contraste

Le texte doit présenter un contraste suffisant par rapport à son arrière-plan :

• 4,5:1 pour le texte normal, 3:1 pour le texte large au niveau AA.
• 3:1 pour les icônes, les bordures et les indicateurs de focus.
• N’utilisez jamais la couleur seule pour transmettre une information ; ajoutez du texte, des icônes ou des motifs.

Vérifiez le contraste à l’aide d’un outil et testez votre design en niveaux de gris pour détecter toute communication reposant uniquement sur la couleur.

Mouvement et préférences

Respectez les préférences de l’utilisateur.

/* motion.css */
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Les effets de parallaxe importants et les animations au défilement sont les causes les plus fréquentes. Évitez également la lecture automatique de médias avec du son, et proposez des commandes pour tout élément en mouvement.

Tests

Les outils automatisés permettent de détecter environ un tiers des problèmes. Combinez-les avec des tests manuels :

1. Lancez axe ou Lighthouse pour identifier les violations courantes.
2. Naviguez uniquement au clavier pour vérifier le focus et l’ordre de tabulation.
3. Zoomez à 200 % et vérifiez que rien ne se casse ou ne se chevauche.
4. Essayez un lecteur d’écran : VoiceOver, NVDA ou Narrator.
5. Vérifiez le contraste et assurez-vous que la couleur n’est pas le seul moyen de transmettre une information.
6. Testez les formulaires avec des erreurs et du contenu dynamique.

Le guide de Testing Library explique comment les requêtes accessibles permettent d’intégrer l’accessibilité directement dans votre suite de tests.

Bonnes pratiques

• Commencez par du HTML sémantique avant d’ajouter des attributs ARIA.
• Rendez tout élément utilisable au clavier avec un indicateur de focus visible.
• Fournissez des alternatives textuelles pour tous les médias significatifs.
• Respectez le niveau de contraste AA et ne vous appuyez jamais uniquement sur la couleur.
• Gérez le focus pour les dialogues, la navigation et les erreurs.
• Respectez les préférences de réduction du mouvement et évitez la lecture automatique des médias.
• Testez avec des outils automatisés et de véritables technologies d’assistance.

Erreurs courantes

• Utiliser des divs comme boutons ou liens.
• Supprimer les contours de focus (focus outlines) pour des raisons esthétiques.
• Texte alternatif (alt text) manquant ou peu utile.
• Ajouter des attributs ARIA de manière incorrecte, brisant ainsi la sémantique native.
• Texte à faible contraste et états indiqués uniquement par la couleur.
• Ignorer la navigation au clavier dans les widgets personnalisés.

Et après ?

L’accessibilité est une pratique, pas une simple liste de cases à cocher. Appuyez-vous sur le HTML sémantique, rendez vos formulaires utilisables grâce aux Formulaires et à la validation, et intégrez tout cela à vos tests avec Testing Library. Ensuite, choisissez une page, naviguez-y uniquement au clavier et corrigez les problèmes que vous rencontrerez.