How to be an A11y

In my previous blog, I talked about why it is important that we follow the Web Content Accessibility Guidelines.
In this blog, I’m going to go over the first steps we can take to make our applications more accessible and implementing what WCAG recommends.

We will be going over:

• Writing Semantic HTML
• Introduction to ARIA

Writing Semantic HTML

First, we will talk about semantics and writing semantic HTML.
Semantics in HTML means that if we are using a semantic element in HTML we expect the element to give us information and what to expect inside of it. It is the idea that every element in your document has a purpose. This is important so that say if a user is using assistive technology like a screen reader to navigate your application, they can easily interpret what every element on the page is doing/saying.
An example of writing HTML that is more semantic is using h to represent important and less important heading on your page. Splitting up the HTML on your page to use main, article, and footer tags can be helpful.
A good example of an element often used that is not very semantic is the div tag. The div tag semantically is a grouping of content, it is often read as a ‘group’ by assistive technology. So, if there is something important in your div such as a list, button, or any important content, you want to use an element that is more semantic. You can also use ARIA to make elements more semantic, we’ll go into that next.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element

Introduction to ARIA

Next, we will go into ARIA.
ARIA stands for Accessible Rich Internet Applications, and it helps with making non-accessible controls accessible. For cases where you are using DOM elements that are not semantic, ARIA HTML attributes can help add a semantic layer to elements to make them readable from assistive technologies. ARIA attributes modify the way an element is translated to the accessibility tree. This is the only change ARIA makes to the element. It will not make any changes to how the element behaves on the page.

Here is an example of a way we would write an input semantically.

<lable>
<input type="radio">
Option One
</label>

A screen reader would be able to provide to the user the label which in this case is “Option One” and it would also tell us the state of the radio input, whether it was selected or not.

Here is an example in which we are not able to use semantic in order to display a radio input.

<div class=”radio checked”>
Option One
</div>

So here we know that this div is meant to be a radio input with a state of checked because we added classes that represent this to us. However, a screen reader would not be able to read this information because divs do not have roles or states to indicate this in the accessibility tree.

Here is how we can use ARIA attributes to make this div tag more semantic.

<div class=”radio” role=”radio” aria-checked=”true”>
Option One
</div>

By adding this role and aria-checked attribute causes our element to now to have a role and state in the accessibility tree, which assistive technologies can now pick up and translate to the user. It will not change anything about the elements’ visual appearance or behavior on the page.

You can learn more about ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) authoring practices for implementing ARIA attributes to less semantic HTML elements.

Cover by The Creative Exchange on Unsplash.