The UX of HTML (2023)

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.

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.

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.

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.

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

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.

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.

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.

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.