semantic DOM

What is a semantic DOM?

A semantic HTML element is any element that expresses a specific role beyond being a generic container of content. Take, for example, the <p> or heading (<h1-6>) tags, both of which is expected to contain some text, but the semantics of the heading tags make an expectation for a short text that describes (in a high level) the content that comes after it, while the paragraph semantics produce an expectation of more detailed and usually longer text.

Element semantics are an integral part of HTML. In fact, in language there are only two non-semantic tags, <div> which represent a block-level generic container, and <span> that represents an inline-level generic container. All other presentational HTML tags have some semantic meaning.

Proper semantic construction of the interface contributes not only to accessibility, but also to SEO, greater code transparency, and better technical communication.

How using semantic elements helps (or interferes with) accessibility

Proper semantic construction of the DOM helps on three levels from an accessibility perspective:

Identification and understanding

The user who sees it, can interpret and understand the meaning and purpose of the elements on the screen according to their styling and the context in which they are presented. This visual data is not available to assistive technologies so they must rely on the actual semantics of the elements. For instance, incorrect or lack of semantics can make it difficult or impossible for screen reader users to identify the elements' meaning and purpose.

Usage and Operation

Semantic elements also carry with them, beyond the baggage of meaning, a set of attributes and behaviors that are required by its semantic meaning. For example, a checkbox will necessarily have to be focusable and have a checked property that's defining its state. Non-semantic elements lack these default attributes, so while a mouse user will be able just to point to and click on the element, keyboard-only users may fail to reach it, as it's excluded from the focus sequence.

When an interface has a proper semantic structure, it is easier for screen reader users to get an accurate mental image of its various parts and have better orientation in it.

Screen readers also allow for quick navigation between elements based on their semantic type through keyboard shortcuts or a dedicated widget.

An alternative for semantic elements

In general, it is considered to be a bad practice to use non-semantic elements instead of the actual semantic element. However, sometimes it's inevitable, so in these cases we can coerce semantics on an element using the role attribute.

Three rules of thumb for using the "role" attribute:

1. Do not coerce semantics on elements that already have their own semantic.
This may cause an unpredictable and inconsistent output as different browser/screen reader combinations will produce different outputs. Use the role attribute only with non-semantic elements (e.g. <div>, <span>).

1✓ <div role="button">Click Me</div>
2✗ <a role="button">Click Me</a>

2. Make sure you assign the role attribute with valid values. The length and diversity of the list of possible values that can be assigned to the role attribute can be confusing and sometimes it gives the feeling that any value we use will be valid, but in fact, this list is carefully constructed, so using improper values may cause assistive technologies to ignore or misread these elements.
See here the full list of valid role values

1✓ <div role="img"><!-- Image content --></div>
2✗ <div role="image"><!-- Image content --></div>

3. Make sure that the required attributes and structure of the semantics are handled properly. Coercing semantics on an element will just register it to the accessibility tree with its new role but will not apply to it any additional attributes that the role may require, such as focusability or state attributes. These have to be added manually by the author. In many cases, the lack of these attributes will prevent users from using these elements.

1✓ <div role="checkbox" tabindex="0" aria-checked="false"></div>
2✗ <div role="checkbox"></div>
3
4  <!-- 'listitem' must be within a list -->
5  <div role="list">
6✓    <div role="listitem"><!-- content --> </div>
7  </div>
8
9✗ <div role="listitem"><!-- content --> </div>

Extending the semantics of HTML

One of the problems of HTML on the semantics aspect is that it has never been able to keep up with the requirements from the user interfaces. The language originally designed to display text documents fails to bridge the gap between its built-in semantics and the semantics required by user interfaces today. Unfortunately, it mainly affects users of assistive technologies that are depended on semantics and the accessibility tree, so to bridge the gap, WAI has added a list of values to the role attribute for common UI components that don't have a corresponding native HTML semantics, including values that express complex structures like tabs or for specifying a more generalized semantic idea like, for example, a switch that is a private case of checkbox.

The same rules that apply to values expressing existing semantics also apply to those that extend semantics. The allowed and required attributes, as well as structure, constrains if the role has any are defined by the WAI on their "Roles Model" spec.