Dix conseils pour un clavier heureux.

L'accessibilité clavier est le socle sur lequel reposent toutes les autres technologies d'assistance. Un lecteur d'écran, une commande vocale, un switch-control — tous émulent au final des interactions clavier. Si le clavier fonctionne, l'essentiel est sauvé. S'il ne fonctionne pas, rien ne fonctionne. Voici les dix règles que nous vérifions systématiquement en audit, présentées dans un ordre d'impact décroissant.

№ 01Atteignable au clavier.

Un problème bloquant en accessibilité survient lorsque des éléments interactifs ne sont pas accessibles au clavier. Ces obstacles peuvent empêcher les utilisateurs d'accéder à des fonctionnalités et des informations importantes du site.

Une balise <span> utilisée comme un bouton fonctionne à la souris mais ne peut pas fonctionner au clavier en l'état :

<span onclick="alert('Action!');">Action</span>

<a href="/cible">Lien</a>

<button type="button">Bouton HTML</button>

<div role="link" tabindex="0">Lien ARIA</div>

№ 02Visibilité du focus.

La visibilité du focus est indispensable. Un élément focusable qui n'est pas clairement visible peut semer la confusion — l'utilisateur clavier ne sait plus où il se trouve dans la page.

Rendez chaque élément recevant le focus parfaitement visible — soit avec l'outline natif du navigateur, soit avec un style CSS personnalisé respectant un contraste de 3:1 minimum.

:focus {
  outline: 2px solid #000;
  /* bordure noire, 2px, à la prise de focus */
}

Ne jamais écrire outline: none; sans remplacement. Ce motif est la première cause de sites inutilisables au clavier.

№ 03Ordre de tabulation.

Un ordre de tabulation désordonné désoriente les utilisateurs clavier. L'attribut tabindex avec des valeurs positives (tabindex="2", "3"…) perturbe l'ordre naturel de lecture du DOM et doit être proscrit.

L'ordre de tabulation doit suivre la logique visuelle et structurelle de la page. Règle simple : si l'ordre DOM correspond à l'ordre de lecture, tabindex devient superflu.

№ 04Pas de piège clavier.

Un piège au clavier se produit lorsqu'un utilisateur ne peut pas sortir d'un élément interactif avec Tab. Tous les éléments focusables doivent être atteignables et quittables au clavier.

№ 05Rôle de l'élément.

Chaque élément interactif doit être identifiable par son rôle : lien, bouton, case à cocher, onglet… Cela conditionne ce que le lecteur d'écran annonce et ce que l'utilisateur attend comme comportement.

№ 06Nom accessible.

Un bouton sans intitulé ou un champ sans étiquette est un problème bloquant. Chaque élément focusable doit avoir un nom accessible, explicite hors contexte.

Bouton explicite

Un bouton doit être compréhensible par lui-même. Une répétition « En savoir plus » peut être acceptable visuellement, mais le lecteur d'écran lira dix fois la même chose :

<button type="button"
        title="En savoir plus sur l'offre Premium">
  En savoir plus
</button>

Champ de formulaire

Chaque champ doit avoir une étiquette liée via for et id :

<label for="nom">Nom</label>
<input type="text" id="nom" name="nom">

placeholder n'est pas un remplacement du <label> — il disparaît à la saisie.

№ 07État de l'élément.

Communiquez si un élément est plié ou déplié, sélectionné, activé. Les technologies d'assistance ont besoin de cette information pour contextualiser la page.

<button aria-expanded="false">Voir plus</button>
<div hidden>Contenu...</div>

<button aria-pressed="true">J'aime</button>

<div role="checkbox"
     aria-checked="true"
     tabindex="0">Option</div>

№ 08Changement de contexte.

Un changement de contexte — rechargement de page à la sélection d'une option dans un <select>, ouverture d'une nouvelle fenêtre, validation automatique — ne doit jamais surprendre l'utilisateur. Prévenez, ou demandez confirmation.

<select onchange="submit()">
  <option>Français</option>
  <option>English</option>
</select>

<select id="lang">...</select>
<button type="submit">Changer de langue</button>

№ 09Focus après une action.

Une fois une action effectuée — ouverture de modale, application d'un filtre, suppression d'un élément — le focus doit être géré logiquement. Deux stratégies selon le cas :

• Déplacer le focus — quand l'action ouvre un nouveau contexte (modale, panneau), on amène le focus dedans.
• Vocaliser le changement — quand l'action met à jour la page sans changer de contexte (résultats de filtre), on garde le focus et on annonce via aria-live="polite".

<div aria-live="polite" aria-atomic="true">
  <!-- "24 résultats trouvés" -->
</div>

№ 10Pages réactives (SPA).

Sur les applications modernes (React, Vue, Angular) où la page ne recharge pas vraiment, la navigation entre routes est un angle mort de l'accessibilité clavier. Gérez le focus manuellement lors du changement de « vue » pour simuler un rechargement — le geste attendu est de placer le focus sur le <h1> de la nouvelle page.

// À chaque changement de route
router.afterEach(() => {
  const h1 = document.querySelector('h1');
  h1.setAttribute('tabindex', '-1');
  h1.focus();
  // Annoncer le changement de page
  document.title = newPageTitle;
});

Complétez avec une zone aria-live qui annonce « Navigation vers [titre] » pour les utilisateurs de lecteurs d'écran.

Conclusion.

Adopter ces dix règles dès le développement simplifie grandement l'audit final et garantit une expérience robuste pour tous les utilisateurs. La majorité des non-conformités que nous relevons en audit tombent dans l'une de ces dix catégories — les traiter en amont épargne des semaines de correction post-livraison.

Pour aller plus loin, consultez nos formations développeurs ou notre offre d'accompagnement technique.