Creating a Web for the Next Billion Users, Part 1: ARIA, Focus and Focus Management

What is web accessibility, and what features and practices should we employ? Let’s also discuss assistive tech and focus management.

Creating platforms for the web has always been as simple as learning to write HTML, throwing in look and feel with some CSS, and then, possibly, a bit of JavaScript or any other scripting language for the functionalities. However, there are more intricacies to be able to accommodate assistive technologies and a wide range of users living with disabilities.

In this three-part series, we will be looking at ways to improve the state of modern applications and also to improve the web for the next billion users.

TL;DR

In this article, we aim to understand the concept of accessibility for the web and will discuss how to implement accessibility features in applications and also give insight into practices that help to encourage the user of assistive technologies. We will also be looking at the concept of focus management.

Prerequisite

Before we go any further, this article assumes the following:

• You have knowledge of HTML
• You have an understanding of the Document Object Model (DOM)

Getting Started

Making a web project accessible can feel overwhelming, but it’s really just as simple as implementing a more semantic approach to writing code to enable all users. The foundation for this is the POUR principle, which guides building accessible websites.

Simply put, POUR means: Perceivable, Operable, Understandable, Robust.

Perceivable: This means the web should be available to the senses (vision, touch and hearing), either through the browser or through assistive technologies like screen readers or screen enlargers.

Operable: This means users can interact with all controls and interactive elements using either the mouse, keyboard or an assistive device. We will look at making platforms operable in the section on focus management.

Understandable: In this aspect, we consider the use of language, which includes trying as much as possible to cut down spelling errors and complex grammar.

Robust: This means having consistency across the web. What this means is your platform must work the same way across all platforms.

Common Practice

I always emphasize the simple fact that building more accessible platforms comes down to writing more semantic HTML. Structurally, semantic HTML is the key starting point toward good accessibility practices. When a screen reader, or any sort of assistive device, scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page.

Note: No styles or JavaScript will be read by a screen reader.

Now this is really straightforward, right? However, the question usually arises, “What does it mean to write semantic HTML?"

Simply put, the semantics of HTML put more emphasis on what each markup means rather than just defining its presentation or look. Which means using the actual tags that give more meaning to what your structure actually is, e.g., using a nav tag when you’re talking about a navigation instead of beating a div into a Nav.

What is Focus Management?

The concept of focus management is really important in understanding how assistive technologies handle announcing elements in the DOM or even how interaction occurs on a platform.

Well-planned focus management is important to ensuring a comfortable user experience. What this means is moving the cursor from one part of the app to another, in order to help users (mostly with motor disabilities) navigating the platform with the keyboard in the intended flow of the app. Some elements are implicitly focusable, such as form elements and anchor elements, while others are not, such as p and h2 tags.

What are Focusable Elements?

HTML elements can be focusable if they have some semantics to them. As stated above, elements that are basically focusable are usually calls to action or navigation, which include input, text area, button, anchor tags, etc.

On the other hand, non-focusable elements are elements that are used to show some structure, such as div and p tags, h1-h6, etc. These elements can gain some focusablitiy using ARIA labels. We will talk about this in another section.

Focus refers to the control from the computer screen that receives input when you send information. This is usually associated with the keyboard. Whenever you attempt to fill a form or use a specific part of a web page, you have to put it in focus.

This is important to users who would rather navigate the platform with the keyboard using tab and shift keys or who have some sort of motor disability.

Focus Helpers

Now that we have an idea of what focus management means, the question is how do we actually implement and achieve this, and how do we navigate focus on elements.

To achieve focus management, we use a couple of awesome attributes. Like tabindex and ARIA, so let’s talk about these elements.

Using Tabindex ( -1 , 0 , 1 )

The way focus rings know how to navigate the tab order is by using what is called the tab index of elements. Naturally, focusable elements may not need a tabindex, so we mostly use this with non-focusable elements.

An element with a tabindex can be categorized into three values:

• Tabindex of 0
• Tabindex of -1
• Tabindex of > 1

Tabindex = 0

Having a tabindex of 0 makes it easy for elements that do not have semantic focusability to be able to appear in the accessibility DOM tree. What this means is that if a div has a tabindex of 0, it is reachable by tabs, giving it focusability.

<div tabIndex = '0'
    role = "button"
    aria-label = "open">
</div>

Tabindex of -1

When an element has a negative value (doesn’t have to be -1), it takes it away from the accessibility DOM tree. You might wonder why you’d want to remove an element from the accessibility DOM tree. A good use case would be toggling the unnecessary links that come before main content to give people the option of starting from the main content on the page.

This can also be achieved with Skip links.

Tabindex of > 1

When the tabindex is set to 1, it moves the element to the top of the accessibility DOM tree. This makes it become the first focusable element in the page

Note: Testing tools like AXE might have a problem with tabindex and flag them as a problem, so if you don’t have to use a tabindex, it’d be best to use the predefined semantic tags.

Roles

The concept of having roles with HTML tags is mostly used to create a better experience for assistive technologies. A screen reader provides an auditory representation of a DOM tree to a user (mostly users with visual impairments). In this case, the screen reader would define the element’s role, name, state and/or value. The role is what the element does, e.g. is it a radio button? Is it an editable text? Is it a button?

<div tabIndex = '0'
    role = "button"
    aria-label = "open">
</div>

From the above code example, we can see the role of the div as button. Although this is not advisable (as the button tag would be preferable), it does provide a semantic explanation of the element.

Another example:

<label>
 <input type = "radio" checked name = 'type' value="0">
  Trip
<label>

What screen readers pronounce is, “Trip, selected, radio button.“

ARIA

ARIA (Accessible Rich Internet Applications) allows us to express a broader range of non-accessible controls to be accessible. For instance, using the radio button example we have above, if we wanted to have more control over the styling of the radio button we would have to modify it a bit, maybe like so:

<div class ="checkbox">
  subscribe to our services 
</div>

Now the above code might display a custom checkbox, but in the accessibility DOM tree it doesn’t exist and this is a problem for screen readers. Although it will announce the text inside the div, it will not tell you the role or the state. How do we solve this?

Using ARIA

ARIA makes use of role to add in additional semantics. To display this, we will modify the code example above.

<div class ="checkbox"
    role = "checkbox"
    aria-checked = "true"
 >
  subscribe to our services 
</div>

Another very fascinating implementation of ARIA is its ability to help generate more expressive UI patterns, using values like aria-expanded = "true" and also adding roles that express what these attributes do. We can also use values like aria-label = "" to give an element its own name tag (this can be used on all elements).

To get more information on ARIA, check out the official documentation.

Note: ARIA does modify the accessibility tree. It does not do the following:

• Modify element appearance
• Modify element behavior
• Add focusablitiy
• Add keyboard event handling

Conclusion

In this article, we have attempted to understand the basics of accessibility for the web and also looked at some accessibility principles. I hope we put these practices into play when building applications to enable a better web for everyone. Happy Coding! 😄