Accessibility for the web - why we should use semantic HTML

In the last article we talked about one of the assistive technologies designed to help people with disabilities access the web: screen readers. If you remember, we said that screen readers translate the info they see on the screen into audio and/ or Braille output. But in order for this to work, developers need to make sure the HTML can be read and translated by the screen readers.

One of the simplest steps a developer can take in order to make their page/ application accessible for everyone is to use semantic HTML as much as possible. But what is that? Is it any different from regular HTML?

The answer is no. Semantic HTML is markup that describes its meaning very clearly. For example, elements like header, table, section or article are very clear about their content while div or span say nothing about what they might have inside. Since 2014, HTML4 got upgraded to HTML5. With the new version, many semantic elements were added so writing accessible code become so much simpler than before. Unfortunately, even today we can see lot of non-semantic markup in the wild. Consider the following example:

<div>
   <div>This is a list</div>
    <br>
     <span>First item</span>
      <br>
     <span>Second item</span>
      <br>
     <span>Third item</span>
   </div>
</div>

This is of course an exaggeration but a very clear example of not so friendly screen readers code. Although we wrote valid tags, they're not used for the purpose they're intended (we're trying to create a list using divs and brs instead of using the correct elements). Now look at the correct example:

<section>
  <h2>This is a list</h2>
   <ul>
     <li>First item</li>
     <li>Second item</li>
     <li>Third item</li>
   </ul>
</section>

When the screen reader encounters the second example, it's very clear that the user it's looking at a section of a web page and that inside the section we have an unordered list - things that are impossible to understand from the first example.

Semantic HTML doesn't require any additional effort compared to non-semantic HTML, especially if you use it right from the beginning of your project. A quick list of semantic elements:

<article>
<aside>
<details>
<figcaption>
<figure>
<footer>
<header>
<main>
<mark>
<nav>
<section>
<summary>
<time>

This doesn't mean we should never use divs or spans or other elements that don't convey their meaning very clearly, but if you care about making your application accessible to everyone, you should definitely use HTML5 as much as possible. Besides a larger number of users, other advantages of semantic HTML is that the code is simpler, easier to read and more maintainable (think about only about all the ids and classes you could avoid using while trying to make non-semantic elements be more specific; for example, someone could write something like <div id=header></div> instead of <header></header>).

Image source: Goran Ivos/ @goran_ivos on Unsplash

Comments

[mihai]

okay, i see your point, but you can give meaning by introducing ids and classes, of course you need to use correctly those things, meaning a id is unique on the page, a class can be reused on any page... d'ohh that's theory. So i can only say this.
It's a matter of usage and what the managers/people you work with say. I mean if the standard is to use these html 5 tags... great!! we all use this. Same can be said about using sass /less /etc .
But if communications is bad, and people let you work on your own , then you could go all xhtml on the project.
Side note, backcend dev don't care what html you give them, we/ they will implement it how it is given, they also can call on you to make changes where you didn't compensate, meaning there was a place where the backend puts and not just divs or But, nice article, keep going :)

[Arika O]

I understand your point of view. HTML5 is not that new tho' and it has no learning curve (when it comes to semantic elements at least). I don't see why would anyone chose to clutter their HTML with CSS and write something like <div id="footer">This is a footer</div> when they could go the simple and user friendly way and write <footer>This is a footer</footer>. These ids and classes might make sense for us, the developers, but let's not forget that screen readers are not human so most often than not, the CSS doesn't make much sense to them. Everyone working as they wish and poor communication inside a team are some realistic scenarios but this is another problem :). Thx for your input.

[Suyash]

HTML had semantics even before HTML5 new semantic tags via WAI-ARIA Roles attributes and some of these new tags also brought new native capabilities (like accordion with details & summary). Also class or id doesn't change the semantic meaning of the tag, div with id or class of footer will still have generic semantic.