For digital technologies to work interchangeably, they need to speak the same language. The purpose of semantic HTML (HyperText Markup Language) is to provide that language — and with it, a common framework for the different technologies that browse the internet.
This is particularly important when designing content for screen readers (software that converts text to audio) and other assistive technologies (AT). As we’ve discussed on this blog, plain old semantic HTML is the perfect basis for accessibility.
In this context, semantics means providing markup that conveys meaning. When you use semantic HTML appropriately, your website works well with a wide range of technologies.
But to put that lesson to use, we need to understand a bit more about how minor semantic mistakes can have a significant impact on users with disabilities. Here’s what to know.
Screen readers and other AT expect content to have a predictable structure
Contrary to a popular myth, screen readers aren’t web browsers: They’re software that works with the user’s preferred web browser (and various other applications).
Screen readers use accessibility application programming interfaces (APIs) to relay information to the user. The browser’s rendering engine maps information from the website (delivered through HTML and other technologies) to an accessibility API, which works between the browser and the screen reader.
If you don’t use semantics properly, the process fails at the first step. Some screen readers and browsers may be able to overcome common issues with bad HTML, such as parsing errors — but ultimately, the developer has the responsibility to define the content with HTML and other markup.
To learn more about how AT works with web browsers, read: What Is a Website’s Accessibility Tree?
When semantic elements are used improperly, content doesn’t work for everyone
Let’s say you use a subheading tag to organize the content on your blog. That’s a good practice, but think about why those subheadings are important.
You want users to be able to scan content to get the information they need quickly. You can do that by styling text differently using CSS (Cascading Style Sheets), but this results in a visual heading: The text appears to be a heading, but if the user isn’t perceiving the content visually, they’ll miss out on that information.
If a website has visual-only headings, screen reader users can’t jump around the content to find the most important information. Their software might lead them to hyperlinks, input fields, and other important parts of the page, but not to the visual subheadings.
Likewise, if you use subheading tags out of their sequential order, or you use them in place of CSS to style the visual appearance of text, you’re sending confusing signals to screen reader users.
Other semantic mistakes can have an enormous effect on screen reader users:
- Overusing <div> and <span> elements, which have no semantic value, screen readers may announce all of the content as a single block of text.
- Misusing WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) markup may prevent users from understanding content, or in extreme cases, prevent them from regaining control of their web browsers. Read: Don't Use ARIA to Fix Broken Semantics.
- Using HTML tables to layout content can cause screen readers to output the text as a table — which may be confusing if the table is only used to achieve a certain aesthetic. Read: Using CSS to Improve HTML Table Accessibility.
- Generic class and id names can prevent screen readers from understanding the purpose and function of interactive elements.
By using HTML, WAI-ARIA, and other types of markup to define semantics, you can create an experience that works for every user. And by sticking with simple HTML wherever you can, you can write cleaner code and markup, which can reduce the long-term costs (and frustration) of web development.
If you’re ready to start building your digital accessibility strategy, get started with a free automated website accessibility report, which tests content against the Web Content Accessibility Guidelines (WCAG) Level A/AA requirements. To discuss a specific issue, send us a message to connect with an expert.
