The practical value of semantic HTML
Bruce’s guide to writing HTML for JavaScript developers
It has come to my attention that many in the web standards gang are feeling grumpy about some Full Stack Developers’ lack of deep knowledge about HTML. One well-intentioned article about 10 things to learn for becoming a solid full-stack JavaScript developer said
As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like <span> and how they differ from block ones like <div>. This will save you a huge amount of headache when fiddling with your CSS code.
This riled me too. But, as it’s Consumerfest and goodwill to all is compulsory, I calmed down. And I don’t want to instigate a pile-on of the author of this piece; it’s indicative of an industry trend to regard HTML as a bit of an afterthought, once you’ve done the real work of learning and writing JavaScript. If the importance of good HTML isn’t well-understood by the newer breed of JavaScript developers, then it’s my job as a DOWF (Dull Old Web Fart) to explain it.
Gather round, Fullstack JavaScript Developers – together we’ll make your apps more usable, and my blood pressure lower.
What is ‘good’ HTML?
Firstly, let’s reach a definition of ‘good’ HTML. Many DOWFs used to get very irked about (X)HTML being well-formed: proper closing tags, quoted attributes and the like. Those days are gone. Sure, it’s good practice to validate your HTML, just like you lint your JavaScript (it can catch errors and make your code more maintainable), but browsers are very forgiving.
In fact, part of what we commonly call ‘HTML5’ is the Parsing Algorithm which is like an HTML ninja – incredibly powerful, yet rarely noticed. It ensures that all modern browsers construct the same DOM from the same HTML, regardless of whether the HTML is well-formed or not. It’s the greatest fillip to interoperability we’ve ever seen.
By ‘good’ HTML, I mean semantic HTML, a posh term for choosing the right HTML element for the content. This isn’t a philosophical exercise; it has directly observable practical benefits.
For example, consider the <button> element. Using this gives you some browser behaviour for free:
- A button is focusssable via the keyboard. I bet you, dear reader, know all the keyboard shortcuts for your IDE; it makes development much faster. Many people use only the keyboard when using a webpage. I do it because I have multiple sclerosis – therefore the fine motor control required to use a mouse can be difficult for me. My neighbour has arthritis, so she prefers to use the keyboard.
- Buttons can be activated using the space bar or the enter key; you don’t have to remember to listen for these keypresses in your script.
- Inside a <form>, it doesn’t even need JavaScript to work.
“What’s that?”, you say. “Everyone has JavaScript”. No, they don’t. Most people do, most of the time. But I guarantee you that everyone is without JavaScript sometimes.
Here’s another example: semantically linking a <label> to its associated <input> increases usability for a mouse-user or touch-screen user, because clicking in the label focusses into the input field. See this in action (and how to do it) on MDN.
This might be me, with my MS; it might be you, on a touch-screen device on a bumpy train, trying to check a checkbox. How much easier it is if the hit area also includes the label “uncheck to opt out of cancelling us not sending you spam forever”. (Compare the first and second identical-looking examples in a checkbox demo.)
But the point is that by choosing the right element for the job, you’re getting browser behaviour for free that makes your app more usable to a range of different people.
Invisible browser behaviours
With me so far? Good. The browser behaviours associated with the semantics of <button> and <label> are obvious once you know about them – because you can see them.
Other semantics aren’t so obvious to a sighted developer with a desktop machine and a nice big monitor, but they are incredibly useful for those who do need them. Let’s look at some of those.
HTML5 has some semantics that you can use for indicating regions on a page. For example, <nav>, <main>, <header>, <footer>.
If you wrap your main content – that is, the stuff that isn’t navigation, logo and main header etc – in a <main> tag, a screen reader user can jump immediately to it using a keyboard shortcut. Imagine how useful that is – they don’t have to listen to all the content before it, or tab through it to get to the main meat of your page.
And for people who don’t use a screenreader, that <main> element doesn’t get in the way. It has no default styling at all, so there’s nothing for you to remove. For those that need it, it simply works; for those that don’t need it, it’s entirely transparent.
Similarly, using <nav> for your primary navigation provides screenreader users with a shortcut key to jump to the navigation so they can continue exploring your marvellous site. You were probably going to wrap your navigation in a <div class=”nav”> to position it and style it; why not choose <nav> instead (it’s shorter!) and make your site more usable to the 15% of the world who have a disability?
For more on this, I humbly point you to my 2014 post Should you use HTML5 header and footer?. A survey of screenreader users last year showed that 80% of respondents will use regions to navigate – but they can only do so if you choose to use them instead of wrapping everything in <div>s. Now you know they exist, why wouldn’t you use them?
Update: here’s a YouTube video of blind screenreader user Leonie Watson talking through how she navigates this site using the HTML semantics we’ve discussed.

New types of devices
We’re seeing more and more types of devices connecting to the web, and semantic HTML can help these devices display your content in a more usable way to their owners. And if your site is more usable than your competitors’, you win, and your boss will erect a massive gold statue of you in the office car park. (Trust me, your boss told me. They’ve already ordered the plinth.)
Let’s look at one example, the Apple Watch. Here are some screenshots and excerpts from the transcript of an Apple video introducing watchOS 5:
We’ve brought Reader to watchOS 5 where it automatically activates when following links to text heavy web pages. It’s important to ensure that Reader draws out the key parts of your web page by using semantic markup to reinforce the meaning and purpose of elements in the document. Let’s walk through an example. First, we indicate which parts of the page are the most important by wrapping it in an article tag.
Specifically, enclosing these header elements inside the article ensure that they all appear in Reader. Reader also styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.
itemprop
is an HTML5 microdata attribute. There are shared vocabularies documented at schema.org, which is founded by Google, Microsoft, Yahoo and Yandex. Using schema.org vocabularies with microdata can make your pages display better in search results:
Many applications from Google, Microsoft, Pinterest, Yandex and others already use these vocabularies to power rich, extensible experiences.
Update: Google published numbers on how using structured data boosts conversions.
(If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.)
Apple WatchOS also optimises display of items wrapped in <figure> elements:
Reader recognizes these tags and preserves their semantic styles. For this image, we use figure and figcaption elements to let the Reader know that the image is associated with the below caption. Reader then positions the image alongside its caption.
You probably know that HTML5 greatly increased the number of different <input> types, for example <input type=”email”> on a mobile device shows a keyboard with the “@” symbol and “.” that are in all email addresses; <input type=”tel”> on a mobile device shows a numeric keypad.
On desktop browsers, where you have a physical keyboard, you may get different User Interface benefits, or built-in validation. You don’t need to build any of this; you simply choose the right semantic that best expresses the meaning of your content, and the browser will choose the best display, depending on the device it’s on.
In WatchOS, input types take up the whole watch screen, so choosing the correct one is highly desirable.
First, choose the appropriate type attribute and element tag for your form controls.
WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.Secondly, it’s important to note that unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.
I didn’t choose to use <article> and itemprop
and input types because I wanted to support the Apple Watch; I did it before the Apple Watch existed, in order that my code is future-proof. By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users. You are opting out of this if you only use <div> or <span> because, by definition, they have “no special meaning at all”.
Summary
I hope I’ve shown you that choosing the correct HTML isn’t purely an academic exercise. Perhaps you can’t use all the above (and there’s much more that I haven’t discussed) but when you can, please consider whether there’s an HTML element that you could use to describe parts of your content.
For instance, when building components that emit banners and logos, consider wrapping them in <header> rather than <div>. If your styling relies upon classnames, <header class=”header”> will work just as well as <div class=”header”>.
Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.
And, best of all, thinking more about your HTML will stop Dull Old Web Farts like me moaning at you.
What’s not to love? Have a splendid holiday season, whatever you celebrate – and here’s to a semantic 2019!
More!
- How to Learn CSS – Rachel Andrew’s on the core concepts of CSS that will help you work with CSS, rather than against it.
- Understanding Semantics by Léonie Watson, a screenreader user
- Building websites for Safari Reader Mode and other reading apps
- I Used The Web For A Day With Just A Keyboard
- I Used The Web For A Day Using A Screen Reader
- Styling buttons, the right way – using <div> instead of <button> because it’s easier to style? This will help.
- Related: It’s more important to load fast than to code fast by Estelle Weyl
(Last Updated on )
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
20 Responses to “ The practical value of semantic HTML ”
Thanks Bruce. Do you have any good books or just ONE article you would recommend for understanding how to structure a page? From a landing page, to index pages, to detail pages like a blog post?
@HMCB
This is a good book to use and it is not a big, voluminous tome:
https://html5forwebdesigners.com/ by Jeremy Keith
excellent reminder to all
It’s all to easy to become complacent or simply forget about the huge array of semantic assistance we already have cooked-in.
A worthy read for any frontender!
@Bridget, thank you! Will pick this up this weekend.
Trying to see the semantic HTML5 structure of a page was often extremely difficult when trying to sort out my clients’ often over-complicated markup so I made this tool to visualise it. It saves a lot of time and is free access : Semantic HTML5 structure viewer. Have fun with it !
And this is a good article over at SEMrush for starting out The Secrets of Semantic HTML5 for Document Structure — a Guide.
Thanks Bruce for the great article – I know that semantic HTML has been preached pretty much since the turn of the century but this drives home all the extra more modern benefits for taking the time to Do It Right.
@bruce, thanks for the offer. I’m going to pick up the book @bridget selected so I think I’ll be ok. But again thanks for the informative article. I’ve been disappointed in myself for letting semantics slide. I’ve been developing for over close to 20 years and am really perplexed at the state of web development. How complicated things have gotten. I just read an article last week on the security concerns of the dependencies around NPM / Node / frameworks. 1,700 dependencies before the build, in one instance. At the end of the day, I look back on the sites I’ve built and the ones with staying power focused on the fundamentals.
So when using nav element, would you use nav as the actual wrapper for a whole top menu or just the container for the link?
Hi Bruce, don’t forget that it will help your website’s SEO as well. Google and other search engines will rank your site higher when you use semantic HTML.
Thanks, Bruce. Going to be showing this and the many examples to students I’m teaching this semester.
This is important. I’m also a “dull old fart” and I likewise believe it’s necessary now that we explain semantic HTML. Very necessary. Yet I find this is actually also tricky because most explanations for “semantic HTML” are poor. My view. I know few articles that explain at least a little what semantics actually means (the ones you attach are good but I like this one because it explains what semantics really is). Even there we probably need updates. Perhaps you (or CSS tricks who recommended this post) can pull something out of their sleeves. It may help much.
Started learning HTML in 1998. I am STILL seeing new websites using things like DIV and P elements where they should be using H1 – H6 elements. If I talk about anymore HTML atrocities I’ve seen I’ll get really sad.
Bruce, this was very insightful. I have never thought about how the sites would be for the people with disability or issues. I will keep these factors and the tips in mind now! Thank you very much for this article.
– Shubham
@Bruce You might want to skip the “list” elements altogether in your navigation menu, because the `nav` element already implies the listing (semantically), and some screen readers make it more user-friendly to read a bunch of links than a list.
Thanks for the article!
As a primarily-backend developer who has been doing frontend for a couple years and has found a lot of it confusing (family-guy-venetian-blinds.gif), I found this a compelling and useful read and I really appreciate the links at the bottom. I’ll also take a look at the Jeremy Keith book you recommended.
I found this link enlightening https://components.guide/accessibility-first
Easy to read, with great specific examples.
The practical examples of how this is used by devices really helped me out. Thanks for this