Accessibilité des interactions : clavier, focus et ARIA

Une interaction JavaScript est accessible quand tout le monde peut l'utiliser : au clavier seul, avec un lecteur d'écran qui lit la page à voix haute, avec une loupe ou une commande vocale. Le JavaScript est souvent ce qui casse l'accessibilité d'une page bien écrite en HTML : un div cliquable qu'on n'atteint pas au clavier, un message d'erreur qui apparaît sans être annoncé, un focus perdu après un rafraîchissement. Ce chapitre donne les règles qui évitent ces problèmes : choisir le bon élément, gérer le clavier et le focus, annoncer les changements, et utiliser les attributs ARIA de base. Le cadre légal (RGAA, WCAG, European Accessibility Act) et les vérifications d'une page statique sont dans le chapitre Accessibilité web du cours HTML et CSS.

Le bon élément HTML d'abord

La règle la plus efficace : utilise l'élément HTML natif qui fait déjà ce que tu veux. Un <button> reçoit le focus avec Tab, se déclenche avec Entrée et Espace, est annoncé « bouton » par les lecteurs d'écran, et se désactive avec disabled. Un <div> avec un écouteur de clic n'a rien de tout cela.

<!-- Inaccessible : pas de focus clavier, pas de rôle, pas d'activation au clavier -->
<div class="btn" id="ajouter">Ajouter</div>

<!-- Accessible sans une ligne de code en plus -->
<button type="button" id="ajouter">Ajouter</button>

Le type button compte : dans un formulaire, un <button> sans type est un bouton d'envoi, et chaque clic envoie le formulaire.

Utilisable au clavier

Beaucoup de personnes naviguent sans souris : handicap moteur, lecteur d'écran, ou simple préférence. La touche Tab passe d'un élément interactif au suivant, Maj + Tab revient en arrière, Entrée et Espace activent.

• Tout ce qui se clique doit être atteignable et activable au clavier. Avec les éléments natifs, c'est automatique.
• L'ordre du focus suit l'ordre du HTML. Ne réorganise pas visuellement la page en CSS au point que Tab saute d'un bout à l'autre de l'écran.
• Le focus doit rester visible. Ne supprime jamais le contour de focus (outline: none) sans le remplacer par un style au moins aussi visible ; préfère :focus-visible, qui ne s'affiche que pour la navigation au clavier.
• tabindex : tabindex="0" rend focalisable un élément qui ne l'est pas (rarement nécessaire si tu utilises les bons éléments), tabindex="-1" le rend focalisable par le code seulement (element.focus()), sans l'ajouter au parcours Tab. N'utilise jamais de valeur positive : elle bouleverse l'ordre de toute la page.
• Pas de piège : l'utilisateur doit toujours pouvoir sortir d'une zone au clavier.

Les raccourcis clavier se gèrent avec l'événement keydown et la propriété event.key. Par exemple, Échap vide la recherche de Gestock :

champRecherche.addEventListener('keydown', (event) => {
  if (event.key === 'Escape') {
    champRecherche.value = '';
    etat.recherche = '';
    rafraichir();
  }
});

Un <input type="search"> le fait d'ailleurs déjà dans la plupart des navigateurs : encore un comportement natif offert.

Gérer le focus après une action

Le focus est l'élément qui reçoit les frappes du clavier. Quand ton script retire ou remplace cet élément, le focus retombe au début de la page : l'utilisateur au clavier doit tout reparcourir, et le lecteur d'écran ne sait plus où il en est.

C'est exactement ce qui arrive dans Gestock : un clic sur le bouton + d'une ligne reconstruit tout le tableau avec replaceChildren, donc le bouton cliqué disparaît et le nouveau bouton n'a pas le focus. La correction tient en une ligne, après le rafraîchissement : retrouver le bouton équivalent dans le nouveau tableau, grâce à ses attributs data-*, et lui rendre le focus.

tbody.addEventListener('click', (event) => {
  const b = event.target.closest('button[data-action]');
  if (!b) return;
  const { action, ref } = b.dataset;
  modifierStock(ajusterQuantite(etat.pieces, ref, action === 'ajouter' ? 1 : -1));
  // Le tableau a été reconstruit : on rend le focus au même bouton.
  tbody.querySelector(`button[data-ref="${ref}"][data-action="${action}"]`)?.focus();
});

Vérifié dans le navigateur : après un clic sur + de RAM-16, document.activeElement est bien le nouveau bouton + de RAM-16, et Entrée peut être pressée plusieurs fois de suite pour ajouter plusieurs unités.

Les autres situations où ton code doit déplacer le focus :

L'élément <dialog> gère pour toi l'essentiel d'une fenêtre modale : showModal() place le focus dans la boîte, rend le reste de la page inerte, et Échap la ferme.

<dialog id="confirmation" aria-labelledby="titre-confirmation">
  <h2 id="titre-confirmation">Supprimer la pièce ?</h2>
  <form method="dialog">
    <button value="annuler">Annuler</button>
    <button value="supprimer">Supprimer</button>
  </form>
</dialog>

const dialogue = document.querySelector('#confirmation');
dialogue.showModal();
dialogue.addEventListener('close', () => {
  if (dialogue.returnValue === 'supprimer') {
    // supprimer la pièce
  }
}, { once: true });

Un <form method="dialog"> ferme la boîte quand on clique sur l'un de ses boutons, et returnValue contient la value du bouton choisi.

Annoncer les changements : aria-live

Quand ton script modifie la page sans que le focus bouge (un résumé qui change, un message « Pièce ajoutée »), une personne aveugle ne s'en aperçoit pas : son lecteur d'écran lit l'endroit où se trouve le focus, pas le reste. Une région live demande au lecteur d'écran d'annoncer ce qui change dans un élément.

<p id="resume" aria-live="polite"></p>
<p id="message" role="status"></p>

Deux conditions pour que ça marche : la région doit exister dans la page dès le chargement (vide), et c'est son contenu qui doit changer, par textContent. Une région ajoutée au DOM en même temps que son texte n'est souvent pas annoncée.

Dans Gestock, #resume annonce « 5 références, 2 en alerte, valeur du stock : 970,80 € » après chaque modification du stock, et #message annonce « Pièce VEN-12 ajoutée. » ou « Le formulaire contient des erreurs. ». N'en abuse pas : une région qui change à chaque frappe (un résultat de recherche mis à jour pendant la saisie) devient vite insupportable. Pour la recherche, une annonce du nombre de résultats après une courte pause suffit.

Les attributs ARIA de base

ARIA (Accessible Rich Internet Applications) est un ensemble d'attributs qui décrivent aux technologies d'assistance ce que le HTML ne dit pas. Ils ne changent rien au comportement : role="button" sur un div ne le rend ni focalisable ni activable au clavier. Ceux que tu utiliseras dans une application de gestion :

Sans aria-label, un lecteur d'écran lirait les boutons de Gestock « bouton moins, bouton plus », dix fois de suite sans dire de quelle pièce il s'agit. C'est pourquoi vue.js les nomme ainsi :

b.setAttribute('aria-label', `${action === 'retirer' ? 'Retirer' : 'Ajouter'} une unité : ${piece.nom}`);

Un bouton qui ouvre et ferme un panneau doit dire son état :

<button type="button" id="bouton-filtres" aria-expanded="false" aria-controls="filtres">Filtres</button>
<div id="filtres" hidden>…</div>

const boutonFiltres = document.querySelector('#bouton-filtres');
const panneau = document.querySelector('#filtres');

boutonFiltres.addEventListener('click', () => {
  const ouvert = boutonFiltres.getAttribute('aria-expanded') === 'true';
  boutonFiltres.setAttribute('aria-expanded', String(!ouvert));
  panneau.hidden = ouvert;
});

Les attributs ARIA sont des chaînes : écris 'true' et 'false', d'où le String(…). Et l'attribut hidden masque le panneau pour tout le monde, lecteurs d'écran compris.

Tester l'accessibilité de tes interactions

1. Débranche la souris (ou ne la touche plus) et utilise toute l'application au clavier : peux-tu tout faire ? Vois-tu toujours où est le focus ? Ne te retrouves-tu jamais au début de la page sans raison ?
2. Lance un audit automatique : l'onglet Lighthouse de Chrome (catégorie Accessibilité) ou l'extension axe DevTools. Ils trouvent les boutons sans nom, les contrastes insuffisants, les champs sans étiquette, mais pas les problèmes de logique (focus perdu, annonce manquante).
3. Écoute ta page avec un lecteur d'écran : NVDA (gratuit, Windows), VoiceOver (intégré à macOS et iOS, Cmd + F5), TalkBack sur Android. Ajoute une pièce et écoute ce qui est annoncé.
4. Agrandis le texte à 200 % : rien ne doit se chevaucher ni disparaître.

L'onglet Éléments de Chrome a un volet Accessibilité qui montre, pour l'élément sélectionné, son nom et son rôle accessibles : le moyen le plus rapide de vérifier qu'un aria-label est bien pris en compte.

Exercices

<div class="onglet" onclick="afficherOnglet('alertes')">
  <img src="cloche.svg"> Alertes
</div>

<button type="button" class="onglet" id="onglet-alertes" aria-pressed="false">
  <img src="cloche.svg" alt=""> Alertes
</button>

const onglet = document.querySelector('#onglet-alertes');
onglet.addEventListener('click', () => {
  afficherOnglet('alertes');
  onglet.setAttribute('aria-pressed', 'true');
});

<p id="nb-resultats" role="status"></p>

const zoneResultats = document.querySelector('#nb-resultats');
let minuterie;

champRecherche.addEventListener('input', () => {
  etat.recherche = champRecherche.value;
  rafraichir();
  clearTimeout(minuterie);
  minuterie = setTimeout(() => {
    const n = filtrerPieces(etat.pieces, etat.recherche, etat.alertesSeules).length;
    zoneResultats.textContent =
      n === 0 ? 'Aucune pièce trouvée' : `${n} pièce${n > 1 ? 's' : ''} trouvée${n > 1 ? 's' : ''}`;
  }, 500);
});

<th scope="col" aria-sort="none">
  <button type="button" id="trier-prix">Prix unitaire</button>
</th>

const boutonTri = document.querySelector('#trier-prix');
const enTete = boutonTri.closest('th');

boutonTri.addEventListener('click', () => {
  const croissant = enTete.getAttribute('aria-sort') !== 'ascending';
  enTete.setAttribute('aria-sort', croissant ? 'ascending' : 'descending');
  const tries = etat.pieces.toSorted((a, b) => (croissant ? a.prix - b.prix : b.prix - a.prix));
  afficherPieces(tbody, tries);
});