What is web accessibility, and what features and practices should we employ? Let’s also discuss assistive tech and focus management.
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.
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.
Before we go any further, this article assumes the following:
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.
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.
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.
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
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
shift keys or who have some sort of motor disability.
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.
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:
Tabindexof > 1
Tabindex = 0
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
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
tabindexand 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.
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.
<label> <input type = "radio" checked name = 'type' value="0"> Trip <label>
What screen readers pronounce is, “Trip, selected, radio button.“
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?
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
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! 😄
Subscribe to be the first to get our expert-written articles and tutorials for developers!