La etiqueta `<output>`
(denodell.com)- La etiqueta
<output>es poco conocida entre desarrolladores web, pero ofrece de forma nativa visualización de resultados dinámicos y accesibilidad para lectores de pantalla - Existe desde hace mucho en la especificación de HTML y se asigna automáticamente a
role="status", por lo que anuncia los cambios a las tecnologías de asistencia para personas con discapacidad visual <output>se usa para informar resultados calculados a partir de valores de entrada, pero la mayoría de los tutoriales y bibliotecas la pasan por alto- Ofrece una accesibilidad excelente, incluido el soporte para el atributo
for="", y además es muy compatible con frameworks de JavaScript - En distintos proyectos reales puede aprovecharse de forma útil en calculadoras, formato de valores de sliders y retroalimentación de validación de formularios
La joya escondida de HTML: la etiqueta <output>
Todos los desarrolladores conocen bien el elemento <input>, que es un medio fundamental de entrada en la web.
Pero la mayoría nunca ha usado el elemento <output>, y en muchos casos ni siquiera saben que existe.
Es una lástima, porque <output> resuelve de forma nativa la representación de resultados dinámicos y la accesibilidad para las que durante tanto tiempo se han usado soluciones improvisadas con <div> y ARIA.
Esta etiqueta existe desde hace mucho en la especificación de HTML, pero sigue sin ser ampliamente conocida.
Definición en la especificación HTML5
Según la especificación HTML5,
El elemento
<output>representa el resultado de un cálculo realizado por una aplicación o el resultado de una acción del usuario.
En el árbol de accesibilidad se mapea a role="status", por lo que cada vez que cambia su valor, el lector de pantalla anuncia automáticamente todo su contenido al usuario.
Esto equivale a tener aplicado por defecto aria-live="polite" aria-atomic="true".
Este comportamiento tiene la característica de leer el contenido completo de forma pausada, sin interrumpir el flujo del usuario.
Si hace falta, el desarrollador puede cambiar ese comportamiento asignando atributos ARIA por separado.
Cómo usar <output>
Se puede usar de forma tan simple como esto:
<output>여기에 동적 값 표시</output>
Solo con esto ya se obtiene soporte integrado para tecnologías de asistencia, sin necesidad de atributos adicionales ni de APIs difíciles de memorizar, y es posible lograr accesibilidad con HTML puro.
El momento del descubrimiento
El autor descubrió el valor de <output> durante un proyecto de accesibilidad, mientras trabajaba en la visualización de puntajes en un formulario de varios pasos.
Los cambios en la puntuación se veían en pantalla, pero los usuarios de lectores de pantalla no podían enterarse de ellos.
Se podía resolver con una región ARIA live, pero parecía más adecuado usar HTML con un significado más claro.
Mientras revisaba la especificación, encontró <output>, que puede usarse aparte de un formulario y además anuncia automáticamente los resultados, y se dio cuenta de que la solución más simple ya estaba incluida en la especificación.
Por qué casi no se usa
Es una etiqueta olvidada: la mayoría de los tutoriales o bibliotecas de componentes no la cubren, y casi no hay ejemplos de uso ni siquiera en repositorios públicos de GitHub.
Eso hace que la falta de conocimiento se siga repitiendo y que continúe el círculo vicioso de su escaso uso.
Puntos útiles que conviene saber
<output>también tiene el atributofor="", igual que<label>- Permite indicar, separando con espacios los
idcorrespondientes, de qué valores de entrada depende el resultado
- Permite indicar, separando con espacios los
- Aunque visualmente no cambia nada, en el árbol de accesibilidad conecta semánticamente la entrada con el resultado
- Puede usarse en cualquier lugar donde haya texto que cambie dinámicamente según la entrada del usuario, incluso sin un elemento
<form> - Por defecto es un elemento inline, así que según el objetivo del layout puede necesitar estilos como si fuera un
<span>o un<div> - Está incluido en la especificación desde 2008, por lo que el soporte en navegadores y lectores de pantalla es muy bueno
- Tiene excelente compatibilidad con todos los frameworks de JS, como React y Vue
- A octubre de 2025, algunos lectores de pantalla todavía no leen las actualizaciones en ciertos casos, así que en esas situaciones se recomienda agregar el atributo
role="status"
Importante:
<output> es adecuado para resultados de cálculo o resultados de acciones claramente vinculados con la entrada del usuario.
No debe usarse para notificaciones globales (por ejemplo, mensajes toast); para retroalimentación del sistema se debe usar role="status" o role="alert".
Ejemplos de uso real
Aplicación de calculadora
Al crear una calculadora simple, mostrar el resultado con <output> tiene la ventaja de que el valor resultante se anuncia automáticamente sin necesidad de roles ARIA adicionales.
Formato del valor de un slider (caso de Volvo Cars)
Se ajusta con un slider un valor interno (por ejemplo, 10000) y se muestra en <output> en un formato más fácil de leer (10,000 miles/year).
Al contenedor se le puede dar role="group" y una etiqueta compartida, lo que ayuda tanto a la accesibilidad como a la composición de componentes en React.
Retroalimentación de validación de formularios
Los mensajes de validación en tiempo real, como la fortaleza de una contraseña, también pueden comunicarse de inmediato a los usuarios de tecnologías de asistencia mediante <output>.
Mostrar resultados de cálculos del servidor
<output> también es adecuado para valores calculados en el servidor, como costos de envío, impuestos o valores recomendados obtenidos por una API del servidor.
Como en el ejemplo de React de abajo, se puede recibir un monto desde el servidor y mostrarlo de inmediato en <output>.
La satisfacción de usar elementos nativos
Al usar correctamente un elemento HTML puro tal como fue pensado en la especificación,
se mejora la accesibilidad y se simplifica el código,
y se redescubren el valor y las formas de uso de la poco conocida etiqueta <output>.
También sugiere que todavía hay muchos elementos dentro de HTML que son como joyas escondidas.
Actualización más reciente: Bob Rudis publicó una página de ejemplo funcional acorde con este artículo
1 comentarios
Opiniones en Hacker News
El problema con el elemento
<output>es que su funcionalidad está implementada a medias, así que en la práctica se siente casi inútilCreo que sería mucho más práctico si tuviera un atributo
typecomoinputProbé
output|typeen mi Sciter y añadí varios tipos así:type="text": valor predeterminado, sin formatotype="number": formato numérico según la configuración regional del usuariotype="currency": formato de moneda según la configuración regional del usuariotype="date": se muestra como fecha, sin conversión de zona horariatype="date-local": formato de fecha local, conviertedatetimeUTC a localtype="time": se muestra como horatype="time-local": hora local, el valor se procesa comodatetimeUTCDe esta manera, el servidor podría enviar los datos sin conocer la configuración regional del usuario
Como en el artículo y la especificación,
<output>sirve para mostrar el resultado de cálculos en una app o el resultado de acciones del usuarioLa semántica ARIA es la parte importante, y cuando la página se actualiza, un lector de pantalla lee el resultado
Dentro de
<output>puedes poner directamente la representación del tipo que quieras"text"es el valor predeterminado, y para fechas u horas se puede usar la etiqueta<time>Actualmente no hay una etiqueta dedicada solo al formateo de números, pero desde la introducción de
Intlla piden mucho másPor ejemplo:
<output>The new date is <time datetime="2025-10-11">Oct 11</time></output>Es decir,
<output>no necesita manejar todos los tipos; todo HTML debería expresar los tiposCoincido con eso de que por ser una función a medias resulta casi inútil
Incluso en 2025 sigue habiendo demasiados casos así, lo cual da pena
Creo que Safari tiene buena parte de la culpa
El ejemplo más extremo es
<input type="date">Se supone que ya se puede usar tal cual en producción, pero por los problemas entre navegadores terminamos usando más un date picker en JS, y se siente raro
Mi deseo personal es que
<output>pudiera conectarse directamente a<input>para mostrar el resultadoPor ejemplo:
<input type="range" id="example_id" name="example_nm" min="0" max="50"><output name="example_result" for="example_id"></output>Me gustaría que algo así mostrara directamente el valor delinputTambién estaría bien que se añadiera un especificador
"type", y que el contenido pudiera cambiarse concontent:en CSS::beforeo::afterCreo que una función de formateo así sería útil para varios tipos de
<input>En especial sería cómodo para casos como
type="tel", donde se podría mostrar el valor de entrada con un formato más bonitoSe podría usar también con
'checkbox, color, date, datetime-local, file, month, number, radio, range, tel, time, url, week'Incluso los tipos de texto podrían ser útiles en ciertas condiciones
Y también me gustaría que el atributo
for=""tuviera funciones más variadasAhora la mayoría de los ejemplos terminan usándolo transformado, como
<output name="result"><form oninput="result.value=...">Pensar que
<output>debería tener tipos de forma simétrica a<input>es un enfoque equivocadooutputno es algo con tipo como un valor de entrada, sino un contenedor cuyo contenido cambia dentro de la páginaYo prefiero una forma como esta
<output for=input><!-- aquí va un componente personalizado time-locale --><time is=time-locale datetime=2001-02-03>2001-02-03</time>Me gustaría que este componente cambiara el valor según la configuración regionalGenerar contenido falso con HTML/CSS tiende a causar varios problemas
Por ejemplo, al copiar algo inyectado con CSS
::before/:after, o por las diferencias entre.innerTexty el texto interno realHabrá que tomar decisiones sobre esas cosas, pero si se mete demasiada funcionalidad en una sola etiqueta, al final termina pareciendo un DSL hecho solo para esa etiqueta
El tipo de valor (absoluto/relativo), los datos acompañantes (tipo de moneda, etc.) y parte del procesamiento HTML terminan quedando fijados, y ya no se pueden modificar con flexibilidad desde JS
¿
<output>? Yo tampoco lo había usado nuncaHoy me enteré de su existencia por primera vez y lo agregué a mi lista de TIL (hoy aprendí)
Incluso buscando en repos públicos de GitHub casi no aparece; la razón parece ser que, si nadie lo enseña, nadie lo usa
Y eso me hizo pensar si los LLM realmente usan esta etiqueta al generar código, o si de plano ni siquiera la tienen aprendida
A mí también me preocupa que la IA no lea la documentación (spec)
¿Qué pasa si aparece una nueva especificación del W3C y la mayoría se pone a hacer "vibe coding"?
Si la IA no refleja las especificaciones más recientes y solo repite patrones de código viejos, difundir las actualizaciones del spec podría volverse aún más difícil de lo que ya es ahora
Yo descubrí la etiqueta
<output>por primera vez porque Claude me generó código con ellaLos LLM no leen directamente los documentos de los estándares, sino que generan código a partir de patrones estadísticos en una enorme cantidad de datos obtenidos de proyectos existentes
Si en el código real esta etiqueta casi no se usa, entonces casi no aparecerá tampoco en la salida de código de los LLM
Actualización del 7 de octubre de 2025: algunos lectores de pantalla todavía no reconocen las actualizaciones de la etiqueta
<output>, así que por un tiempo podría ser mejor usar explícitamente el atributorole:<output role="status">Me pregunto si solo nos toca seguir esperando a que mejore el soporte de una etiqueta que ya tiene 17 años
En Windows, si abres un issue en el repositorio de NVDA, suelen atenderlo bastante bien
https://github.com/nvaccess/nvda
A pesar de ser un estándar de 17 años, hace falta esfuerzo para mejorar el problema de que los lectores de pantalla ignoren esta etiqueta
Creo que claramente es un problema del lado de los lectores de pantalla
He tomado varios cursos de accesibilidad web frontend, pero nunca había visto la etiqueta
<output>ni una sola vezGracias por compartir esta buena información
<output>también tiene un atributofor=""como<label>, pero me pregunto si eso realmente tendrá algún significado para quienes usan lectores de pantallaComo casi no se usa en la web actual, puede que incluso los usuarios de lectores de pantalla no estén familiarizados con ello, aunque al final supongo que depende del UX del software
Tengo dudas de si esto se expone correctamente a la tecnología asistiva
No estoy frente a la computadora, así que no puedo probarlo ahora mismo
Personalmente creo que es mucho mejor etiquetar con claridad el valor de
outputPor ejemplo:
<label for="output">Total</label><output id="output">£123.45</output>Así un lector de pantalla diría "Total, £123.45", y sería más fácil entender el contextoCreo que el HTML semántico no es más que una trampa para principiantes
Mejor no darle tantas vueltas y usar soluciones que sí funcionan en la práctica, como
aria-liveUno puede divertirse con este tipo de elementos, pero como desarrolladores nuestra responsabilidad es construir estructuras que realmente funcionen para los usuarios
En vez de usar etiquetas semánticas poco utilizadas, lo correcto es usar lo que esperan los navegadores y el ecosistema existente
Desde mi experiencia trabajando mucho con EPUB, una composición semántica de la página hace que todo sea mucho más fácil y mejor en general
Me enteré de que
<output>es una etiqueta para la accesibilidad en páginas web, especialmente para soporte de lectores de pantalla"ARIA" es la abreviatura de Accessible Rich Internet Applications, y es un conjunto de atributos HTML que mejoran la accesibilidad para personas con discapacidad
Se siente como explicar qué es JavaScript debajo de React
No es vergonzoso no conocer lo básico de accesibilidad, pero tampoco creo que haga falta reaccionar como si fuera raro que un lector no lo supiera
En MDN está bien organizada la documentación relacionada
(El autor del artículo también enfatiza la misma guía)
"La primera regla del uso de ARIA es que, si ya existe un elemento o atributo HTML nativo con la semántica y el comportamiento que necesitas, no reinventes la rueda agregando un role, state o property de ARIA para reutilizarlo; usa directamente eso."
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA
Gracias por la explicación
La verdad yo también podría haberlo buscado en Google, pero simplemente me resultó más cómodo leer tu comentario en una tarde de sábado medio nublada
Gracias de nuevo
Solo por el título del artículo pensé que
<output>se estaba usando mal, pero al leerlo me llevé una gran sorpresa(Sobre todo porque al ver arriba la imagen dudosa de una calculadora GenAI esperaba un desastre mucho peor, pero al final el contenido me gustó tanto que solo volví a pensar en la imagen después de terminar de leer todo)
Esa imagen dudosa de la calculadora GenAI da muchísima risa
Puede sumar, multiplicar y dividir, pero no puede restar
Hablando de esa imagen dudosa de la calculadora GenAI
Siento que con la IA se nos olvida lo mucho más chafas que eran algunas imágenes hechas por humanos antes
Gracias a la IA, ahora al menos se pueden crear al instante imágenes que no den vergüenza
En este caso, (subjetivamente) creo que transmite bien una vibra retro vintage de TI, así que tiene cierto valor
No creo que todo uso de IA reemplace el trabajo de artistas profesionales
Siempre me gusta ver este tipo de cosas
Otro tip es poner nombres a los formularios de forma que coincidan con la estructura de datos del backend, para reducir la necesidad de leer valores o reconstruir datos con JS
Por ejemplo, algo así:
<input name=“entity[id]”><input name=“entity[relation]”>Así no hace falta crear datos aparte de forma tediosa en JS; basta con enviar el formulario y ya obtienes directamente los datos que querías