La balise `<output>`

• La balise <output> est peu connue des développeurs web, mais elle offre nativement l’affichage de résultats dynamiques et l’accessibilité pour les lecteurs d’écran
• Présente depuis longtemps dans la spécification HTML, elle est automatiquement associée à role="status", ce qui permet d’annoncer les changements aux technologies d’assistance pour les personnes malvoyantes
• <output> s’utilise pour signaler un résultat calculé à partir de valeurs d’entrée, mais reste ignorée par la plupart des tutoriels et bibliothèques
• Elle offre une excellente accessibilité, notamment avec la prise en charge de l’attribut for="", et fonctionne très bien avec les frameworks JavaScript
• Dans divers projets concrets, elle peut être très utile pour les calculateurs, le formatage de valeurs de curseur et les retours de validation de formulaire

---

Le joyau caché de HTML : la balise <output>

Tous les développeurs connaissent bien l’élément <input>, qui constitue l’un des principaux moyens de saisie du web.

Mais la plupart n’ont jamais utilisé l’élément <output>, et beaucoup ignorent même son existence.

C’est regrettable, car <output> résout nativement ce que l’on a longtemps bricolé avec des <div> et ARIA pour l’expression de résultats dynamiques et l’accessibilité.

Cette balise existe dans la spécification HTML depuis longtemps, mais elle reste encore peu connue.

Définition dans la spécification HTML5

Selon la spécification HTML5,

l’élément <output> représente le résultat d’un calcul effectué par l’application ou le résultat d’une action de l’utilisateur

Dans l’arbre d’accessibilité, il est associé à role="status" ; chaque fois que sa valeur change, un lecteur d’écran annonce automatiquement l’ensemble de son contenu à l’utilisateur.
C’est comme si aria-live="polite" aria-atomic="true" était appliqué par défaut.

Ce comportement a pour avantage de ne pas interrompre le flux de l’utilisateur, tout en lisant calmement le contenu complet.
Si nécessaire, le développeur peut tout de même définir des attributs ARIA pour modifier ce fonctionnement.

Comment utiliser <output>

On peut l’utiliser très simplement, comme ci-dessous :

<output>여기에 동적 값 표시</output>

Même ainsi, on bénéficie déjà de la prise en charge intégrée des technologies d’assistance, sans attribut supplémentaire ni API difficile à mémoriser, et il est possible d’atteindre l’accessibilité avec du HTML pur.

Le moment de la découverte

L’auteur a découvert la valeur de <output> au cours d’un projet d’accessibilité, en travaillant sur l’affichage du score d’un formulaire à plusieurs étapes.

Les variations du score étaient visibles à l’écran, mais les utilisateurs de lecteurs d’écran ne pouvaient pas percevoir ces changements.
Une région live ARIA permettait de contourner le problème, mais il semblait préférable d’utiliser un HTML sémantiquement explicite.

En examinant la spécification, il a découvert <output>, utilisable indépendamment d’un formulaire et capable d’annoncer automatiquement un résultat, réalisant que la solution la plus simple faisait déjà partie de la spécification.

Pourquoi elle est peu utilisée

C’est une balise oubliée : elle est absente de la plupart des tutoriels et des bibliothèques de composants, et on trouve très peu d’exemples d’usage même dans les dépôts publics GitHub.

Cela entretient un manque de transmission des connaissances et un cercle vicieux de faible adoption.

Points utiles à connaître

• Comme <label>, <output> possède un attribut for=""
  • il permet d’indiquer, en séparant les id par des espaces, de quelles valeurs d’entrée dépend le résultat
• Visuellement, rien ne change, mais dans l’arbre d’accessibilité, le lien sémantique entre entrée et résultat est établi
• Même sans élément <form>, on peut l’utiliser partout où un texte change dynamiquement en fonction d’une saisie utilisateur
• Comme c’est un élément inline par défaut, il faut le styliser comme un <span> ou un <div> selon les besoins de mise en page
• Elle fait partie de la spécification depuis 2008 ; la prise en charge par les navigateurs et les lecteurs d’écran est donc excellente
• Excellente compatibilité avec tous les frameworks JS comme React ou Vue
• En octobre 2025, certains lecteurs d’écran peuvent encore ne pas lire les mises à jour ; dans ce cas, il est recommandé d’ajouter l’attribut role="status"

Important :
<output> convient aux résultats de calcul ou d’action clairement liés à une entrée utilisateur.
Il ne doit pas être utilisé pour des notifications globales (par exemple des messages toast) ; pour le feedback système, il faut plutôt utiliser role="status" ou role="alert".

Exemples d’usage concrets

Application de calculatrice

Lorsqu’on crée une calculatrice simple, afficher le résultat avec <output> permet de faire annoncer automatiquement la valeur sans ajouter de rôle ARIA supplémentaire.

Formatage de valeur de curseur (cas Volvo Cars)

On ajuste avec un curseur une valeur interne (par exemple 10000), puis on l’affiche dans <output> sous une forme plus lisible (10,000 miles/year).
En attribuant role="group" au conteneur ainsi qu’un label partagé, on peut l’exploiter à la fois pour l’accessibilité et pour la composition de composants React.

Retour de validation de formulaire

Des messages de validation en temps réel, comme l’indication de la robustesse d’un mot de passe, peuvent aussi être transmis via <output> pour informer immédiatement les utilisateurs de technologies d’assistance.

Affichage de résultats calculés côté serveur

<output> convient aussi à des valeurs calculées côté serveur, comme des frais de livraison, des taxes ou des recommandations obtenues via une API serveur.

Comme dans l’exemple React ci-dessous, il est possible de récupérer un montant depuis le serveur et de l’afficher immédiatement dans <output>.

La satisfaction d’utiliser un élément natif

En utilisant correctement un élément HTML pur conformément à l’intention de la spécification,
on améliore l’accessibilité, on simplifie le code,
et on redécouvre la valeur et les usages de la balise méconnue <output>.

Cela suggère qu’il reste encore dans HTML de nombreux éléments semblables à des joyaux cachés.

Mise à jour la plus récente : Bob Rudis a publié une page d’exemple fonctionnelle correspondant à cet article

[GN⁺]

Avis Hacker News

• Le problème avec l’élément <output>, c’est qu’il donne l’impression d’être à moitié implémenté, donc en pratique il est presque inutile.
  Je pense qu’il serait bien plus pratique s’il avait un attribut type, comme input.
  J’ai expérimenté output|type dans mon Sciter, et j’y ai ajouté plusieurs types comme suit :

  • type="text" : valeur par défaut, sans formatage
  • type="number" : formatage des nombres selon la locale de l’utilisateur
  • type="currency" : formatage monétaire selon la locale de l’utilisateur
  • type="date" : affichage en date, sans conversion de fuseau horaire
  • type="date-local" : format de date locale, avec conversion d’un datetime UTC en local
  • type="time" : affichage en heure
  • type="time-local" : heure locale, avec une valeur traitée comme un datetime UTC
    De cette façon, le serveur peut transmettre les données même sans connaître la locale de l’utilisateur.

  • Comme dans l’article et la spécification, <output> sert à afficher le résultat d’un calcul dans une application ou d’une action utilisateur.
    La sémantique ARIA est importante ici, et lorsqu’une page est mise à jour, le résultat est lu par les lecteurs d’écran.
    Dans <output>, on peut insérer directement n’importe quelle représentation du type souhaité.
    "text" est la valeur par défaut, et pour les dates ou heures on peut utiliser la balise <time>.
    Il n’existe pas actuellement de balise dédiée uniquement au formatage des nombres, mais depuis l’arrivée d’Intl les demandes sont fréquentes.
    Par exemple :
    <output>The new date is <time datetime="2025-10-11">Oct 11</time></output>
    Autrement dit, <output> n’a pas besoin de gérer tous les types : c’est à l’ensemble du HTML d’exprimer les types.

  • Je suis d’accord avec l’idée que c’est presque inutile à cause de ce caractère inachevé.
    C’est dommage qu’en 2025 il y ait encore autant de cas comme celui-ci.
    Je pense que Safari porte une grande part de responsabilité.
    L’exemple le plus extrême, c’est <input type="date">.
    On dit qu’on peut l’utiliser directement en production, mais à cause des problèmes entre navigateurs, on finit souvent par utiliser davantage un date picker JS, ce qui donne une impression étrange.

  • Personnellement, j’aimerais que <output> puisse se lier directement à <input> pour afficher le résultat.
    Par exemple : <input type="range" id="example_id" name="example_nm" min="0" max="50"> <output name="example_result" for="example_id"></output> J’aimerais qu’il affiche directement la valeur de l’input de cette façon.
    Ce serait bien aussi qu’on puisse ajouter un spécificateur "type", et permettre aussi au contenu de changer via content: dans le CSS ::before ou ::after.
    Je pense qu’une telle capacité de formatage serait utile pour de nombreux types de <input>.
    En particulier, ce serait pratique pour quelque chose comme type="tel", afin d’afficher la valeur d’entrée dans un format plus agréable.
    Cela pourrait s’appliquer à checkbox, color, date, datetime-local, file, month, number, radio, range, tel, time, url, week, etc.
    Même les types textuels pourraient être utiles dans certaines conditions.
    Et j’aimerais aussi que l’attribut for="" puisse jouer des rôles plus variés.
    Actuellement, la plupart des exemples l’utilisent plutôt sous une forme détournée comme <output name="result"><form oninput="result.value=...">.

  • Penser à donner à <output> des types en symétrie avec <input> est une mauvaise approche.
    Un output n’est pas une valeur typée comme une entrée, c’est le concept d’un conteneur dont le contenu change sur la page.

  • Moi, je préfère une forme comme celle-ci : <output for=input> <!-- insertion d’un composant time-locale personnalisé --> <time is=time-locale datetime=2001-02-03>2001-02-03</time> J’aimerais que ce composant modifie la valeur selon la locale.
    Produire un faux contenu en HTML/CSS a tendance à créer beaucoup de problèmes.
    Par exemple, quand on copie quelque chose injecté par CSS ::before/:after, ou avec la différence entre .innerText et le texte réel interne.
    Il faudra sans doute prendre des décisions sur ces points, mais si on entasse trop de fonctionnalités dans une seule balise, elle finit par devenir une sorte de DSL conçue uniquement pour elle-même.
    Le type de valeur (absolue/relative), les données associées (comme le type de devise), tout cela devient une partie du traitement HTML et n’est plus modifiable de manière souple en JS.

• <output> ? Moi non plus je ne l’ai jamais utilisé.
  Je l’ai découvert aujourd’hui pour la première fois et je l’ai ajouté à ma liste TIL (Today I Learned).
  Si une recherche dans les dépôts publics GitHub ne donne presque rien, c’est simplement parce que si personne ne l’enseigne, personne ne l’utilise.
  Et là, je me demande soudain si les LLM utilisent réellement cette balise lorsqu’ils génèrent du code, ou si au contraire elle n’a pratiquement pas été apprise.

  • Moi aussi, je m’inquiète du fait que l’IA ne lise pas les documents de référence (specs).
    Que se passera-t-il si une nouvelle spécification du W3C apparaît et que tout le monde se met à faire du "vibe coding" ?
    Si l’IA ne reflète pas les spécifications récentes et ne fait que répéter d’anciens patterns de code, la diffusion des mises à jour des specs pourrait devenir encore plus difficile qu’aujourd’hui.

  • C’est Claude qui m’a généré du code et m’a fait découvrir la balise <output> pour la première fois.

  • Les LLM ne lisent pas directement les documents standards : ils génèrent du code à partir de motifs statistiques tirés d’un vaste ensemble de projets existants.
    Donc si cette balise est presque absente du code réel, elle apparaîtra elle aussi très rarement dans les sorties générées par les LLM.

• Mise à jour du 7 octobre 2025 : comme certains lecteurs d’écran ne détectent toujours pas les mises à jour de la balise <output>, il peut être préférable pour le moment d’utiliser explicitement un attribut role, par exemple : <output role="status">.
  Je me demande s’il faut simplement continuer à attendre une amélioration du support d’une balise vieille de 17 ans.

  • Sous Windows, si vous ouvrez une issue dans le dépôt NVDA, ils ont plutôt tendance à bien traiter ce genre de problème.
    https://github.com/nvaccess/nvda

  • Malgré ses 17 ans de standardisation, il faut faire un effort pour améliorer le problème des lecteurs d’écran qui ignorent cette balise.
    À mon avis, c’est clairement un problème du côté des lecteurs d’écran.

• J’ai suivi plusieurs cours sur l’accessibilité web front-end, mais je n’avais encore jamais vu la balise <output>.
  Merci pour ce bon partage d’information.

• Comme <label>, <output> a aussi un attribut for="", et je me demande si cela a vraiment du sens pour les utilisateurs de lecteurs d’écran.
  Comme c’est très peu utilisé sur le web actuel, les utilisateurs de lecteurs d’écran n’y sont peut-être pas habitués, mais au final cela dépendra sans doute surtout de l’UX du logiciel.

  • Je n’utilise pas moi-même un lecteur d’écran, mais j’en ai beaucoup manipulé pour des tests.
    Je me demande si cela sera correctement exposé aux technologies d’assistance.
    Je ne suis pas devant mon ordinateur, donc je ne peux pas tester tout de suite.
    Personnellement, je pense qu’il vaut bien mieux étiqueter clairement la valeur de l’output.
    Par exemple : <label for="output">Total</label> <output id="output">£123.45</output> De cette façon, le lecteur d’écran lira "Total, £123.45", ce qui facilite la compréhension du contexte.

• Je considère que le HTML sémantique n’est qu’un piège pour débutants.
  Mieux vaut ne pas trop réfléchir et utiliser une solution qui fonctionne réellement, comme aria-live.
  Ces éléments peuvent être amusants, mais en tant que développeur, notre responsabilité est de construire quelque chose qui fonctionne réellement pour les utilisateurs.
  Il vaut mieux utiliser ce qu’attendent les navigateurs et l’écosystème existant, plutôt que des balises sémantiques rarement employées.

  • Le HTML n’est pas destiné uniquement aux navigateurs.
    Ayant beaucoup travaillé sur des EPUB, je trouve qu’une structure de page sémantique est globalement bien plus simple et meilleure.

• J’ai appris que <output> est une balise destinée à l’accessibilité des pages web, notamment au support des lecteurs d’écran.
  "ARIA" est l’abréviation de Accessible Rich Internet Applications, un ensemble d’attributs HTML qui améliorent l’accessibilité pour les personnes en situation de handicap.

  • C’est un peu comme expliquer ce qu’est JavaScript dans un contexte React.
    Ne pas connaître les bases de l’accessibilité n’a rien de honteux, mais cela ne veut pas dire non plus qu’il faille réagir comme si c’était étrange que le lecteur ne le sache pas.

  • La documentation MDN sur le sujet est très bien faite.
    (L’auteur de l’article insiste d’ailleurs sur la même consigne.)
    "La première règle de l’utilisation d’ARIA est que si un élément ou attribut HTML natif possède déjà la sémantique et le comportement requis, il faut l’utiliser directement au lieu de réaffecter un rôle, un état ou une propriété ARIA pour le faire fonctionner."
    https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

  • Merci pour l’explication.
    En réalité, j’aurais pu chercher sur Google, mais en ce samedi après-midi un peu brumeux, c’était plus confortable de lire ton commentaire.
    Merci encore.

• En voyant seulement le titre de cet article, je pensais que <output> avait été mal utilisé, mais après lecture, j’ai été franchement surpris.
  (Surtout qu’en voyant tout en haut cette image douteuse de calculatrice GenAI, je m’attendais à un échec encore plus grossier, mais le contenu était finalement si bon que ce n’est qu’après avoir tout lu que j’ai repensé à cette image.)

  • Cette image douteuse de calculatrice GenAI est vraiment hilarante.
    Elle sait faire l’addition, la multiplication et la division, mais pas la soustraction.

  • À propos de cette image douteuse de calculatrice GenAI :
    j’ai l’impression qu’avant l’IA, nous oublions les images encore plus bancales que nous, humains, produisions.
    Grâce à l’IA, on peut désormais générer instantanément des images au moins suffisamment correctes pour ne pas être embarrassantes.
    Dans ce cas précis, je trouve (subjectivement) qu’elle dégage bien une ambiance rétro vintage informatique, ce qui lui donne un certain intérêt.
    Je ne pense pas que tous les usages de l’IA remplacent forcément le travail d’un artiste professionnel.

• J’aime bien tomber sur ce genre de contenu.
  Une autre astuce consiste à nommer les formulaires en les alignant sur la structure de données du back-end, ce qui réduit le besoin de récupérer les valeurs en JS ou de reconstruire les données.
  Par exemple : <input name=“entity[id]”> <input name=“entity[relation]”> Ainsi, il suffit d’envoyer le formulaire sans avoir à fabriquer séparément les données en JS pour obtenir directement la structure voulue.