Accessibility Basics: Semantic HTML
Semantic HTML is the backbone of any accessible website. Semantic elements clearly describe their meaning and content to browsers, developers and users of assistive technologies. If you want your website to be accessible, start here.
Quick disclaimer: this is just a basic introduction to semantic HTML. I’ve added a short reading list at the end of this article if you want to dive deeper into the topic.
What is semantic HTML?
Let’s start by defining what “semantic HTML” actually means. In short, a semantic element describes its meaning to the browser and the developer.
Some example semantic elements are
Here’s a comprehensive list of semantic elements (opens in new window)
Most importantly for accessibility, semantic elements also describe their meaning to users of assistive technologies. Semantic HTML allows users who rely on, for example, keyboard navigation or screen readers to understand the structure, hierarchy and content of a website. Semantic elements also come with “built-in” accessibility functionalities, which we’ll discuss in this article.
Semantic vs. generic elements
It’s important to note the difference between semantic elements and “generic” elements like
Those come without any meaning, pre-set styling or built-in functionality.
They are essentially “blank canvases”, which is one reason why they’re so widely used.
Keep in mind, however, that generic elements like
<span> are usually “invisible” to assistive technologies.
If you want your project to be accessible, use semantic elements wherever possible.
While generic elements have their purpose, don’t use them for building your website’s layout or its user interface (UI) elements.
Built-in accessibility features
Semantic elements come with certain accessibility features. For example, you can jump from one interactive element – for example a link, input field or button – to the next just by using the tab key on your keyboard. Hitting the spacebar or enter key then activates that element. This is important to users who don’t use a touch or pointing device like a mouse or a trackpad.
In addition, semantic elements announce themselves to screen readers.
For example: “My great headline” inside an
<h1> tag is automatically announced as “My great headline, headline level one”, and “Download now” inside a
<button> tag is announced as “Download now, button”.
This is important to screen reader users who aren’t able to see your website. Indicating whether something is a headline, a button or an input field makes it easier to understand a website and interact with its elements.
On the flip side, if you’re using
<span> elements to create headlines, buttons, input fields and other important parts of your website, you will not get these accessibility features.
Page hierarchy: landmarks
Some semantic elements serve as so-called “landmarks”: they allow users of assistive technologies to understand the overall structure and hierarchy of a website.
For example, elements like
<main> tell screen reader users which part of a website they’re currently focusing on.
Here’s an example of what a simple, accessible website structure looks like:
Landmarks are a great starting point for your HTML markup. If you want to learn more, here’s an in-depth look at landmarks (opens in new window)
Text and layout
When laying out text, use the
<p> tag for your body copy and the heading tags from
<h6> for your headings.
Using these tags makes it easier for screen reader users to navigate your site.
That's because screen readers let users jump from one heading to the next.
This technique is sometimes used to get a quick overview of a website’s content, without having to read all the body copy between the headings.
Using the right heading tag gives screen reader users an idea of how important a piece of content is on your page.
So try not skip from, say, an
<h1> for your main headline to an
<h3> for all other subheadings.
Another thing about heading tags is that they come with a pre-set styling (by default, for example, the
<h1> font size will always be the largest).
However, when choosing heading tags, ignore these styles and pick headings only by functionality. You can easily override any default style in your CSS.
Just decide which heading tag best represents the importance of your content.
Also, try to avoid line breaks
<br> inside your headings, lists or paragraphs.
They confuse screen readers and break up the content inside an element.
When it comes to font sizes, go for relative sizing units like
rem instead of set pixel values.
That’s because users who don’t see very well can increase the font size in their browser settings.
If you use relative sizing units, your copy scales up or down with those changes.
Set pixel values, on the other hand, stop users from changing your website’s font size.
Make your images accessible by adding an
alt description of what’s shown in an image.
These will be read out when a screen reader’s focus lands on an image.
Interestingly, Apple’s iOS screen reader “VoiceOver” describes an image even if there’s no
alt description, but it’s not quite perfect yet: one of the images on this website shows a rolled-up £5 note, which VoiceOver described as a “drink”.
So always add an
alt description to your images.
Most websites use some kind of iconography. Sometimes those icons are just illustrative, and don’t serve any deeper purpose. Often, however, they’re used for key interactions: for example, icon buttons, progress bars or navigation arrows.
As a UX writer, you should identify these purely visual elements and decide whether they need a description for screen reader users. You can add those descriptions in the form of so-called ARIA labels.
Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) is a technical specification that aims to make web content and web applications more accessible to people with disabilities. While semantic HTML offers tags that come with accessibility features, ARIA offers additional tags which you can use when elements are not accessible by default. Read more about ARIA (opens in new window)
User interface elements
While there are a number of different user interface (UI) HTML elements, I’ll just focus on the two most common ones, links and buttons. Here's a comprehensive list of UI elements here (opens in new window)
When designing accessible buttons, figure out whether something is actually a button or a link. When it comes to accessibility, it’s important to choose the right tag based on its meaning and functionality, not on its visual appearance. For example, a link might be designed to look like a button, but as far as functionality goes, it might really just be a link.
Once you’ve decided that you’re in fact designing a button, use the
<button> tag, not a
<div> or any other generic tag.
<button> offers these accessibility features:
<button>can be selected just by using the “tab” key
- It can then be activated by pressing the enter key or spacebar
Screen readers automatically add “button” to any text you put inside
If your button is a
<div>, it won’t be recognised by the tab key – it’s effectively removed from the UI for users who rely on keyboard navigation (or screen readers).
Sure, you can create a
tabindex and so on – but why go through all this trouble when these functionalities come “for free” with the right, semantic, element?
Keep in mind that buttons – like other semantic elements – come with a pre-defined styling.
<div> comes without any styling, it’s important to replace, or “counter”, the native
<button> styles in your CSS.
In order to make your links accessible, simply use a descriptive link text in your
Also, think of your links as independent, self-explanatory elements.
That’s because screen reader users can skip from link to link, and they’ll only hear the link text.
So if your website has a bunch of “Click here” or “Learn more” links, it’s easy to get lost.
If your link opens in a new tab or window, you can add something like “opens in new window” to your link text. That way, you don't confuse screen reader users when they're suddenly taken to a new page.
As a side note, different browsers display semantic UI elements and the states they come with – e.g. hover, active or focus – differently. That means that if you click a link on Chrome, not much happens, but on Firefox, a dotted line around the link appears.
This can be annoying from a design perspective, but whatever you do to address something like this, don’t set
While this is a surefire way to remove a dotted line, it’s also a surefire way to make your site a lot less accessible: the
focus style usually appears when a user “tabs” through a page.
By removing the
focus style, it becomes really hard to know which link or button is currently selected.
Want to learn more about web accessibility, standards, projects and best practices? Here’s a quick reading list to help you get started: