Written by Kristofer Selbekk✏️
On any given website, there’s a lot of implicit meaning that’s easy for some users to interpret. There are a lot of visual clues and hints on sites. Text that’s larger than usual is typically headings, the navigation menu looks a certain way, and a magnifying glass icon tends to signify a search feature.
Without these visual clues, most of these implicit relationships disappear. We can have somebody (or something) read us the content – but all the small visual cues that helped us understand emphasis, paragraphs, and general content structure will be lost.
Want proof of concept? Go to the website you’re working on now, click
ctrl+a to copy “everything”, and paste the text into your favorite text editor. Welcome to the world of no semantics.
Luckily, the web can portray much more meaning than this. This article will show you why semantics on the web is important, what kind of semantic elements are built into HTML, and how you can use them in your apps to improve accessibility, availability, SEO and profits.
As far as words go, “semantics” is a tricky one. It’s plural but singular, and it means “the meaning of words”. On the web, semantics typically refer to the intrinsic meaning provided by HTML elements.
On web pages that are semantically built, these HTML elements are used to place its content into some kind of structure. Some content should take the center stage, while other content is more peripheral in nature. Some content should be emphasized, while other content should be presented as a quote. HTML provides tools for all of these types of content, and tons more.
Content that’s structured this way (we’ll call it the “semantically correct” way) is easier to consume and process for everyone interested. That brings with it a few great advantages:
By using the correct semantic markup to structure your content, you’ll make it much easier to consume by all users. Screen readers will be able to present the content in the most efficient way possible and will allow its users to navigate your site much faster than they would without semantic markup.
Search engine crawlers have a much easier time indexing your content correctly with semantic markup. By using the correct tags, you’ll provide valuable hints to the underlying sorting algorithms that decide how easy your content will be to find. And since semantic markup is better for accessibility, you’ll get an extra boost in the ratings, too! 💪
Screen readers and crawlers might not be the two only programs interested in your content. There are price aggregators, reading list apps, sharing features and probably a thousand more ways your content can be consumed, and making that process as easy as possible will only gain you readers.
Reading through source code that’s all
<div />s is not a great experience. Luckily for us, HTML is so much more than the generic
<div /> and
<span /> tags! You can place navigation specific content in a
<nav />, your main content section inside of a
<main /> tag, and suddenly your code is much easier to scan. This might not be adding end-user value – but a happy developer is a productive one, right?
As I mentioned, HTML is much more than
<div />s and
<span />. In fact, there are over 100 different elements! You can check all of them out in the MDN reference, but they can be roughly grouped into three groups – content sectioning, content semantics, and functional elements.
A web page typically contains a few sections of content – a header, a footer, a main content area, and so on. HTML provides a few elements that will let you denote these different “landmarks” of a page.
Some of the ones you should remember are these:
<main />wraps the actual content of your page, or the main functionality of your app. Simply put, it’s your web site without the header, footer, and sidebar
<header />should wrap the main header of your page or app, but also the “head” of any other groups of content. It could contain the heading and content category of a blog post, or your app’s logo and main navigation
<section />is a generic content container which should wrap a section of your site or app. These elements typically have a heading, too. A good rule of thumb is that a section should logically appear in the outline of your website
<article />is almost similar to a
<section />. The main difference is that you should use
<article />tags around content that could be separately reused in another context, and not around the main content. Examples could be blog post summaries, a comment or even a complete widget
<aside />can be used in two different ways. If you use it inside an
<article />tag, it’s understood to contain content that closely relates to that article, like a glossary or an explanation box. If it’s used outside of an article, it can be used to wrap semi-related content, like a sidebar or a list of related links
<footer />is typically used to provide copyright or author information for an article or the website itself
<nav />wraps your page’s main navigation sections. Your main site navigation, pagination, and next post / previous post features should all be wrapped in a
By remembering these seven elements and when to use them, you can provide lots of structure to your website. You can read more about structuring content in general in this article if you’re interested.
There’s another group of HTML tags that lets you structure the actual content of your site, and I’m calling it “content semantics”. This group of elements let you add semantic meaning to your content itself, making it possible to discern quotes and image captions from regular text.
There are a lot of these, and if you’ve used HTML at all, you’re probably familiar with most of them. Here are a few you might not have used a lot, but are great to know about!
<blockquote />wraps extended quotes and lets you cite the source of those quotes. If the source is a URL, you can use the
citeattribute, otherwise, you can use the
<cite />tag to provide the source of the origin
<figure />should wrap your images, illustrations, and figures (i.e. charts, code snippets). By providing a
<figcaption />as well, you can add a caption that’s semantically related to the figure
<dl />stands for “definition list”, and is great for whenever you need to display a key-value relationship. Product metadata and glossaries are great examples of this
The ones above all wrap a block of content. You can (and should!) get even more granular, and provide further semantic meaning to each of these blocks though.
<time />wraps a specific period or place in time. You can specify it further with the
datetimeattribute, which accepts a more detailed timestamp
<em />creates emphasis, which is great for when you’re using a screen reader or a voice assistant to parse your text. You can even nest them to provide an added level of emphasis if needed
<small />wraps your “legal text” and copyright notices
<abbr />is for explaining the abbreviations you use. It’s weird that the
abbrtag itself is an abbreviation for “abbreviation”, but let’s leave it. You can explain the abbreviation with the
There are indeed a few more to look at for the extremely interested. You can find a complete list here.
The semantic web is so much more than a buzzword. By using the appropriate HTML tags, you can provide structural hints to screen readers, search crawlers and all users alike.
If you don’t remember when to use what, look it up a few times. The MDN docs are incredible, and this article outlines the ones you’ll use the most. Try to see how long you can survive without using a
<div /> or
<span /> in that new landing page you’re putting together!
I hope this article will inspire you to add some meaning to your document structure and let you dive into this wonderful language called HTML.
Editor's note: Seeing something wrong with this post? You can find the correct version here.
Plug: LogRocket, a DVR for web apps
LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.
Try it for free.