A Matter Of Semantics

Semantic markup is a veteran concept in web development – it’s one of the cornerstones of the accessible web. Many online accessibility tutorials and checklists make it a point to mention the importance of semantic markup for accessibility, but a lot of the ones I’ve used didn’t elaborate further.

What does the term “semantic markup” actually refer to? 

Why is it so important? 

How does it affect accessibility? 

I’m going to try to address those questions here – to highlight the role of semantic markup in A11y and to break down how it’s conveyed to the end-user. I’m going to discuss a couple of ways to categorize semantic elements by type, to clarify how each type affects a page’s accessibility and to present a few ways to predict the severity of issues caused by the lack or misuse of semantic markup. 

We’ll also touch on the use of ARIA roles in non-semantic elements.

What is semantic markup?

Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information in web pages and web applications rather than merely to define its presentation or look. Semantic HTML is processed by traditional web browsers as well as by many other user agents.

Wikipedia

Semantic markup refers to HTML elements whose name and usage describe their meaning. The initial HTML language was designed to act as the building blocks of a document. It consisted of paragraphs, headings, tables, etc. just like the semantic building blocks of documents.

As the internet gained momentum, interfaces became increasingly more complex. As styling options were very limited (CSS wasn’t introduced until the end of 1996), developers found solutions by building the interface layout using tables. Though at the time it was an effective fix, another problem arose – search engine crawlers now transmitted page data in table data format.

As CSS matured, more layout-related attributes were added. When styling was finally separated from the content layer, the table-based layout was replaced by the <div> based layout, which allegedly solved the semantic contradiction in the cases that layout was conveyed as table data. The flip side of this solution was that it stripped all the semantic meaning from the code itself, conveying content by the visual layer exclusively. In 2010, new semantic tags that described application structure were added to HTML and so the first features of HTML5 were born.

But if web pages and applications don’t need to be built with semantic building blocks in order to be operational and to accurately display content, why are semantic tags important? And what do they have to do with a page’s accessibility?

Who’s reading my DOM?

Each user agent uses and interprets a page’s DOM in its own way and communicates content using various different output methods, visual output being the most intuitive. When a sighted user is perceiving an interface, the semantic meaning of the elements is presented on the screen by the element’s visual attributes. 

Some user agents (and some assistive technologies, ie: screen readers) cannot rely on visually perceivable attributes to relay the context and meaning of the present elements. Screen readers use auditory output to communicate the content of a page, to describe each element and instruct the user on how to interact with it. Being that a browser’s visual output is built to be intuitive for neurotypical users and screen readers can’t interpret visual conventions, communicating content depends exclusively on parsing the code itself. 

Take, for example, a <div> used as a button. It gets style info from CSS and has an event handler attached to it from the JS. It’s allegedly a valid button, but screen readers interpret it as a generic container, which means the attributes that are expected from a button will not be communicated to the user, like the fact that it’s clickable, why the user might click it, etc.

How do assistive technologies convey the semantic DOM?

As mentioned earlier, user agents use an element’s semantic attributes to communicate its meaning and purpose to the end-user. If semantics are misused, the element they belong to is rendered inaccessible.

Semantic elements can be categorized to predict how the lack or misuse of semantics will affect component accessibility. It’s not a perfect method, nor is the categorization below complete, but it can definitely be a tool for designing and diagnosing semantic structures. 

HTML elements’ semantics are classified into 3 categories:

1. Structural
2. Contextual
3. Operational

Structural

Structural semantics use tags like <header>, <footer>, <section>, <article>, etc. to imply their role in the interface. Most of these tags were additional HTML5 added to incorporate HTML into the descriptions of modern interfaces. Using these tags will help screen reader users access elements directly without needing to manually click their way through the entire interface. 

Headings tags (<h1-6>) are critical to this category. When used correctly, they create a kind of table of contents for the page, allowing the user to jump around the page and interact only with the elements of their own choosing. An incorrectly structured headings hierarchy is a major

Contextual

This category includes elements like <ul>, <ol>, <li>, <table>, <tr> etc. In contextual tags, each element depends on a larger semantic structure to convey its full semantic meaning. These semantics are crucial to the user experience as these elements usually represent some kind of sequential data and facilitate internal sub-navigation of list items, table cells, etc.

Operational

Tags like <a>, <button> and <input> are form elements that require user input. Using incorrect operational semantics to represent an element can result in the element being miscommunicated (or not communicated at all) to the user. This category of element semantics impacts accessibility the most when its overlooked or misused. Incorrectly tagging operational elements might cause an interface or parts of it to be inaccessible to users of assistive technology. These elements often require user input so, when the element’s operational semantics are incorrect, any interaction or input from the user fails to yield the intended change(s) in the interface. 

Missing/Incorrect Semantics

In time, interfaces began incorporating elements like tabs, tooltips and pop-up dialogs that didn’t have representative HTML tags. To remedy the situation, the W3C‘s WAI initiative introduced the ARIA spec.

The ARIA spec is kind of a semantic band-aid to make the dynamic content and advanced user interface controls of Web content and Web applications more accessible to people with impairments.

One of the components of the WAI-ARIA is the role attribute, which allows the developer to assign semantic meaning to non-semantic elements. There are 70 available roles – some present new semantic concepts that have no analogous HTML tag, others represent existing semantic concepts like buttons, links, and checkboxes.

ARIA roles that complete the missing element semantics can significantly improve usability and user experience, but using them also has some (avoidable) pitfalls.

Adding roles to an element indicates to assistive technologies how to interact with it, but the element is then missing some attributes that would be included had actual semantic elements been used.

For example, in the case of a <div role=”button”>Click me</div>, a screen-reader would communicate to the user that it’s a button, but won’t communicate information about the button’s interactive options that would have been specified had a native semantic <button> been used. Other roles might require an additional attribute or a specific DOM structure or they will not work as expected.

To sum it up, ARIA roles can be very useful, but it should be implemented with forethought.

• Always prioritize native semantic elements over adding roles. 
• If you are using an ARIA role, check if it requires additional attributes or if it should be part of a larger hierarchy. For example, the element assigned to the role “listitem”, should always be the child of a “list” element.
• Never redefine an already semantic element. Different assistive technologies parse the accessibility tree in different ways, so redefining attributes can lead to unintended behavior.  

Conclusions

A well-designed graphic user interface is a beautiful thing, but keep in mind that conveying the context of interface components visually is not enough. Non-human user agents digest the same interface, and lack the human ability of interpreting its contents and intent by visual context alone. To compensate, they use the semantic structure to communicate and operate the interface components.

The semantic structure of HTML should always describe what you see on the screen. If it doesn’t, that’s the spot in which your site’s accessibility is lacking.