Accessibilité web : clavier, ARIA et contraste

L’accessibilité web consiste à concevoir une interface utilisable sans friction par les personnes présentant des différences visuelles, auditives, motrices ou cognitives. Beaucoup de développeurs la voient comme une case légale à cocher ou un « extra » ajouté à la fin. En réalité, l’accessibilité est une pratique fondamentale qui, lorsqu’elle est bien menée dès le départ, améliore aussi la qualité du code, le SEO et l’ergonomie globale. Ce guide se concentre sur les trois domaines qui font la plus grande différence : la navigation au clavier, le bon usage d’ARIA et le contraste des couleurs.

Pourquoi l’accessibilité est une base, pas un bonus

Une part importante de la population vit avec un handicap permanent ou temporaire, mais l’accessibilité ne concerne pas qu’elle. Un écran ébloui par le soleil, une souris cassée, une vidéo coupée, des yeux fatigués — tout le monde navigue parfois dans un contexte « handicapé ». Un site accessible aide les utilisateurs de lecteurs d’écran et de clavier tout en offrant aux moteurs de recherche une structure plus signifiante.

• Le HTML sémantique règle environ 80 % du travail : la bonne balise fait le bon travail.
• Les WCAG (Web Content Accessibility Guidelines) donnent un objectif mesurable ; la plupart des organisations prennent le niveau AA comme référence.
• Un code accessible est généralement plus robuste et plus facile à maintenir.

HTML sémantique : la fondation de l’accessibilité

L’erreur la plus fréquente est de tout construire avec des <div> et des <span>. Le navigateur ne sait pas qu’un <div> est cliquable, et un lecteur d’écran ne l’annonce pas. Utiliser le bon élément vous offre gratuitement le comportement clavier, la gestion du focus et les annonces de lecteur d’écran.

<!-- Mauvais : l’accessibilité doit être ajoutée à la main -->
<div class="btn" onclick="enregistrer()">Enregistrer</div>

<!-- Bon : clavier, focus et rôle sont inclus -->
<button type="button" onclick="enregistrer()">Enregistrer</button>

La même logique s’applique à <nav>, <main>, <header>, <footer> et aux champs de formulaire. Chaque <input> doit être lié à un <label> :

<label for="email">E-mail</label>
<input id="email" type="email" name="email">

Navigation au clavier : ça doit marcher sans souris

Tester une interface au clavier est le contrôle d’accessibilité le plus rapide qui soit. Avancez avec Tab et reculez avec Shift+Tab : atteignez-vous tous les liens, boutons et champs de formulaire ? Le focus est-il visible ?

• Ne supprimez jamais l’anneau de focus avec outline: none. S’il jure avec votre design, stylisez-le proprement avec :focus-visible.
• Utilisez l’ordre du DOM pour une séquence logique et évitez les valeurs positives de tabindex. Seuls tabindex="0" (inclure dans l’ordre) et tabindex="-1" (focus programmatique) sont nécessaires.
• Quand une fenêtre modale s’ouvre, piégez le focus à l’intérieur, et rendez-le au bouton déclencheur à la fermeture.

/* Un anneau de focus net, uniquement pour le clavier */
:focus-visible {
  outline: 2px solid #4f46e5;
  outline-offset: 2px;
}

Un lien d’évitement (skip link) est aussi d’une grande aide pour les utilisateurs au clavier :

<a class="skip-link" href="#main">Aller au contenu</a>
...
<main id="main"> ... </main>

ARIA : moins, c’est mieux

ARIA (Accessible Rich Internet Applications) sert à communiquer aux lecteurs d’écran des états que le HTML seul ne peut exprimer. Mais la règle d’or est claire : pas d’ARIA vaut mieux que du mauvais ARIA. Un role erroné ou un état erroné casse un HTML sémantique pourtant correct.

• Si un élément HTML natif fait le travail, n’ajoutez pas d’ARIA : role="button" sur un <button> est redondant.
• Donnez un nom accessible aux boutons-icônes sans texte : aria-label="Ouvrir le menu".
• Annoncez l’état : aria-expanded="true/false" sur un menu déroulant, aria-selected sur l’onglet actif.
• Annoncez les mises à jour en direct avec aria-live="polite" (un message d’erreur de formulaire, par exemple).

<button aria-label="Ouvrir le menu" aria-expanded="false" aria-controls="menu">
  <svg aria-hidden="true"> ... </svg>
</button>
<ul id="menu" hidden> ... </ul>

Pour les images purement décoratives, laissez alt="" ou utilisez aria-hidden="true" afin que les lecteurs d’écran les ignorent. Pour les images porteuses de sens, un texte alt descriptif est indispensable.

Couleur et contraste : la lisibilité pour tous

Le faible contraste est le problème d’accessibilité le plus courant et le plus facile à corriger. Le niveau AA des WCAG exige un ratio de contraste d’au moins 4,5:1 pour le texte normal et de 3:1 pour le grand texte (18,66px gras ou 24px). Les composants d’interface et les éléments graphiques doivent aussi viser 3:1.

• Les DevTools de votre navigateur affichent le ratio de contraste et le statut AA/AAA quand vous sélectionnez du texte.
• Ne transmettez jamais l’information par la couleur seule. Au lieu de « le champ rouge est invalide », ajoutez une icône, un texte ou un motif — crucial pour les daltoniens.
• Distinguez les liens par un second indice, comme un soulignement ou une graisse, pas seulement par la couleur.
• Réduisez les animations pour les utilisateurs sensibles au mouvement avec prefers-reduced-motion.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Tester : outils et humains ensemble

Les outils automatiques ne détectent qu’une partie des problèmes ; le reste exige une expérience réelle.

• Faites une analyse rapide avec Lighthouse ou axe DevTools.
• Parcourez toute la page au clavier : restez-vous coincé quelque part ?
• Essayez un lecteur d’écran : VoiceOver sur macOS et NVDA sur Windows sont gratuits.
• Zoomez la page à 200 % ; le contenu se réorganise-t-il sans casser ?

Questions fréquentes

Dois-je viser le niveau WCAG AA ou AAA ?

Pour la plupart des projets, le niveau AA est l’objectif pratique et largement accepté, et de nombreux cadres légaux s’y réfèrent. Le niveau AAA est très strict sur certains critères et n’est pas réaliste pour tout contenu, mais il est bon de l’appliquer là où c’est possible.

ARIA peut-il remplacer le HTML sémantique ?

Non. ARIA enrichit seulement le sens là où le HTML est insuffisant ; il n’ajoute aucun comportement. Même si vous donnez un role="button" à un <div>, vous devez quand même gérer vous-même les événements clavier et le focus. Le bon élément est toujours plus sûr.

L’accessibilité aide-t-elle le SEO ?

Oui. Une structure sémantique, des textes alt, une hiérarchie de titres logique et un contenu clairement lisible offrent la même clarté aux lecteurs d’écran et aux moteurs de recherche ; les deux se recoupent largement.

Une interface accessible est tout simplement une meilleure interface. Si vous souhaitez auditer votre site sur le clavier, ARIA et le contraste, ou le construire accessible dès le départ, contactez-moi.