The UX of HTML (2023) | Hacker News Reader

The UX of HTML (2023)

htmhell.dev

183 pointsBrajeshwar92 comments

Speaking from the experience of building small web apps for personal use, trying to follow semantic HTML in good faith has been nothing but a source of frustration. The rules are clearly molded around static, primarily text-based documents defined upfront, and anything that doesn't fit this format feels like a second citizen at best. Take headings, for example: in component-based development, I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless. As much as I want to be a good citizen, if I have to fight the platform for it, you're getting divs and h2's everywhere.

It is perfectly reasonable and accepted html to use custom element names. Any element with a `-` is styled like a span by default.

  <article-content>
    <author-byline><author-byline>
    <content-text></content-text>
  </article-content>

This has the benefit that you can describe your markup however you'd like if it doesn't fit into the standard elements, and if you find yourself in "div soup", often times this is mitigated through class names, but using custom elements, the closing tags are much more readable than

      </div>
    </div>
  </div>

Custom elements are incredibly powerful. Not only do they have their own tag name for easy selecting from css without having to use a class, but by adding custom attributes (eg size=“large”) you can basically eliminate the need for css classes entirely. Combine that with attr() to put the attribute value anywhere in or around the element with pure css and plenty of interactive components can be built purely with css, no scripting required. You can even use the @media scripting block to add noscript behavior to custom elements from css.

And then you can register a javascript class with customElements.define to add more dynamic behavior, and the sky becomes the limit. Custom elements are like a hidden framework built right into the browser.

I didn’t know any of this.

I feel like a huge door just opened on an idle Saturday morning. I need to experiment to form some opinions.

Thank you & parent poster too.

If you're interested in learning about this stuff, I recently made a website about it: https://plainvanillaweb.com/

This was recently posted to HN and I started to read it. I think your explanation for web components is the best I encountered so far.

That site is good - i might have missed it in your site but one thing I’ve run into with custom elements today is accessibility - testing with a screen reader has shown up lots of issues. Maybe custom elements aren’t perfect but they are handy.

I'll add it to the todo list :)

how every accessibility effort ends

this is a good article on styling with custom elements too: https://www.keithcirkel.co.uk/css-classes-considered-harmful...

While I believe you are entirely right from a developer perspective. I do wonder if the same is true from a UX and more specifically accessibility perspective as the author in the article describes.

If you are unsure what I mean, from the article

> I show them that a span with an onclick-event might seem to be behaving like a link, but that there are many layers of UX missing when you look a bit closer: right-click on this span, and a generic context menu opens up. When on the other hand you right-click on a proper link like this one a specialised context menu opens, with all kinds of options that are specific to a link. And I show them that proper links show up when you ask your screen reader to list all the links on a page, yet spans with an onclick-event don’t. Moreover, a span doesn’t receive focus when you tab to it. And so on. My students see this and they get it. And they love the fact that by being lazy they get much more result.

Accessibility will rely on correct use of landmarks [1] and aria attributes, as well as real links (like the article mentions). Custom elements can do that just fine, by either decorating them with aria attributes manually and placing them in or around landmark elements, or by having the JS side of the custom element take care of that automatically. The JS class can generate any necessary markup inside of the element to help make it accessible, just like a component built with a JS framework would, and by using shadow dom and slots this markup can wrap around the child elements (though I think it's best to try to avoid shadow dom, as it is quite a cumbersome API to deal with). UX is a bit of a similar story, any kind of UX can be achieved once you register a JS class for the custom element.

[1] https://developer.mozilla.org/en-US/blog/aria-accessibility-...

I didn't know this was possible. I thought you were forced to use Javascript to define a custom element - this severely reduced its attractiveness. Why use JS for static UI ?

I don't know why custom elements never became common knowledge. I've had PR's blocked by people convinced I was doing arcane black magic by using them.

But they've been worked this way for decades. Now they weren't officially added to the spec until browser support for v1 of custom components, but that was still back in 2016.

Wait... I can just declare one of these in HTML without doing all the CustomElement JS jiggery-pokery?

No need to declare anything, just use the tag.

Sounds like you did not jump into the pool of flexibility and reusability.

> Sounds like you did not jump into the pool of flexibility and reusability.

Quite a good analogy: a pool is responsible for more drownings than you'd think.

Most people in the pool of flexibility and reusability are drowning in it.

Interesting, I did not know this was a thing. I just gave it a try and it seems to work as advertised. I'm definitely going to use that more. Div soup is super hard to untangle when you are debugging layout issues and I love having more readable html

It is the same div soup for a screen reader, because there is no behavior attached to those new tags. They can not be a landmark, there are not marked as headings, they have no roles. Just a container with a text. And to attach the behavior you need to use javascript. So without js it wont work.

Why bother and try yo create half-baked non working solution if you can just use html?

Well, it easier to style, maybe. But hey, there is a class attribute.

Custom elements are for when semantic elements run out, don't apply or are unnecessary.

Semantic elements are always preferred.

This would be way more helpful if browsers all supported extending built-in elements and inheriting accessibility features.

For example, if `class DropdownMenu extends HTMLSelectElement` worked, you could have full control of styling and functionality without having to recreate all the a11y support baked into `<select>`. As it stands today, this will be treated as a div and its all on you to make it accessible.

Safari (Webkit) is the hold-out on having this: https://caniuse.com/mdn-api_customelementregistry_builtin_el...

The reasoning for choosing not to support it is here: https://github.com/WebKit/standards-positions/issues/97#issu...

Thanks! I was pretty sure Safari was the only major holdout but didn't have a link handy and didn't want to speak out of turn there.

That kind of support is a really tough one to work around with a major browser lacking support. For certain features its not a big deal, but when it comes to extending to get full accessibility support the only substitute is avoiding the feature and rolling it all custom. It really is a shame in my opinion, extending built-ins is extremely powerful.

Blame Safari. The standard includes the `is` attribute, it's supported by all browsers except Safari, but Safari not only hasn't worked on supporting it, they've stated they won't do so.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

I think in part, it's also a case of there being some agreement on standard textual mark-up but not universally. And for good reason: books aren't journal articles, journal articles aren't poems, and heading and paragraph boundaries differ between languages.

Even practically, are sections part of articles? Or aticles part of sections in the context of a collection? Why do we need six heading levels, not four or seven? The semantic hierarchy does equally apply across publication contexts.

Even for text documents... for the love of documents, why wouldn't you have an official table of contents element?

Someone in a nearby thread mentioned custom elements. If we don't agree on meaning then it's not very semantic! Part of the power of agreement on semantics is that the more we have of it, the more we have things like Firefox or Safari's reader mode, which remolds the website to the user's desire.

What would a specific table of contents element bring over a <nav> inside your <main>/<article>?

(As demonstrated in the first example of https://html.spec.whatwg.org/multipage/sections.html#the-nav...)

I'd look to what Wikipedia provides as a document reading experience. The problem with nav is that there weren't enough tags so developers will rightly use them for other things, such as breadcrumbs. I'm looking for exclusive ToC that will allow reader mode to go further.

The heading hierarchy is the table of contents. Rather than some magic that creates a set of anchor links that link to the page's headings, I want browsers to provide what screen readers do, list the headings and let people keyboard navigate to them without site authors having to do anything.

"SkipTo Landmarks & Headings" is a browser extension that somewhat does what I'm describing. It's harder for an extension to handle this smoothly compared to a browser. https://skipto-landmarks-headings.github.io

> The rules are clearly molded around static, primarily text-based documents defined upfront

I mean yeah, that‘s what the web was created for after all. There was no need to invent yet another operating system and desktop environment to replace the ones already existing. The advertising industry capturing the web and brainwashing one generation after another of „web developers“ locking in with said web developers seeing the web primarily as an economical niche to carve out and a means for job safety, is what happened. The end result is that the majority of actually interesting information you want to read is on archive.org nowadays, and on „platforms“ when easy self-publishing was the entire point of it.

Yes HTML is stuck being a markup language for casual academic publishing. Starting in 1997, people wanted to add entire new vocabularies, but W3C botched it by focussing too much on „meta“ stuff, subsetting XML from SGML but then not using it for actual emergent text formats apart from SVG and MathML such as blogs, drama, novels, wikis, etc. Instead they diverted into unproven XForms and SemWeb, leaving HTML in an organizational lock for ten years during the forming years such that everything else (CSS, JS) had to bend around HTML inflexibility, finally having the gall to call that failure a virtue (the structure-vs-presentation dichotomy, „semantic“ HTML, tunneling JSON through HTML, etc.).

> There was no need to invent yet another operating system and desktop environment to replace the ones already existing.

Actually there was. My web apps can be used in Windows, Linux, Mac, Android, iOS, Meta Horizon OS, etc. thanks to it being a standard that is more or less not controlled or gatekept by a single entity (browser monoculture aside). Java applets died because of it.

You could argue that it wasn't wise to shoehorn interactive functionality in what was essentially a document presentation format, but that's another story. Having documents and applications intertwined is often cited as a drawback, but I disagree with that since we often want to have app-like behavior for parts of documents, or document-like behavior for parts of apps. Think e.g. interactive programming tutorials with executable REPLs and code examples... we have the ability to create books that are alive, and that's simply amazing.

Thing is, the Web platform is what won, and for good reasons. GTK, Java Swing, and other supposedly multiplatform toolkits did not lose just because -- they lost because the Web is objectively better.

HTTP is awesome. HTML is awesome. CSS is awesome. JS is awesome. JSON is awesome. WAI-ARIA is awesome. The whole web stack is awesome.

I feel that all the negative sentiment around it is just because we cannot fathom how much worse it could have been had the HTML5 effort never happened.

> Actually there was. My web apps can be used in Windows, Linux, Mac, Android, iOS, Meta Horizon OS, etc. thanks to it being a standard that is more or less not controlled or gatekept by a single entity (browser monoculture aside). Java applets died because of it. > > Thing is, the Web platform is what won, and for good reasons. GTK, Java Swing, and other supposedly multiplatform toolkits did not lose just because -- they lost because the Web is objectively better.

To be honest I consider Java Swing better than current "fancy web UI". At least it's more consistent and at least try to match the OS... I loath the "creative bunch" that tries to re-invent the wheel and be all flashy and whatnot.

Every app should try to match to the best possible way native OS. Yes, it's not possible 100% of the way but it would go a long way.

Currently we live in a world led by brainded bunch of "let's care about brand" and try to have same UI on all platforms as if users were switching constantly between windows/mac/linux or between iphone/android... no, they don't. At least in the mobile space they do try to be more native-looking and follow the theme but it's not all that great either.

Also. Java/Swing loose (especially on the desktop) because it was slow at the time and wasn't open like "web". Besides learning curve for the web was easier (hey, you can open web console, write `alert('bam!')` and it DOES stuff, wild!... and then it went downhill from there...

> I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless.

The sectioning algorithm proposed by early iterations of HTML5 mostly solved this and it’s a great shame browsers didn’t implement support for it.

I'm fine with it failing. I think in practice developers would have fucked up regularly so the hierarchy still wouldn't match the content.

> Take headings, for example: in component-based development, I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless.

We could have used <h1>s everywhere with Document Outline:

  <body>
    <h1>top level heading (parent sectioning element is body)</h1>
    <section>
      <h1>2nd level heading (nested within one sectioning element)</h1> 
      ...
    </section>
  </body>

Unfortunately, this was never implemented in browsers and was removed in HTML 5.1.

https://html5doctor.com/computer-says-no-to-html5-document-o...

I usually just use <header> for section headers. Technically you’re supposed to put an h[1-6] tag inside a header tag, but I just drop the header text in there raw and style it with scoped CSS.

<header> and headings are very different. A heading is how you semantically signpost the beginning of a different section of content. A <header> other than one at the beginning of a page, is basically a DX convenience.

Headings are the major way people using assistive technologies can skim a page and navigate around. I think a <header> will still be treated as a landmark, even if it's inside other landmark elements, but it will be nameless so not nearly as useful.

It can be a struggle for some people in some situations to create pages with a heading level hierarchy that accurately reflects the content. Sometimes I think when there's any difficulty, authors should basically give up and follow a simple guideline: have one <h1> that says what the page is about and use <h2> for all the other headings.

The words put inside the headings are far more important than the accuracy of the heading level.

It looks like <header> is treated specially when it’s directly under the <body> tag, but generic everywhere else. This is actually what I want for some widgets which may be arbitrarily nested and aren’t really contributing to a hierarchy, but not others where I would want to be able to navigate between the sections using the headings. I like the idea of just using <h2> for all depths below the very top, I think I’ll start doing that for headers that should be navigation targets.

Edit: looks like that’s basically the WAI approach too, in that role=heading will default to aria-depth=2.

Yes, my recollection was wrong. There are some landmarks that can be nested inside other landmarks and still be conveyed but <header> (ARIA role "banner") isn't one of them.

Using <header> elsewhere for developer convenience is fine but that's all it is.

Headings are especially helpful for screen reader users are especially helpful but their value for sighted users are often underestimated. Developers think that by putting something in a box and by its styling that people will understand what it is, what it's for, when using a heading to put a name on it would be very clarifying.

horrific ux. makes html harder to read for people that dont have the time to learn all this obscure bs.

and for screenreaders this will work maybe sometimes inconsistently. I hope visual llms solve it for our brothers and sisters with special needs. ( and for webscrapers)

BECAUSE THIS NONSENSE IS NOT SOLVING ANYTHING FOR ANYBODY

As I mentioned in another comment, I think developers would have fucked up way too often and the hierarchy still wouldn't be right. Having the right heading levels is not something that can be solved by an algorithm, it depends on a human understanding of the content.

I agree that when developing a component, or even a discrete piece of content, you shouldn't have to care about its place in the heading hierarchy of whichever pages it appears on. But someone needs to care.

There's an HTML spec idea kicking around that's currently called `headinglevelstart`. I think the idea is you put it on an element like <section> and give it a value and the heading level of any heading element within is incremented by that amount; use `headinglevelstart="2"` and an <h1> within is treated as an h3, an <h2> as an h4, and so on (I think extending the valid heading levels from 6 to each least what ARIA supports, 9, is along for the ride). It can even be a negative value so an <h2> heading that's typically lots of other pages could be "elevated" when it's by itself on its own page by adding `headinglevelstart="-1"` to a parent.

I don't know if `headinglevelstart` is a particularly good idea or if it will happen but it's definitely an aspect of the web in need of improvement.

I had the advantage of having a mentor early in my career hold my code to the highest standards with regards to using the semantics of HTML. We were working on a big redesign of a large website for BigCorp, but we were still a small team on a deadline. She would not accept any excuses, and she guided me to think through HTML element selection until we found what we considered the best choice. I was taking the bus to work most days and used the time to read on the bus and at home the thick book "CSS: The Definitive Guide" by Eric Meyer cover to cover.

As you mention, working with HTML, and even more so CSS, can be a source of frustration. The UX of actually working with them is tedious work. However I can write today that all these years later, the high standards that my mentor held me to (and the project required) helped me to master HTML and CSS in a way that made doing that work less tedious, and easier over time. I was being paid to be educated by an expert - I considered it a great opportunity, and believe I have been proven correct.

In the post Vasilis writes that they told their students the assignment "doesn’t have to be semantic and shit". I consider this a missed opportunity to hold them to higher standards and help the students build a strength that can help them for years to come. More broadly, I believe this to be an example of current generations being limited by their mentors and educators lowering standards, and potentially robbing them of opportunities. Impedimentum Via Est.

I'd argue that the semantics of <bigcorp-career> vs <into-webdev-class> are different enough that it's a bit of an antipattern to apply the same style to each.

Many original HTML elements suck.

Best known are checkboxes that can't be styled. But they're still needed, so they're hidden and overlaid with pseudo elements. Now you already have the box, :before, :after and the label and :checked special style. Oops. Better also load a whole font to even render the check mark consistently.

The select and option elements are also terrible. So terrible in fact that iOS breaks its own guidelines and instead shows a new page with all options listed. Example: Language selection. Then there's the developer experience. Can JavaScript stop a selection? Can I hook up an element handler for change? And so on.

I strive to use the "correct" elements, but they do have serious shortcomings.

Pico CSS seems to style checkboxes without pseudo elements: https://picocss.com/docs/forms/checkboxes

(It uses `appearance: none` instead.)

They use background-image for a :checked checkbox. The image is an inline SVG – clever!

I've often been responsible for telling designers and product management alike "no, we aren't going to style the checkboxes how you like" several times in my career.

Interestingly, when deadlines and functionality really matter the "look" of a checkbox isn't that important.

I confess I was sceptical about this article based on the URL, but this is a really good article and articulates some ideas about "semantic and shit" that I've thought about but not really been able to express.

Using the correct elements isn't necessarily about doing things "right" for the sake of being right, it's about making things easier for you and your users. Easier for you because usually the right semantics are in place already, and you just need to tweak some colours and styles and get things looking how you want. Easier for your users because the elements will do what they expect when they try to right click, middle click, use a screen reader, etc.

The UX angle makes it clearer that the aria tags or semantic elements aren't the goal in and of themselves.

Every time an article--such as this--is posted somewhere, it's immediately followed by a series of responses where one is unable to make a web page work the way they want it. Often there is no representation of the markup they used. More often the markup they show is invalid and nonsensical.

In other posts about programming languages, you can't write invalid code because the compiler will complain and stop. When the browser fails to render your HTML, one complains about HTML and rants about how it was developed in the 1990s while forgetting that their own programming language might have been developed long before that.

I've been developing web sites commercially for 25 years. I have no such issues making highly performant, modern and cool web sites.

I recently wanted a table with a vertical scroll bar. Nothing fancy. If the table reaches some maximum size, a scrollbar should pop up, and only the data should scroll, the header should stay on top.

I've read a lot of stackoverflow, did a lot of arcane css, learned a bunch of display:table obscurities, and still every option broke somewhere, UI wise. Presumably, some magic combination of css incantations should work.

But I can't spend 2+ hours on a table, and even if it seems to work, I can't guarantee it will continue to work or break subtly on some edge case. And this is very basic stuff, UI wise. I've setled for div/class soup, gridlayout, and a few aria selectors.

What was wrong with a <table> inside a <div style="max-height: ...; overflow: scroll">?

I've forgotten a lot of the errors so don't quote me on this, but I think the table header scrolls out of screen

That’s when you add position: sticky to the relevant row. Search for “sticky table header” for the proper CSS incantation.

But now what do you do when you want a sticky footer too?

The same trick works for footers, just use bottom:0 instead of top:0

I will have to try this, thank you :)

I tried. I think the scrollbar bled into the header at this point.

Update: I remember now: The rows were drawn on top of the header. Their background must have been transparent or something.

Maybe you could set the Z-index

Unless other items it’s colliding with also have explicit z-index, there’s no need to mess with it, just make sure the background is opaque.

I tried both: added multiple variations of z-index: and background-color:. There must have been something else in there neutering these. I didn't see it in the developer console.

Now you all must be right: This must have been fixable somehow. Now the application contains 10+ years of CSS evolution, maintained by at least 4 predecessors and a bunch of quick and dirty maintenance hacks. It's a huge tower of exceptions built on exceptions . I had already blow way past my time budget for something I had estimated easy, and creating a table wasn't even the core of the job. So I cut my losses.

That’s another source of frustration. God only knows how many hours I’ve spent on individual problems like yours, and what did I learn from diving into the specs and reading every Stackoverflow post on the topic? Nothing. Only how the intricate interactions within CSS eventually allowed me to solve that particular problem, details which I’ve long since forgotten because they’re not relevant anywhere else.

The shift of screen sizes for computing devices from a single aspect ratio (4/3 monitors) to just about anything created a nightmare for UX, and web development is suffering from it. I still maintain that no-one should have to scroll to use software. Everything you need for a certain place in an application's workflow should be on one screen. If the size of the screen means that more steps are needed to complete a task using software, then that should be handled by the adaptability of the software (including larger text for visually impaired people). Scrolling was the work of the devil. As for accessibility, it makes a blind person able to become familiar with how many elements are available on any screen they use based on their own experience.

Do you have any reference resource where I can see something along the lines of "before with scrolling, after removing scrolling" examples?

I too hate scrolling, what can I do about long tables? Pagination is half the solution.

How to write documentation that fits one screen size, with images and tables?

> I still maintain that no-one should have to scroll to use software. Everything you need for a certain place in an application's workflow should be on one screen.

Independent of whether you agree with that, it is just completely unrealistic to achieve, in a sane way.

Without using 7 levels of nested submenus, which is also horrible UX, it will never be possible to present all features of e.g. Word on my 4.7“ phone screen.

Where did you find a phone with a 4.7" screen? Do they still have some? (Please tell me it isn’t an iPhone...) Every time my phone’s battery fades into unusability, I struggle for a bit before resigning myself to having a larger phone than before.

I've seen this referred to as something like "Scroll content, don't scroll the app".

And of course we now have Apple of all companies where they botched that even in native apps (like settings)

Do you suggest then that HN show every page of every comment on a separate screen?

Rigid dogma does not make for good UI.

HTML semantic tags and the World Wide Web at large are very rooted in traditional academic research papers. One of the new awesome features HTML brought was the "hyperlink" to go to another document from citation.

With single-page apps and the like, even with early jQuery, it seems we overload the HTML language to do so much when it's so often just used as a tree of nodes w/ no meaning until you get to a node.

Things get even more complicated when you use HTML just as GUI for an app and not for a document.

I will definitely try your approach of not talking about semantics but about the free UX you get when using the proper elements. I have the same experience when talking to my devs about semantic html.

This is a very limited view that (understandably so) forgets that screen readers and other accessibility tools do offer more UX that is normally not obvious for us, able developers.

This for example is very wrong if you take accessibility into account:

> Yes, I know that some sectioning elements actually have some UX attached to it. But not that much UX if you compare it to the real interactive elements. Not getting your heading levels right is not at all as destructive as using divs instead of links.

We often forget about accessibility users, not because we don't care about them (well, sometimes that too, I'm sick of hearing "we can't spend that much time on such a small percentage of users"), but because we are not even aware of how accessibility tools make use of the semantics around HTML. We don't live in the "accessibility world" and it's not ingrained in our development practices so it doesn't even cross our minds. We already fail at non-accessible UX (as the article correctly points out; which BTW also affects accessibility) so how can we not fail at providing the means to navigate via tools we don't even use?

I've recently been tasked with fixing a web app to make it more accessible (due to government mandate), and using a screen reader to debug has been an eye-opening experience (no pun intended). I wish every developer tried a screen reader at least once.

For example, do you know how important the different WAI-ARIA patterns are? See for example the alert pattern[0] or how landmark regions[1] (which the paragraph above dismisses as having very little UX) help accessibility users navigate.

Have you ever tried the full-page accessibility tree [2] in the browser's devtools?

There is so much hidden UX that we take for granted as sighted users, such as communicating field set relationships visually (by having related fields be close, or e.g. padded at the same level) instead of providing accessible UX like grouping those under an actual properly labeled `fieldset`.

I know it's not your fault as a sighted user (out of sight, out of mind; goes both ways) but I'm a little saddened by the state of accessibility good practices -- both because they're not taught anywhere and because the platform sometimes fights against us (e.g. as one of the other threads points, manually setting heading levels is a pain in the ass).

Accessibility users should be able to navigate the web too. And not only those with visual impairments -- proper accessibility is not only for screen readers.

[0] https://www.w3.org/WAI/ARIA/apg/patterns/alert/

[1] https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/

[2] https://developer.chrome.com/blog/full-accessibility-tree

I once tried out a screen reader out of personal interest but gave up after an hour or so due to how frustrating the experience was. I couldn't find the right key combinations or had a hard time remembering them because there are so many and none of them seemed intuitive. I also accidentally toggled some option using the wrong keys and then other basic things stopped working with no apparent way to recover from that. My suggestion would be to improve the UX of screen readers for sighted developers, e.g. by adding a little bit of UI to access the most important features without having to study the tool for days.

I would recommend using the VoiceOver / TalkBack feature on your phone instead. It's a lot more intuitive. With VoiceOver learning to use the rotor gives you the experience that fully blind people are likely to use.

https://support.apple.com/en-us/111796

Annoyingly, we've been reading various versions of this article for around twenty years, yet the problems it discusses still exist. Unsure why, and what the solution is.

The “problem” is that html is largely free-form as schemas go, so undifferentiated div soup is perfectly valid. Being able to easily define a document schema kind of died out with xhtml, and no one uses html5’s official xml encoding.

Basically it’s up to the content generator to produce semantically nice html, whether that’s a fancy editor or a widget toolkit. When I use PrimeVue for example, the generated DOM is chock full of ARIA attributes.

HTML is, imho, a victim of its own success (and the even bigger success of the web browser / server paradigm in rolling out not just documents - as was the original idea, but full blown "apps").

Already the first part (HTML as the basis for universal web publishing of all kinds of documents) is quite unprecedented in scope. Did the print world of physical books and newpapers ever produce a global "semantics and shit" paradigm? No. Within the walled gardens of a major publisher or the walls of a monastery reproducing manuscripts there may have been consistently followed rules.

In other words: we never had anything better. The current focus on "apps" is just turning a difficult situtation into a hopeless one.

There might some limited scope for something more rational / pleasant in the world of CMS's, together, e.g., with the adoption of HTMX type technologies. If your pages/documents are derived more or less from a standard schema in the backend then its is quite efficient to develop a corresponding structure of components on the frontend.

I think part of the issue stems from html being seen as the boring and needed stepping stone to the “fun stuff” and people writing it off as “not a programming language”

When people realise how much functionality you can get for free using semantic tags they get right on board and start seeing html as a tool rather than simply labels that some pedant insists can’t all just be divs.

I like this approach. It makes me wonder though, what about <i>, <em>, <dfn>, <cite>, etc.? They all look the same by default and as far as I know there is no UX advantage to using them properly. Do screen readers differentiate them? It doesn’t seem necessary for accessibility when sighted users can’t tell the difference either.

If you use `<i lang="la">sic transit gloria mundi</la>` then your screen reader should read the text in a Latin accent rather than munging whatever your default language is.

As for the rest, they look the same now. But HTML is supposed to be future proof.

Suppose, in the future, people prefer emphasised text to slant backwards, definitions to hover holographically, and cites to render directly to your neural link. Or, suppose right now you want to screen-scrape a page and get all the definitions.

That's why I use semantic HTML.

Screen readers should read those tags differently. em is emphasis, cite is citation etc.

In theory they could, in practice they don't because almost nobody writing those elements pays attention to that level of detail or use them solely for a visual styling effect that has no bearing on understanding the meaning of the content.

The semantics are indeed different in screen readers and the elements will be announced differently and behave differently in the accessibility tree (by virtue of having ARIA roles like e.g. "term"[0] or "definition"[1]). Note that ARIA roles change drastically how elements are announced -- a screen reader would take forever to announce elements if they were not scoped by their role because it would have to announce what an item is not (e.g. if it's unchecked, which is announced for "checkbox" roles, which can be and often are <span>s). ARIA roles make a bunch of ARIA attributes hidden (or, conversely, shown) in the accessibility tree.

It also gives context to additional ARIA attributes like aria-details[2] because now the screen reader knows that the details are the definition or whatever, and will announce those appropriately.

Using semantic elements allows you to have the proper ARIA roles (and thus the accessibility tree be properly scoped) without thinking too much or polluting your DOM tree with aria-* attributes.

There are also some other semantic-related benefits. E.g. from <dfn>'s MDN page[1] "if you include an id attribute on the <dfn> element, you can then link to it using <a> elements. Such links should be uses of the term, with the intent being that the reader can quickly navigate to the term's definition if they're not already aware of it, by clicking on the term's link."

I know you can already id-link to a simple <span>, but the thing is the screen reader would be able to announce that the link is to a definition so the user is already aware of the link purpose even before clicking it (unsure if any do this, but they could). Or maybe the user agent could build up a list of definitions automatically and allow you to quickly look up them, even if they are not explicitly linked.

Most importantly: you might think that sighted users cannot tell the difference between the default styling of all those elements, but they often can by virtue of what they are visually surrounded with and other contextual clues that are not available while using a screen reader. E.g. `<cite>` is often surrounded by other visual cues that might not be obvious to screen reader users which have a very local and narrow contextual scope (you can only hear elements one at a time, while visual users can see a bunch of context at a glance).

Also, sighted navigation is much faster than navigating via keyboard+narration so the additional affordances really help non-sighted users. Imagine having to wait for a whole paragraph to be narrated to get to some textual clue near the end of the paragraph, or even further down the content... or worse, above the current content (think an <h2>Definitions</h2> for example) which will normally not get visited while you navigate piecewise. It's very hard (impossible?) to read/navigate diagonally with a screen reader. We get so much instant info visually that we take for granted and it's just not there for screen reader users.

Lastly, you can style those differently in CSS even if the default user agent stylesheet does not. E.g., by giving <dfns> a dashed underline or a different mouse cursor. I know you can do that by manually annotating <span>s with classes but the thing is... you don't need to. So you can give additional visual affordances to sighted, but also to cognitively-impaired or partially-blind users too.

[0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/df...

There are many roles that exist that are not actually conveyed by screen readers. Either they're obscure and so seldom used that no one cares if the role is not supported, the content and context are sufficient, or they're overused/misused and having to listen to/read through all the roles would clutter up the content.

<dl> lists with their <dt> <dd> elements are fine to use but screen readers rarely convey their roles.

a11ysupport.io is not comprehensive and its volunteer data is not kept current but it still offers a sense of the divide between what's theoretically possible and what actually happens.

https://a11ysupport.io/tech/html/dt_element

I still don't understand why anyone would waste their time on this academic nonsense instead of building stuff for their actual users-- all you're doing is making yourself vulnerable to bots and scrapers if your content is worth anything

The whole "semantic HTML" debate really seems like the two-state solution of the web world. Browser vendors are profoundly uninterested in the whole topic. It could be relevant for search engines in theory - but in practice, the only remaining relevant engines (that happen to be identical to the browser vendors) use proprietary algorithms that deal with messy, un-semantic HTML just fine. (Or, if they have a specific need for semantics, they will just invent their own markup).

That leaves a long tail of "specialized" HTML consumers and usecases, such as screen readers, niche search engines, open source projects or scientific projects that actually would benefit from consistent, widely-used semantic HTML (to an extent), but don't have the market power to push the world in that direction.

However, those still have the "founding vision" of HTML on their side, that browsers rely on for their brand reputation. So browser vendors can't simply say out loud "look guys, you lost. HTML today is for showing stuff in a browser and running javascript and nothing else, deal with it".

The result seems to be that the "semantic" people get to claim the "moral" victory of how HTML "should" be. They are encouraged to spread their vision at countless web Dev conferences, under the enthusiastic support of the browser vendors - while they are doing absolutely zero to support that vision in actual browser implementations.

nothing has hindered me more in my learning of html than this moralistic tone about semantic html.

just do what ever works. non of this matters. its just talking points by people that wanted to stay relevant.

as soon as I started to ignore these kinds of people i suddenly became able to just make things.

TFA is the author switching from “moral scolding” over semantic tags to demonstrating their utility and letting them stand on their own merits. Give it a read, I think you’ll find yourself agreeing with it more than not. And if you still want to write div soup after, just sprinkle some role attributes around where appropriate and you should be good to go.

> And if you still want to write div soup after,

thanks for the baseless assumptions about me with moralistic undertone

spent 5 more minutes on this yapper. no code examples btw. just one long effort post full of yapping.

I should write an article on the "UX of yapping" - at least include some images or code samples.

crazy to think that anybody who does not care about "semantic html" clowns only ever uses divs.

I probably write more "semantic html" just by accident. no i am not going to sprinkle useless attributes into my code. I am good to go already.

It wasn’t personal, sorry to have triggered you.

Semantic HTML made sense in the early 1990s where it was intended for formatting static academic literature. It hasn’t made sense since about 1998 however, but unfortunately no new paradigms have emerged to allow creators to express emergent state web apps, which is almost the entirety of content created for the web for the past 25 years. This means we’re simply we’re simply trying to squeeze a square peg into a round hole.

Semantic HTML is the wrong paradigm entirely.

this is so true. especially now with llms.

people still riding this horse are yapping yapping fr fr no cap

Reply on news.ycombinator.com