Meaningful semantics
Published on | Takes approximately 3 min to read
Semantics and meaning is a very in-depth topic. I cover the ideas I will mention in this article in three separate, in-depth chapters in the Practical Accessibility course. So I will try to be as brief as possible here.
HTML Accessibility API Mappings
The way HTML elements are conveyed to assistive technologies (ATs) like screen readers depends on the Accessibility API Mappings (HTML AAM) of those elements.
The HTML AAM define which ARIA role an HTML element maps to, if any. This role determines the meaning of an element to ATs like screen readers.
Most semantic HTML elements and attributes have implicit role, state and property mappings. They are mapped to ARIA roles that are exposed to screen readers in the accessibility tree. For example:
-
The
<nav>element is mapped to anavigationrole. So it is exposed as a navigation region to screen reader users. -
The
<h2>element is mapped to aheadingrole, with thearia-levelproperty set to the number in the element’s tag name, so the screen reader knows this is a level 2 heading. -
The
<img>element is mapped to animgrole, so users know that this is an image. -
The
<button>is mapped to abuttonrole, so users know it is a button. Since native HTML controls also come with functionality baked in, thebuttonalso has attributes indicating that it is focusable, for example.
An element’s role is the the first part of the accessibility information exposed in the accessibility tree. This means that semantics in HTML provide the first (and arguably most important) piece of accessibility information about an element. The meaning (and by extension, the usefulness) of an HTML element is determined by the ARIA role it maps to.
For your day-to-day work, the ARIA in HTML specification provides a more developer-friendly list of mappings that you can refer to. These role mappings give you insights into how an element should be exposed in the accessibility tree, and whether and how it is going to be announced by screen readers.
section is meaningless… unless.
The <section> element doesn’t map to an ARIA role by default. This means that it is not exposed as a landmark region, unless it has an accessible name.
Without an accessible name, <section> becomes almost like a <div> — specifically, in that it doesn’t provide any meaningful semantics to a screen reader user.
<section> will only be exposed as a landmark region if it has an accessible name.
If a section on the page should be exposed as a landmark region, the section should have a name. And, ideally, the name should be visible to all users. This also means that, ideally, the <section> should have a heading element (<h1>–<h6>) that describes the contents of the region. Then, you associate the heading with the <section> using aria-labelledby:
<section aria-labelledby="title_ID">
<h2 id="title_ID">I describe the contents of this region</h2>
..
</section>You could use aria-label to provide an accessible name to the <section> if you absolutely have to. But aria-abel does not translate well. If designed well, the region should have a clear label that is available to all users equally (the heading in our case). Use aria-label as a last resort.
Other elements are also meaningless unless…
<section> is not the only element that doesn’t map to a role by default. If you browse the list of mappings, you’ll see that other landmark elements will also only map to a role if they are used in specific contexts. For example, a <header> element will only be exposed as a banner landmark when it is a direct child of the <body> element. Same applies to the <footer> element.
<body>
<!-- this header is exposed as a banner landmark region -->
<header> .. </header>
<main>
<!-- this header is not a direct child of the body, so it won't be exposed as a banner landmark region -->
<header> .. </header>
<!-- .. -->
<!-- this footer is not a direct child of the body, so it won't be exposed as a contentinfo landmark region -->
<footer> .. </footer>
</main>
<!-- this footer is exposed as a contentinfo landmark region -->
<footer> .. </footer>
</body>You can use <header> and <footer> elsewhere where it is semantically appropriate, but you should know that they won’t add any semantic value to ATs like screen readers. They may still contribute to how content is displayed by other types of ATs such as reader modes.
