# La genèse d’aria-live en 2010 : le problème concret qu’il devait résoudre > Avant de servir à annoncer un panier mis à jour ou un message de chat, aria-live répondait à un problème très concret posé par la généralisation des mises à jour de page sans rechargement. - Auteur : WordPress Développement - Publié le : 2021-12-04 - Mis à jour le : 2021-12-04 - Catégorie : Accessibilité - URL : https://www.wpmoderne.fr/accessibilite/genese-aria-live-2010-probleme-resoudre/ ## L’essentiel - Le contenu mis à jour sans rechargement de page reste invisible à un lecteur d'écran - Le brouillon WAI-ARIA formalise dès 2010 la notion de région active - Sa mise en Recommandation W3C n'arrivera qu'en 2014 Au milieu des années 2000, la généralisation des interfaces qui mettent à jour une partie de la page sans recharger l'ensemble du document, popularisées sous le nom d'AJAX, crée un problème que personne n'avait vraiment anticipé pour les utilisateurs de lecteurs d'écran. Un lecteur d'écran construit sa restitution vocale à partir d'un arbre de contenu qu'il parcourt de façon séquentielle. Quand une portion de cet arbre change silencieusement, sans que le focus ne se déplace et sans rechargement de page, rien n'indique à l'utilisateur qu'une information nouvelle vient d'apparaître ailleurs sur l'écran. Un exemple concret de l'époque : un webmail qui affiche « nouveau message reçu » dans un coin de l'interface pendant qu'un utilisateur voyant continue de composer un message. Un utilisateur de lecteur d'écran, concentré sur son propre champ de saisie, ne perçoit strictement rien de cette notification, à moins de déplacer manuellement son focus vers cette zone, ce qu'il n'a évidemment aucune raison de faire s'il ignore qu'un changement vient de survenir. ## Le brouillon qui pose les bases Le groupe de travail du W3C chargé des applications riches d'internet accessibles, connu sous le nom de WAI-ARIA, travaille sur cette question dès le milieu des années 2000. Un brouillon de travail publié autour de 2010 formalise la notion de région active, une zone du document que l'on peut marquer explicitement pour que les technologies d'assistance surveillent ses changements et les annoncent, sans que l'utilisateur ait besoin d'y déplacer son focus. L'attribut `aria-live` constitue le cœur de ce mécanisme, avec trois valeurs possibles définissant la politesse de l'annonce : `off` pour ne rien annoncer, `polite` pour attendre une pause dans l'activité de l'utilisateur avant d'annoncer le changement, et `assertive` pour interrompre immédiatement, réservé aux informations réellement urgentes comme une erreur bloquante. > L'essentiel à retenir : Le contenu mis à jour sans rechargement de page reste invisible à un lecteur d'écran ; Le brouillon WAI-ARIA formalise dès 2010 la notion de région active ; Sa mise en Recommandation W3C n'arrivera qu'en 2014 ## Un brouillon, pas encore une norme stabilisée Il est important de resituer ce brouillon de 2010 dans son contexte : la spécification WAI-ARIA n'atteindra le statut de Recommandation officielle du W3C qu'en mars 2014, après plusieurs années d'itérations, de retours d'implémentation des fabricants de navigateurs et de technologies d'assistance, et d'ajustements sur le comportement exact attendu de chaque valeur de politesse. Le mécanisme de base d'`aria-live`, cependant, reste globalement stable entre le brouillon de 2010 et la version finale de 2014 : c'est surtout son support par les navigateurs et les lecteurs d'écran qui progresse pendant cette période, de façon inégale selon les combinaisons de logiciels. Cette maturation progressive explique pourquoi les premières implémentations de développeurs, au tournant des années 2010, se heurtaient à des comportements inconsistants d'un lecteur d'écran à l'autre : la spécification n'était pas encore assez stabilisée, et les moteurs de rendu n'avaient pas tous implémenté la même interprétation du brouillon en cours. ## Le problème que ce mécanisme ne résout pas seul Poser un attribut `aria-live` sur un conteneur ne suffit pas à garantir une annonce : le brouillon précise déjà, dès cette période, que la région doit exister dans le document avant que son contenu ne change, faute de quoi certains lecteurs d'écran ne détectent jamais la mise à jour. Un conteneur créé dynamiquement puis rempli de contenu dans la même opération risque de passer inaperçu, un piège qui perdure aujourd'hui et qui explique une bonne partie des régions live qui ne fonctionnent pas en pratique. ```
``` ## Ce que cette genèse éclaire aujourd'hui Comprendre que `aria-live` a d'abord répondu à un problème d'AJAX, avant l'explosion des applications monopages et des frameworks JavaScript modernes, aide à mesurer la portée réelle de ce mécanisme : il ne s'agit pas d'un outil pensé spécifiquement pour React, Vue ou tout autre framework apparu bien après, mais d'un attribut HTML générique, indépendant de toute technologie, conçu pour combler un manque fondamental de perception des changements dynamiques du DOM. > Un repère utile à transmettre à une équipe de développement : un attribut qui existe depuis un brouillon de 2010 mérite la même rigueur d'implémentation qu'une norme récente. L'ancienneté d'un mécanisme ne garantit ni sa simplicité d'usage, ni l'absence de pièges dans son support par les technologies d'assistance actuelles. ## Notion à retenir `aria-live` n'est pas né d'un besoin esthétique ou d'un confort de développement : il répond à un problème d'accessibilité concret, apparu avec la généralisation des mises à jour de page sans rechargement au milieu des années 2000, formalisé dans un brouillon dès 2010, et stabilisé en norme officielle seulement quatre ans plus tard. Son implémentation pratique actuelle, avec ses subtilités et ses limites, reste un sujet à part entière, qui ne sera pas développé ici.