The <output> Tag
Posted3 months agoActive2 months ago
denodell.comTechstoryHigh profile
calmmixed
Debate
60/100
HTMLAccessibilityWeb Development
Key topics
HTML
Accessibility
Web Development
The article discusses the lesser-known HTML `<output>` tag and its potential benefits for accessibility, sparking a discussion on its usefulness and the challenges of implementing semantic HTML.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
26m
Peak period
149
Day 1
Avg / period
40
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Oct 11, 2025 at 4:27 AM EDT
3 months ago
Step 01 - 02First comment
Oct 11, 2025 at 4:53 AM EDT
26m after posting
Step 02 - 03Peak activity
149 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 20, 2025 at 6:15 PM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45547566Type: storyLast synced: 11/22/2025, 11:17:55 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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."
You'd be surprised how many people barely know it exists... I was a TA for my uni's Web Engineering and Ethics in CS courses and accessibility never even came up in either course.
That is genuinely baffling to me. How does a university teach web engineering without even mentioning accessibility? It’s not just best practice—it’s often a legal requirement for public-sector sites in many countries. Even outside government work, major companies (FAANG included) publicly invest in accessibility to avoid both reputational and legal fallout. Ignoring it entirely sends the wrong message to students about professional responsibility and real-world standards.
It’s why ‘self taught’ in many disciplines is very doable too, if someone focuses on what people actually want/need.
They might not be good at articulating the differences between fizzbuzz and bubble sort, but they can get shit done that works.
Every PhD that I know that went from Academia to Industry immediately had their stress levels decrease 10x and their pay roughly double too - because they could finally do a thing, see if it worked or not, and if it did, get paid more.
Instead of insane constant bullshitting and reputation management/politics with a hint of real application maybe sprinkled in. Few ‘knives’ have to be as sharp as the academics, in my experience.
For example: You don’t realize how absolutely abysmal voice control is for computers until you have to use it.
There are so many assumptions about the world that causes things like neurodivergence to become a disability instead of a difference.
Fair. I might’ve read more snark in the “Apparently,” than the commenter intended to convey.
For what it’s worth, the comment you read is the toned down version of what I had initially come up with. I really don’t think being dismissive of accessibility concerns is good style.
>> The first rule of ARIA use is "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
In before comments - not advocating for div only development, just that the nature of www moved from html with some js to well ... only js.
Why don't we just have markup for a table of contents in 2025?
It's clear that you are sighted and never use reader mode.
I think the parent has a good point: browsers don't do anything with these tags for sighted users, who are unfortunately the majority of developers. If they were to notice benefits to using semantic tags, maybe they'd use them more often.
I use reader mode by default in Safari because it’s essentially the ultimate ad blocker: it throws the whole site away and just shows me the article I want to read.
But this is in opposition to what the website owners want, which is to thwart reader mode and stuff as many ads in my way as they can.
It’s possible good accessibility is antithetical to the ad-driven web. It’s no wonder sites don’t bother with it.
Sure, it allows the browser to do that. GP is complaining that even though browsers are allowed to do all that, they typically don't.
[1] - eg https://picocss.com/
But if you are a developer you should see value in <article> and <section> keeping your markup much much nicer which in turn should make your tests much easier to write.
Around the time that abbreviation became fashionable using a lot of DIV elements also did, but that wasn't what the "D" stood for.
https://en.wikipedia.org/wiki/Dynamic_HTML
Descriptivism usually reflects some reality no matter the intended prescriptives.
We had table based layouts and then divs when CSS started to take off, mostly used by artists rather than companies at first.
Javascript had vanishingly limited uses at first, too. I don't remember exactly how long it took us to get XHR but before that we had "Comet frames", before iframe security was given much focus. Javascript couldn't do that for a while. It was also dodgy and considered bad practice for quite a while, too.
I don't remember when the term javascript was even really used in regular vernacular but DHTML was not so much referring to CSS as it was the myriad of weird mechanisms introduced to make pages dynamic. It was never "Div-based HTML" or whatever, the div craze came way later once CSS was Good Enough to eschew table layouts - after which, Dreamweaver died and photoshop's slice tool finally got removed, and we started inching toward where the web sits today.
I also do distinctly recall needing a doctype for DHTML for some browsers.
It wasn't as fast or as usable as it is today, but Javascript has been in every mainstream browser since before Microsoft started pushing "DHTML".
Interestingly, in my memory, it seemed like we had JS for a long time before DHTML, but it was only a couple years between Eich writing it and IE4, which was the start of the "DHTML" moniker. Looking back at the timeline, everything seems much more compressed than it felt at the time.
2004 or 2005. Gmail and Google Maps were a "holy crap this is actually possible?" for a lot of people, both technical and non, and was when javascript switched from mostly-ignored* to embraced.
*Just minor enhancements, outside of technical people mostly only known to MySpace users who wanted to add a little flair to their page. XmlHttpRequest was almost entirely unknown even in technical spaces until gmail showcased interaction without page refreshes.
CSS was not there in the '90s because Netscape didn't implement, and MS did its own subset.
JS and CSS both suffered from wildly inconsistent support between Netscape and IE, but JS at root had interop enough to support hotmail, later OddPost, much more. CSS had no extension mechanism based on JS then, so it suffered browser-specific support that was IMHO worse than JS suffered. No way to polyfill.
Divs weren’t a “craze”. They were popularized by the (brand new) XHTML spec, which did have its own doctype.
See also the dictionary fallacy, and again descriptivism vs prescriptivism.
Additionally, even leaving alone the div/dynamic language issue, there really isn’t a point in usage history where DHTML came without JS — believe me, I was doing it when the term first came into usage. JS was required for nearly all dynamic behavior.
DHTML is an acronym that expands to: Dynamic HyperText Markup Language.
There is no dictionary fallacy or descriptivism vs prescriptivism or defined meaning. It was simply an industry standard way to shorten all those words.
Changing one of the letters to stand for something else reassigns the pointer to something else entirely, or is the making of a joke, which I think the above may have been.
https://en.wikipedia.org/wiki/Server_Side_Includes
https://matthodges.com/posts/2025-09-30-visidata/
Not that this is problematic per se, everybodies milage may vary and we're all out there to learn. But if I told one of them about the output tag thry probably wouldn't even understand why that would be important.
Then no one checked, and the javascript train had already left the station.
You have to remember, this is an industry that thinks having code without syntax errors was too unreasonable a requirement for XHTML, there is no reason to expect them to know anything beyond div and maybe a dozen other tags.
Maybe it's because like most things html/css related, it's a semi-broken implementation of a half-feature?
(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.)
It appears human beings are already forgetting the even more dodgy images some of us created before AI allowed us to reduce said dodginess. Or actually get a picture we could post without too much shame. :)
And in this case, IMHO, the image has a significant amount of dodgy vintage tech charm.
Not every use of AI replaces a professional artist.
It normalises it.
1. The techniques, inspiration and creativity of skilled human artists.
2. The personality of art by unskilled artists.
3. The use of generative AI to replace generic clip art. A little whimsy to dress up plain text.
Is anyone really crusading to protect generic clip art? No?
There should be something like rule 34 for social and cultural movements. For every movement, the ideological version will get performatively or knee jerk expressed, with shame throwing, in benign situations.
> Actually, the dodgy GenAI calculator image at the top primed me for even more failure, making the excellent content that followed even more surprising.
This was poor spirited, personal itch scratching. We can just compliment a writer on their writing, if they are a writer, presenting themselves as a writer, not a visual artist.
I'm fairly confident that this article is primarily AI-written as well
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?
It’s obviously the screen readers’ fault.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
https://github.com/nvaccess/nvda
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
That said, I imagine it's more useful to do the opposite, label the output itself e.g.
<label for="output">Total</label> <output id="output">£123.45</output>
That way it will be announced like "Total, £123.45" rather than a random number with no context
This is handy for testing with screen readers, and includes links to the appropriate spec (for output and all elements):
https://stevefaulkner.github.io/AT-browser-tests/test-files/...
The browser may add a reference from one to the other in the accessibility tree, but whether a screenreader announces it is another matter. I'd be surprised if it's supported in any meaningful way here. Happy to be shown otherwise!
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?
You could, but then you wouldn't be gaining any of the accessibility wins the article is discussing...
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?
AI software development models and agents can be "taught" to go look at the official version documentation for languages via the prompt (just as one example) without needing to modify their weights.
One call to getSpecification('Python','3.14') or some similar tool call and they know exactly what they are working with, even if the language version did not exist when the model was trained.
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.<output type="currency"> uses the same convention as "Intl.NumberFormat/style=currency": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
They are correct in that if you're displaying a currency value, you have to know which currency it is in, right? It wouldn't make sense for the server to be "unaware" of the locale of the value.
That said, your comment sidesteps that issue and addresses how the number itself is displayed, since ultimately the value itself is a number, but different locales display numbers differently.
So the person you're responding to is asking: since the server ostensibly already knows which currency it's in, shouldn't it already be formatting the value appropriately, and that's more a question of where one thinks localization formatting should ultimately live in web app context.
If you see a price in Euros and there's a chance the browser converts the number to my locale, then the price becomes completely ambiguous. Information is lost unless I change my locale just to see if the number changed.
If, on the other hand, the browser doesn't apply such formatting, then the number is probably the number.
What's more, wouldn't you need to specify an origin locale so the browser knows how to correctly interpret the value?
If you want specific country format then you may use lang:
<output type="currency" lang="de-DE">123456.00</output>
Currency conversion is not a subject of a browser.
€1,000.48 = 1.000,48€
A payment, bill, price, etc has a particular currency.
For example, 59.95 Australian dollars:
In en-AU locale, that is $59,95.
In en-US locale, that is 59.95 AUD or AU$59.95.
Either way, the quantity and units are the same, but they are presented differently.
In some cases, there may be currency exchange services. That will depend on the current exchange rate, and possibly exchange fees. And yes, that will take some more work. But that’s a fundamentally distinct concept than pure presentation of a monetary amount.
It's sad how many elements this is still the case for in 2025. A good chunk of them can be blamed on Safari.
Probably the most extreme example of this is <input type="date"> which is supposedly production-ready but still has so many browser quirks that it's almost always better to use a JS date picker, which feels icky.
I then proceeded to spend the next week crying trying to get JS date picker to work as well as native did on my browsers.
https://caniuse.com/input-datetime
It's actually a little surprising to me since these are somewhat basic controls that have been around in UI toolkits for decades. It's in that weird sweet spot where the building blocks are almost usable enough to build rich applications, but it's just out of reach.
Formatting output values to the user’s locale has nothing to do with currency exchange rate. And JavaScript does the former rather excellently (except when the locale is not supported [ahm, Chromium]).
Not saying decisions can't be made about these things, just that, making those decisions will pretty much make a dedicated DSL out of a single element (dependent on input, desired kind of output (absolute or relative), other data sent along side (type of currency, does it need to be a "real" currency? Since instead of just calling something in mutable/overridable JS, its now part of the HTML processing, something that can't directly be touched)
There have been a bunch of requests for Intl-driven related elements in HTML, and I expect them to be added at some point.
> 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?
25 more comments available on Hacker News