It's neat, but during my dabbling in web dev I've noticed that you can use basically <whatever>...</whatever> instead of divs, spans, sections, and it still mostly just works.
Aside from the spec wanting you to provide a schema, this is pretty much what xhtml aimed to do. The idea was that you could make the tags describe the content in them, and not have to rely on what's built into a common spec.
HTML is and always was very error tolerant though.
Its not simply styling, it goes beyond that. XML was/still intended to be the equivalent of JSON - just the data. With XSLT you created entirely new structure based on the underlying XML.
You don't have to do it that way. You can embed arbitrary foreign (but appropriately namespaced) XML into an XHTML document and style it with CSS, untransformed. Or, as the sibling comment says, you can even avoid XHTML and style pure XML directly.
Aria should be the source of truth, the list of things is much simpler and straight forward than html tags. They ARE made for accessibility and accessibility only, unlike html which at worst treat accessibility as an after thought and at best just another overloaded function of the mark up.
Even the Aria docs say you should rely on semantics and only use Aria for when that's not possible...
I'd much rather use a <button> that exposes itself as such and has well known interaction functions, then create my own div and have to handle the clicks, keyboard navigation, navigation shortcuts and so on... That actually requires a lot more knowledge than HTML semantics, and unless you test frequently with expert and non-expert assistive tech users, you won't know what kind of UX issues you'll be creating for them...
> They ARE made for accessibility and accessibility only
Sure, but have you ever used a screen reader? Support for aira markup is often limited and if you confuse things with semantically muddled HTML you're almost guaranteed to degrade accessibility.
The more basic and "standard" you can keep your HTML the less likely users using assistive technology will run into problems.
Aria is great, especially the basic stuff like aria-label, but where you can avoid using it you should.
I've worked on accessibility projects for years, treating aria as a source of truth or something that can be relied on isn't a good idea. We might get there eventually, but we're not there today.
Someone says “accessibility software is brittle” and your response is based on a “should”?
Great. Another developer that sees accessibility as another specs compliance fetishism exercise instead of actually being way to make things easier to use for more people.
specs compliance fetishism would be semantic web. The reason so much has been written on it is that it's so messy and practically people never get it right. HTML is so overloaded for multiple functions (content, logic, presentation and now accessibility), so is it really a surprise that it sucks at all of these?
Just my personal experience: If anyone remembers how hard it was to make things render consistently across IE and Netscape, the current situation with different screen readers is 1000x harder.
I mainly test with NVDA on the latest Firefox ESR on Windows 10. Something always breaks if I upgrade any part of this chain in my testing VM. Few months ago I spent many days to make abbreviations in a table header to be read correctly. I tried the abbr tag, abbr attribute, aria-label and many other possibilities and found a super hacky solution that involves hiding the expanded form with some css while exposing it to the screen reader. Then sometime after that I updated the Firefox. At the same day a colleague questioned why we needed all these hacks, and I wanted to show her how broken it was without my hack, but voila it had started working with the non-hacky, semantic way.
I have many stories like this.
I also do test with other configurations but just before releasing. VoiceOver (mac) is 80% there. JAWS Inspect is giving some colleagues headaches. None work 100% without breaking others, so the most popular stack decides how we implement things.
When I saw this post, I thought perhaps doing everything with spans and adding necessary attributes like role would be easier. Well nobody is passing something like that through a code review :)
I am pretty sure in the end accessibility will more likely be solved by some smart LLMs (with vision) interpreting arbitrary web pages on the user side, rather than by web developers coding it by hand. Because the latter obviously doesn't universally work.
I would pay money for a browser plugin that restyles every web page to a single readable/accessible design that I like. Think "Reader Mode" on steroids (that could transform arbitrary GUIs, not just blog posts).
As much as I work painstakingly to implement highly intentional design systems… the browser should be your “user agent.” If it can agentically interpret semi-structured data to help you, it’s entirely the user’s right to have the browser do that for them.
You can even make up your own tags, according to specific criteria, and they will been seen as spans.
Eg:
<my-dalek>EX-TER-MIN-ATE</my-dalek>
You can style them, including setting them as block level elements.
Where it can make life a lot easier is when you have a large number of nested divs. If you give the div's distinct names, it makes debugging/editing the source easier, which is probably required if you have that many divs.
Yes you can do that and it will work. But for future-proofing you should use tag names with a dash in them (like <foo-whatever>) to avoid colissions if html adds an official <whatever> element in the future. (The html standard promises to never add an element with a dash in its name)
Tag names with at least one hypen and two words either side are reserved for custom element use... with a few exceptions that I assume were part of the HTML/svg/mathml spec before the custom element registry.
You can 100% do this, invent your own tags, no need for React to have custom component names. And it works for styling with CSS, just use your custom tag as selector instead of css class. And then the classes can be used for shared styles.
Browsers have always been lenient towards errors in markup. Unknown elements would just be rendered as <p> or <span> (can't remember which).
Much later this was codified in HTML 5: if a browser doesn't know an element, it will render it as basically a span (that is, inline element with default styling IIRC).
And if you're lucky, your `<whatever>` might even get upgraded from "you're using the wrong tag for that purpose" to "now your tag is mostly correct" <i class="icon-cough"></i>.
I think that is both the basic point of and minimizes the interesting point of the website - the actual element doesn't matter, it's the things you can do with them.
Yeah, you could replace every single span on this page with almost any other HTML element and it'd work fine. But I guess onlylists or onlyh1s or onlybolds doesn't quite roll off the tongue as well.
It has role and aria attributes, so I think it actually isn't that bad. It's just `<span role="heading" aria-level="3">` is an awfully long way to spell out `<h3>`.
Screen readers are basically everything you hated about developing for IE6, but in an alternate world where there are 3 different IE6’s each of which works completely differently.
Three? Definition lists are read completely differently in Firefox, Edge, or Edge-in-IE-mode in Windows 11 Narrator. Multiply JAWS, NVDA, Narrator, VoiceOver, Orca, ChromeVox by Firefox, Chromium, IE, WebKit, Opera Mini. (Some of those combinations aren't possible, but 20 isn't an overestimate.)
Then realise: it's not just screenreaders. It's Braille displays, sip-and-puffs, Magnifier, High Contrast mode, keyboard navigation, speech recognition… Seemingly nobody tested any of it before they gave it to the end-user, so now it's your job, as the web developer, to make something that works.
Good luck! I recommend settling for "doesn't make it worse", since that's almost achievable.
I don't really know much about this area of UI. Can you explain why this breaks accessibility? I did load it in reader mode (macOS Safari), and there were no paragraph breaks - is that similar to the experience of a screen reader?
Screen readers know how to deal with common page elements. So they know how to announce and interact with page breaks, headers, lists, buttons, links etc.
If everything is a span, everything becomes just text.
It doesn't only apply to screen readers. Regular actions like keyboard navigation becomes broken. For example, on the page, you cannot tab between "click to expand" "buttons".
Indeed. Good accessibility benefits everyone, even the non-disabled people. And that's even before we start the whole discussion on how everyone will be disabled at one point or another in their lives and so on :)
Yeah, it' a sad state of things. Since there's no real money in screen readers, no one invests enough to make them better (e.g. to work with highly dynamic interfaces). Since they don't work in a lot of situations, people are disinclined to implement features that don't work well with screen readers. It's almost an impasse
This is basically what was happening late 90s and early 2000s, except with the div. ARIA didn't exist at the time so this presented a major accessibility issue. We now have ARIA, but the "use the right element" cargo cult persists [there's nothing wrong with this cargo cult - it just fits the definition, CSSing it up is just as functional sans older and possibly text browsers].
Edit: it's also where table got a bad rap (for a while table wasn't even used for tables, it was completely taboo). Using table for layout completely wrecked accessibility.
I don’t think it fits the definition of a cargo cult. It’s about convenience. I can use a <header /> and the screen reader announces it as such. I could do that with ARIA, but why put in the extra effort? To use a more gross example, I could make a div into a text input or even a form with contenteditable, a bunch of CSS I’d otherwise get out of the box, and a lot of JS. Yet it would require much more work.
The only thing I’ll grant you is that my first example’s benefit is a marginal difference, but there is a benefit nonetheless. It was also probably pushed as much for the screen reader benefit as it was for the ability to parse and extract information if I’m feeling cynical, but I digress.
Yeah, it was a big learning moment for me as a web developer when I learned that elements could be reshaped to function however you wanted, and none of their intrinsic properties were set in stone aside from content categories.
