What is Semantic HTML?

What is Semantic HTML?

Every HTML element serves a purpose. The purpose is conveyed through its semantic meaning. Knowing when to use which element to accurately convey meaning is no easy task.

As a quick example, a link element's semantic meaning is conveyed as, "link". A button element is conveyed as, "button". As a result, people will understand how to interact with and have an expected result when interacting with these elements.

Semantic HTML is the foundation of an accessible experience

Writing semantic HTML is really the foundation or "blueprint" of creating an accessible experience. It means using native browser elements and controls in order to convey the meaning, structure, and purpose of our content.

This is how people who use and rely on screen readers and other assistive technology know how to navigate and consume your site content and what to expect when interacting with an element.

In doing so you answer the question for the user…

What is this thing and what does it do?

The semantics of an element is very important to keep in mind when writing HTML. Understanding when and how to use HTML elements is not always easy, but correct implementation will result in a positive and successful user experience for people who depend on assistive technology.

Semantics include…

There's information that needs to be present when an element receives keyboard focus in order for someone using a screen reader to navigate and consume that content.

For example, naturally focusable elements include links, buttons, and other form controls, and when the element is in focus, its text content and related attributes are read out loud to screen reader users, describing what it is they're currently interacting with.

What's announced is:

  • The element's accessible name or text equivalent
  • The element role
  • The current state of the element (if applicable)

The accessible name/label/text equivalent

The accessible name is the part that describes what the element is for, its purpose for being.

This is usually found as the content between the start and end tags of an HTML element. It could also be the alternative text value for an image alt attribute, or the label associated with a form input.

Let's take, for instance, a link. This element has text between its start and end tag. This text gets read aloud by a screen reader when it receives keyboard focus. In doing so, this conveys context on what should happen or where the browser should go when that link is activated.

For example, a link with the accessible name of "Contact Us" would indicate that, if you activate that link, it will load a page with contact information; maybe a telephone number or address, and possibly a form where someone could send a message.

<a href="contact.html">
  Contact Us <!-- 👈 Accessible name, 🗣 "Conact us" -->
</a>

The element's role

The element's role informs the user of a few things, including what the element does and how to interact with it.

Coming back to the link example, the role announced when the link receives keyboard focus would be "link," as links are structured with opening and closing a tags and include a valid href attribute. The expected result or, "what it does," would be for the browser to either load a new page or jump to another section of the same page, shifting focus to a different element. How to interact with the link would be for the user to press the Enter key, as this is also a part of the semantics of a link.

<a href="contact.html"> <!-- 👈 Role derived from opening… -->
  Contact Us
</a> <!-- 👈 … and closing tag: 🗣 "Contact us, link" -->

Various element roles come with expectations on how to use them. Depending on the role, a user might expect they would need to press the Enter key to continue (as is the case with a link), use the Space key to activate a button, or perhaps use the Up arrow or Down arrow keys to make a selection when interacting with a select element.

The current state

In addition to the name and role, depending on the element at hand, there could also be a state announcement.

Announcing the state helps to convey the current condition of the element, whether an interaction is needed, and what might happen when the interaction takes place.

For example, checkboxes and radio buttons have a "checked" or "unchecked," and a "selected" or "unselected" state, respectively.

<label>
  <input type="checkbox" />
  Apples <!-- 🗣 "Apples, checkbox" -->
</label>
<label>
  <input type="checkbox" checked />
  Oranges <!-- 🗣 "Oranges, checkbox, checked" -->
</label>

An accordion style widget would have an "expanded" or "collapsed" state, indicating whether the content is on-screen and available for consumption (expanded), or if the content section will merely be skipped over when navigation continues (collapsed).

Why using native elements is best

As we'll see later, it is possible to create custom elements and set semantic meaning and interaction using a variety of HTML attributes and JavaScript code. However, consider the following before creating a custom element:

  • Native elements provide semantic meaning by default; no need to worry about how someone using assistive technology might understand what the element is or how to interact with it
  • Native elements provide all the expected keyboard functionality right out of the box; no extra time and effort spent on writing code to capture keystrokes
  • Default styling is consistent and familiar to your users; people get used to the look and feel of their operating system and browser – create a comfortable user experience by using native elements

Using semantic HTML is to set up your users for success

Semantics convey the message of what the currently focused element is, what it might do, and how to interact with it. In order to create an inclusive experience, it's important to understand the semantic meaning of HTML elements, know when the appropriate context is to use them, and how to accurately pass the message along to the user of what the element is for.

See MDN: HTML elements reference for more details on each native HTML element.

The accessibility tree

We can't discuss semantic HTML without mentioning the accessibility tree! This is a tree like structure of elements which closely resembles the DOM, but contains more information, such as semantic meaning as previously discussed.

Screenshot of Shopify.com homepage with console tools open showing the accessibility tree of a button.

Picture for a moment, a website without any style attributes or CSS applied. This raw output of content closely resembles what the accessibility tree is, which is interpreted by assistive technology such as a screen reader.

The DOM is to browsers as the accessibility tree is to screen readers

When the screen reader will be able to use the information stored in the accessibility tree to accurately announce the semantics of the element in question; its role, the name or label, and the state of the element. All of this information is a part of the accessibility API that most assistive technology use to convey information to the end user.

If you'd like to take a peek at the accessibility tree of a website, Chrome has this available in its Developer Tools under the Accessibility tab.

WCAG success criteria

This comes back to 1.3.1 Info and Relationships which states:

"Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

Resources:

Back to blog