How to improve website accessibility with semantic HTML & WAI-ARIA

Consider this: there were more than 2,000 lawsuits filed in 2018 related to web accessibility (source). Now more than ever, there are real-world consequences to ignoring website accessibility concerns.

However, the threat of a lawsuit isn’t the only reason to make your website accessible. Accessibility overlaps with many other website best practices in areas like mobile design or search engine optimization. When you focus on providing an inclusive experience to all users, you’ll see benefits all around.

Improving website accessibility can seem like a daunting task, especially if you’re retrofitting an existing website, but even small improvements can make a big difference to your users. One place to start is going back to the basics and improving the HTML structure of your website.

Why write accessible code?

To understand how your website’s code affects how people with disabilities use your website, you first have to think about the different ways a user might be browsing your content.

The first image that likely comes to mind is a user sitting at a computer using a mouse to navigate—but that isn’t always the case. Users could also be browsing the web on a touch screen, by keyboard-only, or with assistive technology like browser zoom, screen readers, or a voice assistant. If your code is not properly optimized to account for these use cases, your website could potentially become unusable to an entire portion of your audience.

If you’re unfamiliar with how assistive technologies like screen readers work, try out this demo of Google’s ChromeVox Lite. It simulates the website experience of a low-vision user and lets you experiment with how content is read out by a screen reader. This helps illustrate just how difficult it can be for a user to navigate content using this type of technology if a website was not coded with accessibility in mind.

The good news is that you can easily improve the browsing experience for assistive technology users with a combination of semantic HTML and WAI-ARIA.

“There were more than 2,000 lawsuits filed in 2018 related to web accessibility (source). Now more than ever, there are real-world consequences to ignoring website accessibility concerns.”

Semantic HTML

Semantics in HTML essentially refers to the meaning that a piece of code conveys. For example, a heading tag like <h1> has semantic value—it signifies a top-level heading. By wrapping text with the <h1> element, you’re giving it a specific purpose.

This can start to get complicated once you introduce CSS styling onto the page. Perhaps you are using styles to make a line of text look like a top-level heading, but it just happens to be wrapped in a <p> tag instead. Visually, you might be achieving the same effect as using a heading tag, but from an HTML standpoint, that line of text no longer has the same semantic value.

Most users will never know the difference when browsing your website, but any technology that relies on semantics to give meaning to your content will run into issues. Screen readers specifically use HTML markup to announce to users what an element’s role is and any other associated metadata. If that information is not present in your code, it will be difficult to access your content. This is why semantic HTML is the backbone of an accessible website.

How do you ensure your HTML is semantic?

First, consider the purpose of each element you add to the page, as well as what content it will contain. Determine if there is an HTML tag that matches up with the purpose of your element, and if there is, use it.

You should only use generic tags like the <div> tag as a last resort. For example, HTML5 introduced additional semantic tags for common structural elements on a web page, including <header>, <main>, and <footer>. Instead of using a generic <div> tag to wrap your page content, you can now use <main> to make it clear where the primary content of your page is located.

Second, in addition to choosing the right tag, include any relevant attributes as well. For example, a <label> tag needs to have a for attribute that references the id of its associated field. As with this example, some attributes are required in order for an element to be fully accessible.

Finally, consider the hierarchy and order of your elements. Most websites are not just a single column of content – they use CSS styling to place content in different areas on a page. For example, a common layout pattern is to have a sidebar with additional information to the left or right of the main content.

However, assistive technologies do not take the visual layout of a page into consideration but instead look at the order of content in the code. If less important sidebar content is read out before the main content, this could be confusing to a user. Do not rely on styling alone to make the flow of your content make sense.

According to MDN, there are over 100 semantic elements in HTML. By taking advantage of the semantic value of these native HTML elements, you can create accessible content with no extra effort. However, for more complex websites, you’re almost certain to run into cases where a semantic element doesn’t exist for the type of functionality you’re developing. That’s when it’s time to look to WAI-ARIA.

“Semantic HTML is the backbone of an accessible website.”

WAI-ARIA

When it comes to dynamic or interactive features on a website, HTML often needs a little bit of help to convey the right context and meaning to browsers and assistive technologies. That’s the primary goal of WAI-ARIA.

WAI-ARIA, often more succinctly referred to as just ARIA, refers to the Web Accessibility Initiative’s Accessible Rich Internet Applications specification. Put simply, ARIA gives developers additional semantic markup options to improve website accessibility.

ARIA comes in the form of attributes that can be added to existing HTML elements. ARIA attributes do not affect any visual elements of a website but is intended only to convey meaning at the code level. It should only be used when native HTML markup will not suffice, and not as an alternative for poor structure.

ARIA can be broken down into two categories: (1) roles and (2) states and properties.

What are ARIA roles?

Roles are used to define types of elements within a user interface, and can be added using the role attribute. There are six role categories:

1. Abstract roles
2. Widget roles
3. Document structure roles
4. Landmark roles
5. Live region roles
6. Window roles

Two of the most common types of roles you are likely to use are landmark roles and widget roles.

Landmark roles indicate the various regions of a page, and can be used by assistive technologies to jump to different sections. The landmark roles currently available are banner, complementary, content info, form, main, navigation, region, and search.

Widget roles are used to give semantic value to commonly used interface elements. For example, this list includes roles for button, checkbox, and tab, just to name a few.

What are ARIA states & properties?

States and properties are used to provide additional meaning to an element. While similar, properties differ from states in that properties don’t typically change based on user interaction. A state—for example, aria-disabled–is typically tied to functionality and will be programmatically adjusted.

There are four categories of states and properties:

1. Widget attributes
2. Live region attributes
3. Drag-and-drop attributes
4. Relationship attributes

When should I use ARIA?

There is a lot that ARIA can do, and it can be overwhelming to figure out when and where to use it on your website. You can start by looking at the most common problems developer’s use ARIA to solve. For example, ARIA is often used to:

1. Improve document structure
2. Add semantic value to content
3. Make interactive elements accessible

Let’s take a closer look at each of these use cases.

Improve document structure

You can improve how assistive technologies browse the structure of your page by including landmark roles in your HTML.

If you’re using semantic HTML5 tags, you likely already have some of these landmarks setup. For example, role=”banner” is conveyed by using the <header> tag. So, this: <div role=”banner”>…</div> has the same semantic value as this: <header>…</header>.

Other landmark roles such as search don’t correspond with a native HTML5 tag. In these cases, adding the role to the appropriate element will include it in the list of landmarks on the page.

Add semantic value to content

You can use properties like aria-labelledby and aria-describedby to create relationships between elements and make your code more meaningful.

For example, if you have a <section> in your code and would like to associate a heading with that section to describe what it contains, you could do something like this:

<section class=”content-section” aria-labelledby="SectionLabel">
  <h2 id="SectionLabel">My Content Section</h2>
  ...
 </section>

The property aria-describedby can be used in the same way, but would be better when a longer text alternative is required to describe an element.

In general, you can use ARIA properties such as these when the additional context is needed to give meaning to content.

Make interactive elements accessible

The most prominent use case for ARIA is to make interactive and dynamic content accessible to assistive technologies. A combination of roles, states, and properties can be used to improve accessibility for common interface patterns like tabs, accordions, menus, and more.

Consider a traditional tabbed interface: all content except for one panel is hidden initially, with labels to click to toggle to another section. This seems fairly simple from a visual standpoint, but within the code, it’s a bit more complex. Without a visual reference, a screen reader doesn’t know that there is hidden content or how to toggle to another section.

In order to make tabbed content accessible, ARIA attributes are needed to specify the relationship between elements, as well as any state changes. In this particular case, that consists of adding the tablist role to the element and then adding the corresponding attributes to the appropriate elements within the tab interface.

When creating any interactive elements on your website, consider which ARIA attributes might be needed to make your content accessible. You can start by referencing the WAI-ARIA Authoring Practices document, which provides an overview of common user interface elements and how to use ARIA to improve accessibility. It includes examples and code snippets for reference.

Keep in mind this key takeaway from the authoring practices documentation: “No ARIA is better than bad ARIA.” It’s important to fully understand the ARIA markup you are using on your website to ensure it’s being implemented correctly. Overall, with proper research and practice, ARIA is a powerful tool for improving web accessibility.
We design custom websites. Let’s talk
You might also like …

• Is Your Website User-Friendly for People With Disabilities?
• How to Set Up a CMS That Will Make Non-Technical Users Happy
• SEO for Web Developers: A Beginner’s Guide