For all those saying that ARIA trumps semantic elements, consider that for basic interactions semantic elements come out of the box keyboard accessible.<p>For example, a <button> will have default tabindex=0 and respond to spacebar key presses, but you'd have to add that yourself if you put role=button on a <div>.<p>In short, if there is a semantic element that matches your need, use it.
I think HTML is considered too challenging or 'low level' in modern front end development. Components are created with material UI, or bootstrap. No one seems to be doing it by hand.<p>I like coding html (and css) by hand. I find it easier to do that than to deal with frameworks and tooling. So I read articles like this and often find something new (TIL about fieldset). But I've yet to see anyone else do this professionally.<p>So I don't think most people will ever care about this stuff, in the face of modern "best practices". It's just going to be nested div soup, from here on out.
I don't need to be convinced of the benefits of semantic HTML anymore. It's been made clear in numerous similar articles. What I would like to see are examples that are not trivial news/blog type apps.
Oddly enough, I think semantic HTML might be more important for React developers than anyone else. React developers are very vulnerable to creating copious amount of abstract components due to the freedom composability gives you. Over time, it’s possible different people literally speak different languages (even in the same codebase) because of how they see the structure of tags.<p>Thinking in Semantic HTML might help normalize the variances.
The better control I have over styling the more empowered I feel to use semantic HTML. It was frustrating, years ago, to jump on board wide eyed only to realize that styling is a minefield. I believe this is much improved today.
The demonstration is neat and the advice is sound.<p>One thing that rarely gets mentioned however is that well structured HTML, including templates and JSX, is easier to develop with.<p>Semantic tags at least give you common consistency for free. Adhering to some reasonable degree of consistency is the bare minimum we should aim for in respect to code readability.
I wish there was a way to tell the browser to add more default styles to my document. For example we have reader mode but this completely munges your document and kills all custom styles and scripts. It would be cool if you could tell the browser to apply a nice pretty style (customizable by the user of course) but then possibly opt out small sections of the page (like an interactive example) where you could add custom scrips and styles.<p>Obviously this works best with simple "document" websites but it always seems so weird telling the browser how to style the document when I know very little about the user or the device. It is getting "better" in a way with media queries for information about the device and user preference (like dark/light colour scheme) but it still is relying on each site to interpret those settings themselves, and progress is slow because everything needs to be standardized.<p>This also opens the door to a "clean" mode with no default borders, margins, padding, sizes, styles which would help when making interfaces where you want to control every pixel and don't want to be surprised in differences in default browser style sheets.
Instead of using special tags to convey meaning, couldn't we just use special attributes? say, a div tag with an 'aria-role' attribute set to menu would indicate a menu, a div tag with an 'aria-role' attribute set to 'checkbox' would indicate a checkbox etc.<p>That would make creation of visual elements more versatile, keep the number of hacks to minimum (like the hidden input trick for checkboxes), and also make ARIA possible.
Here's Google's test page for "canvas rendering".[1]<p>Try that with a screen reader.<p>[1] <a href="https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview" rel="nofollow">https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...</a>
Most of the heavy lifting in accessibility is in the ARIA attributes and being thoughtful about actually including those. The problem faced by semantic tags is that not all websites use them and that the information that they carry is of very limited use for a screen reader. A section-element without any other information is just a div.<p>Unfortunately adding semantic information to website has gone from a promising avenue for building websites usable from many different kinds to part of the SEO cat-and-mouse game played by Google et al.<p>Unless you're doing SEO, everything semantic is just a distraction. That said do take accessibility seriously, it will never be justified by profits but doing the right thing is a feeling no amount of money can buy.
An article like this, comes up every few months. They tend to give an intro to the technical how-to but miss the step of convincing the readers that supporting screen readers is desirable.<p>Ok sure, it'd be _nice_ if blind people could navigate my website. But... how nice? How many screenreaders can I reasonably expect as a % of traffic? What difference will it make to their quality of life? What decision process should I use to decide if _my_ website needs to support this? Does my personal blog to support a screen reader? What about this bank login page? This motivating information is a cruicual step in actually getting people to care enough to do something different.<p>A contrasting example is the discourse on "bloated" webpages being slow and hard to use on shitty old phones. The upshot is that if your website needs to download and run 1MB of JavaScript then someone viewing it on a 5 year old low cost smartphone on a crappy 3G is going to have a bad time. The statistics around how many people have bad internet motivated me to try and reduce download sizes.<p>It would also be nice to have a guide on convincing your boss to give you time to support accessibility.<p>The technical details are good (and this article is quite readable) but probably aren't the key bottleneck in more people writing accessible markup.<p><edited for less unnecessary snark>
I don't see any reason to use semantic HTML. It's cargo cult.<p>At some point web designers (at the time in the early 00s web development was not as involved as it has been post Ajax) learned the term "semantic" and went wild with it (made you sound smart, and you could charge a little more than the unsophisticated shop down the road), without understanding the science behind data.<p>Instead we should have separation of concerns, with structured raw information (you know, like what we have in our relational and document databases), served with different represenations: for accessibility, for data access, for web, for syndication, for print, for reading devices, and so on.<p>Of course the web being the web, it needed to make this too in the most inefficient and multi-layered way (and leave it up to the web designers/devs to have "proper" semantic tags).
CTRL+F "microdata": no result. Yeah, I thought so too...<p>The Semantic web has failed. ARIA tags are important for accessibility though, but semantic HTML has been irrelevant for a decade, I haven't seen a single successful product based on that or a single use case that yielded something interesting SEO wise.