zonePanier.setAttribute('aria-busy', 'true');
zonePanier.innerHTML = '';
// requête réseau en cours...
zonePanier.innerHTML = nouveauContenuHTML;
zonePanier.setAttribute('aria-busy', 'false');Ce fragment illustre le problème que résout l’attribut aria-busy : entre le vidage du contenu et son remplacement, une région dotée de aria-live peut déclencher deux annonces successives auprès d’un lecteur d’écran, la première portant sur un contenu vide ou incomplet, la seconde sur le résultat final. L’utilisateur entend alors un silence suivi d’une reprise, ou pire, une lecture partielle du contenu intermédiaire qui n’a aucun sens isolé.
Ce que fait réellement aria-busy
La valeur aria-busy="true" indique aux technologies d’assistance qu’une région est en cours de modification et que les changements qui s’y produisent ne doivent pas être annoncés tant que cette valeur reste active. Une fois la mise à jour terminée et l’attribut repassé à false, l’état final de la région redevient éligible à une annonce normale via la région live qui l’englobe.
Sur un bloc de filtre de catalogue qui recharge une liste de produits via une requête Ajax, la séquence correcte combine les deux attributs sur le même conteneur :
<div id="liste-produits" aria-live="polite" aria-busy="false">
<!-- produits affichés -->
</div>
<script>
async function rechargerListe(filtres) {
const zone = document.getElementById('liste-produits');
zone.setAttribute('aria-busy', 'true');
const reponse = await fetch('/api/produits?' + filtres);
const html = await reponse.text();
zone.innerHTML = html;
zone.setAttribute('aria-busy', 'false');
}
</script>Le passage à aria-busy="true" avant même de lancer la requête réseau garantit qu’aucune annonce intermédiaire ne se déclenche pendant le vidage éventuel de l’ancien contenu, qui se produit parfois avant que le nouveau contenu ne soit disponible.
Le piège d’un aria-busy jamais remis à false
Une erreur fréquente consiste à positionner l’attribut à true au démarrage d’un chargement, sans prévoir de chemin de remise à false en cas d’échec de la requête. Si le réseau échoue ou si le serveur renvoie une erreur, la région reste marquée comme occupée indéfiniment, et plus aucune mise à jour ultérieure ne sera annoncée tant que la page n’est pas rechargée entièrement :
async function rechargerListe(filtres) {
const zone = document.getElementById('liste-produits');
zone.setAttribute('aria-busy', 'true');
try {
const reponse = await fetch('/api/produits?' + filtres);
if (!reponse.ok) {
throw new Error('Réponse serveur invalide');
}
zone.innerHTML = await reponse.text();
} catch (erreur) {
zone.innerHTML = '<p>Impossible de charger les produits, veuillez réessayer.</p>';
} finally {
zone.setAttribute('aria-busy', 'false');
}
}Le bloc finally garantit que l’attribut repasse systématiquement à false, que la requête ait réussi ou échoué, ce qui évite de figer silencieusement la région dans un état inaccessible.
aria-busy en dehors d’une région live
L’attribut n’est pas réservé aux régions live : il peut aussi être posé sur n’importe quelle partie de l’interface pour signaler visuellement, via un sélecteur CSS, qu’une zone est en cours de traitement, indépendamment de toute annonce vocale :
[aria-busy="true"] {
opacity: 0.5;
pointer-events: none;
}Cette utilisation croisée entre CSS et ARIA permet de synchroniser l’état visuel de désactivation temporaire avec l’état exposé aux technologies d’assistance, plutôt que de gérer deux mécanismes séparés qui risquent de se désynchroniser au fil des évolutions du code.
Un contenu qui change ne mérite pas toujours d’être annoncé tout de suite : parfois, le plus utile est de dire d’abord qu’il est en train de changer, puis seulement ce qu’il est devenu.
Ce que cet attribut ne remplace pas
aria-busy ne dispense pas d’afficher un indicateur visuel de chargement pour les utilisateurs qui voient l’écran : il agit uniquement sur la couche d’accessibilité exposée aux technologies d’assistance, pas sur le rendu visuel. Un indicateur visuel de chargement, comme une roue qui tourne ou un texte « chargement en cours », reste nécessaire en parallèle pour les personnes qui perçoivent visuellement l’interface mais ne bénéficient d’aucune indication sans lui.
- Positionner aria-busy à true avant de lancer la requête, jamais après.
- Prévoir un chemin de remise à false qui couvre aussi le cas d’échec réseau.
- Combiner l’attribut avec une région live plutôt que de l’utiliser isolément si une annonce finale est attendue.
- Ajouter un indicateur visuel distinct, car aria-busy seul reste invisible à l’écran.
Bien réglé, cet attribut évite les annonces fragmentées ou prématurées qui rendent un bloc dynamique confus à l’écoute, sans demander de refonte lourde du code existant : quelques lignes suffisent généralement à corriger un chargement Ajax mal signalé.
