Semantic HTML for Better Accessibility

When I first learned to create a basic webpage using semantic HTML, it was not in the context of accessibility. I learned terms like header, footer, section, and aside, but didn’t have a clear understanding of why these terms were important. Over time, I saw a lot of code simply using divs for everything, and fell into that pattern myself. I realized that it didn’t affect the functionality of my web pages as far as I was concerned, and didn’t require me to think about the construction of my webpages at all. It takes no effort or thought to throw a div in there.

Since then, I’ve taken a deep dive into accessibility, and various tools for enabling wider access to web pages.

So, now I’m here to strongly encourage you to use semantic HTML correctly and intentionally.

This post will give a brief summary of accessibility and screen readers, describe what belongs within each semantic html tag, talk about using automated tools such as Lighthouse for testing accessibility on your page, and direct you to comprehensive sources for information and guidance on accessibility.

ACCESSIBILITY

An accessible web page is one that is functional and readable for all users, including those who are experiencing an impairment or disability. That impairment or disability could be physical, non-physical, temporary, or sustained, and there’s a huge range of tools to help with any of them.

THE IMPORTANCE OF SEMANTIC HTML

Using correct Semantic HTML is crucial for efficient navigation of a web page using a Screen Reader.

Screen readers are software programs that allow blind or visually impaired users to read text displayed on a screen with either a speech synthesizer or a braille display. Screen readers create an alternate version of the page. Victor Tsaran, a Google employee who is blind, released this video to show the experience of using a screen reader for everyday use. This video was incredible to me, having never seen a screen reader in use, and I highly recommend checking it out.

Using semantic elements and consistent labeling gives screen readers more information about what is being displayed, and empowers users to zip around the page using key terms. Without it, a user may be forced to go through the page line by line to try to find the information they are interested in, or render some buttons or functionality unusable. You could compare the experience of listening to endless non-semantic elements to listening through an unreasonably lengthy phone menu to know which number to press for the information you are looking for.

WHAT TO DO

Use div and span only for layout. These elements don’t give any keyboard or touch support in any browser, and they don’t communicate anything to assistive technology. Avoid using them for headings, buttons, or other uses where semantic elements would provide more meaning.

Buttons should be used for actions, and links for navigation, as intended. Remember that styling can be altered, if that’s the reason you are tempted to use div.

Provide names for buttons to avoid ambiguity and to enable users relying on a screen reader to know what action they will initiate.

If you use each semantic element for its intended use, the browser will do most of the work for you to make that element accessible. Below are some of the most common semantic elements.

SEMANTIC ELEMENTS

The <header> element defines a header of your document that will always be visible at the top of the page. It gives introductory content, and commonly contains heading elements, a logo, a search form, and navigation.

Headings are very important. Screen reader software has a shortcut key which asks the browser to search the HTML for anything inside a h1 to h6 heading element. It will send back a list of headings, allowing a user to quickly select which they would like to read.

The <nav> element denotes a section of a page that has the purpose of providing navigation links. Examples include menus, tables of contents, and indexes.

The <main> element encloses the main contents of a document, and should be unique to the document. It should not contain repeated content such as navigation links, site logos, search forms, etc.

The <section> element represents a grouping of related information, and usually will have a heading. It’s used when other, more specific, semantic elements don’t apply, and may contain any other elements. It cannot be a descendent of <address>. Consider using the <article> element(below) if your section is a self-contained grouping.

The <article> element represents a stand-alone composition on the page. Examples include a forum post, a newspaper article, or a blog entry. An <article> may contain multiple <section> elements.

The <aside> element represents a portion of the document with content that is indirectly related to the main content. They are often presented as sidebars or call-outs.

A <footer> element typically contains information about the nearest sectioning content, including author information, or links to related documents.

The <address> element indicates that the enclosed HTML contains contact information.

The <figure> element indicates separated content, which may include photos or diagrams.

The <figcaption> element is used as a child of the <figure> element to give a caption or legend that describes the contents of the figure.

The <details> element denotes additional details that the user can choose to display or hide.

The <mark> element indicates text that is marked or highlighted for emphasis.

The <time> element, intuitively, is used to denote a display of time and date on the page.

IS YOUR WEBSITE ACCESSIBLE?

There are open source automated audits to test for accessibility. While they won’t tell you everything about the ease of use or efficiency of your site, they can wave a red flag for anything that is not functional for users using assistive technologies. Try it in chrome by opening up your dev tools, selecting the lighthouse tab, and making sure the accessibility option is checked.

As an example, I checked this page as I was writing, and it scored an 86 for accessibility. It flagged several things, including a button without an accessible name, making it unusable for anyone relying on a screen reader to know what the actions it carries out would be.

In the below resources, there’s a checklist by WebAIM for checking your web content for accessibility.

MORE RESOURCES

There’s an excellent Google Webdocs text version of part of the content available in the free Udacity course on Accessibility. These cover far more than semantic HTML.

Check out the Web Content Accessibility Guidelines (WCAG) 2.0, which was put together by accessibility experts to break down the meaning of accessibility, and provide guidance around best practices.

WebAIM has broken the WCAG guidelines down into a checklist for web content.

Web.dev has excellent information on accessibility for development called Accessibility for All.

For more detail and examples for semantic HTML tags, see HTML5 Semantic Tags: What Is Semantic Markup?

MDM Webdocs HTML Elements Reference.

Check out Three common accessibility pitfalls for developers: information and relationships by Julie Grundy.

THANK YOU!

As always, I’m learning continuously, and would be happy for any feedback or corrections.

Take care of each other.