What is semantic HTML?
Semantic HTML forms the building blocks of the web. They are the correct ingredients to make a cake. It’s the difference between putting 4 cups of flour into a bowl or putting flour, butter, sugar, and eggs into a bowl. One of those makes a cake (or in our case, a website), and the other makes a bowl of flour (also known as a mess)! So how can we make sure our sites are lovely cakes, not messes?
Building an accessible website
One of the main discussion points about building an accessible website is that ‘it takes so much time to do!’. In many cases, that’s just not true. A large number of web pages can be made accessible just by making sure that the correct HTML elements are used for their correct purpose throughout the site. This takes much less time than trying to fix non-semantic markup later on.
One of the first things you learn when you start coding is the different semantic elements that HTML has to offer, and when to use them. As HTML forms the building blocks of the web, it’s incredibly difficult to learn to code without learning HTML first. CSS styles the HTML, JavaScript manipulates the HTML, and Python and other backend languages deal with the data that populates into the HTML.
Semantic HTML is sometimes referred to as POSH – Plain Old Semantic HTML, a term coined in 2007. POSH content means using semantic HTML wherever possible, instead of defining structure using CSS or ARIA. It also extends beyond the basics of semantic HTML, focusing on the mindset of coding. It teaches that HTML markup shouldn’t be used for presentational purposes. For instance, tables should only present data that genuinely belongs inside a table, rather than for an aesthetic purpose. Class names and ids should be named for their purpose, not their visuals (i.e. ‘submit-button’ instead of ‘red-button’).
Why should we use it?
So why is HTML important, when we have all these other languages to manipulate code for us? We can put in a div, use CSS to style it to look like a button, and use JavaScript to add an onclick. Functionally, it’s a button. Except it isn’t – it’s a styled, manipulated div. HTML elements have some styling and functionality applied by default. Some of this is regularly overwritten by CSS resets, but other things are necessary, such as built-in keyboard functionality.
For a button, a semantic HTML button element allows the user to navigate to and from it using the Tab key, and they can ‘press’ the button using the Enter key. Suddenly, our div button is lacking the functionality that users with accessibility requirements need. We could add that functionality in with Javascript, but now we’re working with at least 10 lines of Javascript, plus the original HTML, which is completely unnecessary when we could just use a button element. We don’t need to reinvent the wheel, we just need to use it.
A Web for All
Using semantic HTML gives everyone and everything, regardless of visual capacity, the ability to use the web. Not all users can perceive visual content, which means that some users won’t get the same experience from visual-first content.
For visually impaired users, using semantic HTML means that their screen reader, braille display, or other assistive technology can infer information about the website content from the element that it’s inside. Semantic HTML provides information about the structure of a web page to assistive technologies, which allows those technologies to enhance the user’s experience, making it easier for a user to navigate and use your site.
Google and Bing’s bots are blind, so using semantic HTML is a massive SEO win! They give importance to keywords in semantic HTML than keywords in non-semantic elements like divs, making your site more findable on search engines.
We can also consider the ease of writing and validating our code. HTML semantic elements are a simpler approach, as every developer will have some experience with HTML.
WAI-ARIA
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) can be used to give semantic definitions for content, and most assistive technologies support ARIA. This allows the addition of the role attribute, among other things. However, the W3C’s first rule of ARIA is simple:
“If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.”
To add to this, not all older assistive technologies will correctly identify certain ARIA roles, meaning that there can be some confusion and miscommunication due to using ARIA. Semantic HTML, however, is supported by all web browsers and assistive technologies.
Let’s take a look at a list of the most common semantic HTML elements, and how they should be used.
| Element | Use |
| <title> | The title that displays in the tabs at the top of your browser. This should match your <h1> |
| <header> | The header of your page or section, containing your <h1> and <nav> |
| <footer> | The footer of your page or section, containing things like copyright and contact information |
| <nav> | Contains your main navigation – not every link on your site, just the main chunk |
| <h1> – <h6> | Your headings. They should be sequential. Don’t jump from <h1> to <h4>, then back to <h3>. If you need different sized headers, change the size with CSS, but keep the semantic HTML in the correct order |
| <main> | Main content |
| <button> | A clickable button, to affect the page, not a link |
| <a> | A link to take you to another page, not a button |
| <aside> | Consists of content that is tangentially related to the content around the element but is considered separate. This is often used on news websites. |
| <img> | Represents an image, provided by the src attribute. The alt attribute should be included to show the image’s fallback content if the image doesn’t load, or if the user is visually impaired. |
| <hr> | Often referred to as a horizontal rule, this is a paragraph-level thematic break. It should only be used in between blocks of text, to convey the end of one section, and the beginning of another. |
| <li> | An item inside a list, whether that be a <ul>, <ol>, or <menu> |
The tricky elements
Here are a few tricky elements that people often get wrong and a few elements that many people haven’t heard of.
| Elements | Use |
| <b> vs <strong> | These aren’t just for making text bold. Semantically, <b> is for drawing the reader’s attention to the element’s contents, although there is usually a better way of conveying this. <strong> means it should be rendered in a way that the user understands as important. If you want bold text with no semantics, use CSS styling. |
| <i> vs <em> | <em> provides emphasised text, and <i> provides a part of text in an alternate voice or mood. If you want italicised text without these semantics, use CSS styling. |
| <section> vs <article> | <article> should be used where, if you removed that section of HTML from your site, and viewed it somewhere else, it would still make logical sense. <section> is the semantic catch-all for sectioning. It’s better than using a <div>, but it can give less meaning than other semantic HTML. If you’re using a <section> or <article>, you must always have an <h1> – <h6> inside it. |
| <br> | Whilst this is commonly used for any line break, it should only be used for line breaks that form part of the content, such as in addresses, or poems. |
| <noscript> | Will not display if scripting is enabled, but will display its children if scripting is disabled. This can be used if your site requires Javascript to work, allowing something to display to inform the user that they need to enable scripting to use the site. |
| <address> | Represents the contact information for the section that it’s in. If it’s a child of the body, it applies to the whole document. |
| <abbr> | An abbreviation, such as HTML. The title attribute can be added to show an explanation of what the abbreviation stands for. |
| <time> | Represents a precise date and / or time. |
Proper use of HTML5 semantic elements will allow screen readers to more accurately communicate your content by making the visual audible. However, not every developer has the luxury of starting a project from scratch. You may need to work with legacy code or markup generated by a server-side framework that you don’t have control over. An easy way to check the basics of your site’s semantic HTML is by running it through an HTML validator. While this won’t pick up the use of extraneous divs, it will flag when you’re using an element incorrectly.
The goal isn’t “all or nothing”. Every single improvement you can make will improve the accessibility of your site, no matter how small that improvement is. So why not start today? Replace one div with a semantic element, and you’ve already taken steps to ensure your site is accessible to all users!
If you’d like to look further into semantic elements, W3C Schools has a fantastic list that contains many semantic elements and a brief explanation of their use. HTML5 Doctor contains a similar list, but with suggestions from developers around which elements should be used, and which should be avoided, as well as links to other articles to discuss some elements in detail.
Further reading
- https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML
- https://www.boia.org/blog/plain-old-semantic-html-a-perfect-basis-for-accessibility
- https://ux.shopify.com/semantic-html-the-unbearable-rightness-of-being-9b3c493e1791
Abigail Harrison, Code Institute Student
A11y Accessibility Series
This article was written by Abigail Harrison, a Code Institute student. This is part of a series of articles on the subject of A11y, where Abigail covers the following topics.
Try our Free 5 Day Coding Challenge 
Take our full stack course 
