Apparently, it's about screen reader support in web pages.
Also "ARIA" stands for Accessible Rich Internet Applications and it's "a set of HTML attributes that make web content more accessible to people with disabilities."
So there's useful html tags from 2008 that no one uses or knows about... How can that be the case? Because there's just so many tags? Because people don't read the docs? Because the benefits are not obvious?
I came to this article expecting to see <output> misused, and was pleasantly surprised. :-)
(Actually, the dodgy GenAI calculator image at the top primed me for even more failure, making the excellent content that followed even more surprising. But I soon forgot about it and only remembered when I scrolled back to the start for no particular reason when done.)
I can see this having extreme value 20 years ago. Then it could take more than a minute to asynchronously get data back and you needed to tell people what content on the page changed.
Now, the bottleneck is entirely the database first and the framework second. Those can be switched if the framework code is extra garbage. When those are taken out of the equation I am seeing text update to the screen in about 5-15ms in response to a user interaction that requires execution on the localhost server, 45ms for networked server.
At that speed you don’t need to alert the user of any content changes. You only need to structure the content such that walking the DOM, using a screen reader, from point of interaction to area of output is direct and logical, expected, for a human.
> Update 7 Oct 2025: Some screen readers have been found not to announce updates to the tag, so explicitly emphasising the role attribute might be worthwhile for now until support improves: <output role="status">.
Waiting for support to improve on a 17 year old tag that is barely used anymore?
> Like <label>, <output> has a for="" attribute. Here you list the ids of any <input> elements the result depends on
Any screen reader users able to comment on whether this is worth doing? I suspect this would be such a rarity online that screen reader users wouldn’t be familiar with it, but it depends on the UX of the software
If you have to use `role=status` to make it work with screenreaders, I'm not sure I see the point.
Maybe I'm jaded, I was all in on semantic xhtml and microformats before we got HTML5, but this seems like being overly-pedantic for the sake of pedantry rather than for a11y.
For a website speaking accessibility, it does something very bad and annoying with scrolling. Not using the native browser scrolling I think.
When I use the middle wheel of my mouse to go up or down, sometimes it suddenly it ignore the command or stutter or go back a little bit instead of continue going down or some random movement.
Even with using 2 fingers scroll with the touchpad, I can feel very slightly that there a subtle lag or stutter.
I don't think this was ignored for no reason or simply forgotten. I don't see it bringing a great feature or value compared to input tag. You still need to code up the logic for setting its value, via a script, like any other container tags. You could pretty much use a read-only input tag to include the output with the form.
Interestingly I've often seen this in Claude outputs, especially on long prompts. I've assumed this is because of Claude's XML-based instruction format, but this does make me wonder how related the two are. And if Claude may have a harder time using <output> given it's related to both accessibility and its instructions
I think the lesson here is if you want to provide an accessibility feature, you have to also make it do something useful for people that don't care about accessibility.
Problem with <output> is that it is half-baked making its usage almost useless.
It would be significantly more practical for the output to have "type" attribute in the same way as in the input.
I did experiment with oputput|type in my Sciter and added these:
type="text" - default value, no formating
type="number" - formats content as a number using users locale settings,
type="currency" - formats content as a currency using users locale settings,
type="date" - as a date, no TZ conversion,
type="date-local" - as a date in users format, UTC datetime to local,
type="time" - as a time
type="time-local" - as a local time, value treated as UTC datetime.
This way server can provide data without need to know users locale.
> The output element represents the result of a calculation performed by the application, or the result of a user action.
<output> is for changing content. It's the ARIA semantics that matter. The content gets announced after page updates.
You can put whatever you want inside the <output> to represent the type. "text" is the default. You can represent dates and times with the <time> element. And while there is currently no specific number formatting element, since Intl has arrived there have been many requests for this.
For example:
<output>The new date is <time datetime="2025-10-11">Oct 11</time></output>
IOW, <output> should not have to handle all these types when it handles HTML and HTML needs to represent the types anyway.
You are thinking about it wrong, output is not symmetrical to input to have a type, it's a container for content that updates while you're using the page.
And it would just show you the input value. Maybe with a "type" specifier like talked about. Maybe the ::before or ::after css and it would allow content: updates or something.
Bunch of <input> types that there's a reasonable case for. Especially if it allowed for formatting. Did you put in the type="tel" the way you believed? It prints it out formatted.
'checkbox, color, date, datetime-local, file, month, number, radio, range, tel, time, url, week' might all have possible uses. Some of the text cases might have uses in specific conditions. 'email, text, url'
Also be nice if the for="" attribute actually did very much. The attachment seems mostly irrelevant in the examples seen. Most example just use a variation on:
The article was all good until he started to use react for implementation. I would not have done that for an article about web standards, and I use react all the time.
Hell html in 2025 feels so underdeveloped, semantic html should just be declared dead and we should just move on. How many years we wasted by having "experts" underlining the semantic meaning of aside, article, main etc? Good lord, perhaps we should just totally skip the dom and use a graphics, input and accessibility api the way we want
I honestly don't know what is it for. Why is it important to have an output tag.
The output of any actions will be shoved into any N random elements. So every `<div>` will have `<output>`? Why? Waste of payload size and CPU cycles in parsing.
The designers of semantic tags truly live in ivory towers.
Semantic html is a novice trap, just do the thing that works and that browsers expect (aria-live)
It's fun to play around with things like this, but if you're a developer you have a responsibility to build things that work for your users using the existing tools and ecosystem. Don't use semantic HTML tags that aren't widely used, just do the thing that works.
Another is structuring your form names to help align with how it’s going to be used in the backend so you don’t have to use JavaScript to gather all the data or be doing a lot of restructuring of the request data.
This is an oversimplified example but now even if you submit with JS, you just have to submit the form and the form data is already there.
32 comments
[ 3.8 ms ] story [ 40.8 ms ] threadAlso "ARIA" stands for Accessible Rich Internet Applications and it's "a set of HTML attributes that make web content more accessible to people with disabilities."
(Actually, the dodgy GenAI calculator image at the top primed me for even more failure, making the excellent content that followed even more surprising. But I soon forgot about it and only remembered when I scrolled back to the start for no particular reason when done.)
Now, the bottleneck is entirely the database first and the framework second. Those can be switched if the framework code is extra garbage. When those are taken out of the equation I am seeing text update to the screen in about 5-15ms in response to a user interaction that requires execution on the localhost server, 45ms for networked server.
At that speed you don’t need to alert the user of any content changes. You only need to structure the content such that walking the DOM, using a screen reader, from point of interaction to area of output is direct and logical, expected, for a human.
Waiting for support to improve on a 17 year old tag that is barely used anymore?
Any screen reader users able to comment on whether this is worth doing? I suspect this would be such a rarity online that screen reader users wouldn’t be familiar with it, but it depends on the UX of the software
Maybe I'm jaded, I was all in on semantic xhtml and microformats before we got HTML5, but this seems like being overly-pedantic for the sake of pedantry rather than for a11y.
Is there a way to search by code?
> It’s been in the spec for years. Yet it’s hiding in plain sight.
Almost as if we're... blind to it?
No? Too on the nose?
Yeah, count me on with those who don't even know it exists. I'm adding this to my TIL.
> When I searched GitHub public repos, it barely showed up at all.
> That absence creates a feedback loop: if no one teaches it, no one uses it.
This has triggered an instant question in my head: Do LLMs actually use it when generating code or they are not well-trained for this specific tag?
It would be significantly more practical for the output to have "type" attribute in the same way as in the input.
I did experiment with oputput|type in my Sciter and added these:
This way server can provide data without need to know users locale.> The output element represents the result of a calculation performed by the application, or the result of a user action.
<output> is for changing content. It's the ARIA semantics that matter. The content gets announced after page updates.
You can put whatever you want inside the <output> to represent the type. "text" is the default. You can represent dates and times with the <time> element. And while there is currently no specific number formatting element, since Intl has arrived there have been many requests for this.
For example:
IOW, <output> should not have to handle all these types when it handles HTML and HTML needs to represent the types anyway.Bunch of <input> types that there's a reasonable case for. Especially if it allowed for formatting. Did you put in the type="tel" the way you believed? It prints it out formatted.
'checkbox, color, date, datetime-local, file, month, number, radio, range, tel, time, url, week' might all have possible uses. Some of the text cases might have uses in specific conditions. 'email, text, url'
Also be nice if the for="" attribute actually did very much. The attachment seems mostly irrelevant in the examples seen. Most example just use a variation on:
Because we don’t need another fucking tag, that’s why.
The output of any actions will be shoved into any N random elements. So every `<div>` will have `<output>`? Why? Waste of payload size and CPU cycles in parsing.
The designers of semantic tags truly live in ivory towers.
It's fun to play around with things like this, but if you're a developer you have a responsibility to build things that work for your users using the existing tools and ecosystem. Don't use semantic HTML tags that aren't widely used, just do the thing that works.
Another is structuring your form names to help align with how it’s going to be used in the backend so you don’t have to use JavaScript to gather all the data or be doing a lot of restructuring of the request data.
This is an oversimplified example but now even if you submit with JS, you just have to submit the form and the form data is already there.
<input name=“entity[id]”>
<input name=“entity[relation]”>