Accessibilité (A11y)

#Accessibilité (A11y)Copier le lien

L’accessibilité n’est pas une option. Elle garantit que l’interface est utilisable au clavier, compréhensible par les lecteurs d’écran et confortable pour des profils variés. Une page plus accessible est aussi plus robuste: sémantique claire, états visibles, erreurs annoncées.

Concentrez‑vous d’abord sur trois axes concrets: l’ordre de tabulation et la visibilité du focus, le couplage des libellés aux champs, et des alternatives textuelles pertinentes. Respectez les préférences de l’utilisateur (réduction des animations, thème) et gardez un contraste suffisant.

#Modal accessible: de l’ouverture à la fermetureCopier le lien

Voici les éléments indispensables: un titre référencé par aria-labelledby, un aria-modal sur le conteneur, un focus donné à un élément interactif à l’ouverture, la restitution du focus à l’élément déclencheur à la fermeture, et un « focus trap » pour éviter de sortir du modal au clavier.

#Animation: cycle d’un modal accessibleCopier le lien

Exemple de structure minimale:

1<button id="open">Ouvrir</button>2<div role="dialog" aria-modal="true" aria-labelledby="title">3  <h2 id="title">Paramètres</h2>4  <button aria-label="Fermer">×</button>5  <form>6    <label for="name">Nom</label>7    <input id="name" />8    <button>Valider</button>9  </form>10  <!-- focus trap: gérer Tab/Shift+Tab pour boucler dans le dialog -->11  <!-- restituer le focus à #open à la fermeture -->12  <!-- masquer l’arrière-plan aux AT: aria-hidden sur le reste de la page tant que le modal est ouvert -->13</div>

Erreurs fréquentes à éviter: des div cliquables sans rôle et sans clavier; des placeholders utilisés à la place de vrais labels; des messages d’erreur uniquement colorés sans texte explicite; des animations lourdes non désactivables malgré prefers-reduced-motion.

Mini‑exercice: créez un petit modal qui s’ouvre au clavier et respecte les points ci‑dessus. Vérifiez au Tab que le focus ne s’échappe pas et que la touche Échap fonctionne.