Habits you can adopt to achieve accessibility

We are web developers and our focus is mostly on the technical part of an application like a feature should work or animation should animate but in building applications, we often forget the disabled people which are 15% of the world's population (according to WHO) and more than 1 billion in number.

About 15% of the world's population lives with some form of disability, of whom 2-4% experience significant difficulties in functioning.

In this article, we are going to look at how by adding small habits in your daily code routine can help you make your applications accessible also we will be going to look at Accessibility testing and some tools that you could use or integrate into your application to test if your application is accessible to users.

What is Aria?

When you first heard about the term accessibility you might have heard about aria too or maybe you read it somewhere but you never get a chance to look at what it's. Aria is shorthand for Accessible Rich Internet Applications. It's a set of attributes that can be added to your HTML elements to make the application accessible across the people with disabilities. This helps the screen readers and other assistive technologies to better understand the webpage. An aria is composed of 3 specifications role(It's announced by the screen reader like button, menu, heading,...), state and properties.

Habit #1: Use the suitable native HTML element

Try to use native APIs available in the HTML and not to create an element which is already available. If you really want to then add it's semantics.

For Example:

We always have this habit of creating buttons using div

<div class="button button-primary">
  Click Me!
</div>

Now what's bad in it is divs don't have tabIndex attribute that's why they are not accessible using tab also they don't have a role of a button as well. Instead, create a button using a native HTML.

<button class="primary">
  Click Me!
</button>

In the old days, people used to build a webpage using single table element. Now that was surely a challenge but that doesn't mean a good practice too it's bad for screenreaders because it will readout weird stuff. An example of that will be this. If you inspect the site you will see just one table element inside a body.

Habit #2: No aria is better than bad aria

To understand this concept you need to understand that ARIA, controls the rendering of the non-visual experience. Every HTML element and its attribute has semantics. Using incorrect aria-*- could end up in making the confusing for a screen reader.

For Example:

Let's say we want to show our user some tabs on the webpage. We could do it something like this.

<h1 role="tab">Group 1</h1>

Now here the problem is the tag we used has a default role="heading" and as we have discussed before using suitable and appropriate element is the key. So to fix the above example we can simply do the following.

<div role="tab">
  <h1> Group 1 </h1>
<div>

Habit #3: Keyboard navigation

Not all your users use a mouse for navigation some only use keyboard. HTML should be written in a way that your user will be able to move focus between elements using tab and shift + tab. To achieve this WAI-ARIA has a tabIndex attribute which can be applied to all the HTML elements. Anchors and form control have a by default value.

Note:

tabIndex="-1"
-1 or any negative value means this item is click focusable and not sequentially focusable.
tabIndex="0"
0 or any positive value means this item is sequentially focusable and click focusable. It creates a sequence/ordering so the tabIndex value with higher number comes later.

<div tabindex="1">Tab One</div><br>
<div tabindex="3">Tab Two</div><br>
<div tabindex="2">Tab Three</div>

These were some of the basic code habits you can adopt to make your code accessible across assistive technologies.

Tools

When writing code a developer requires some tools to test the code internally. Some of the tools that are helpful in testing the accessibility of your app are.

• Google Chrome Lighthouse It's an open-source, automated tool for improving the quality of web pages.
• eslint-plugin-jsx-a11y Static AST checker for accessibility rules on JSX elements.
• react-axe Accessibility auditing for React.js applications

Testing

Testing your accessible element is important because the project you work on the first time you never know you will be working on it again.
Let’s say we have a login form which has fields email and password and a button to submit the form. We have an active form validation on it before login submission.
As per WAI-ARIA, we need to notify the user in an accessible way whether it's a validation error or result of there form submission is an error.
You can look at the number of ways we can notify a user about the form activity here.
To test the form accessibility we will go with the approach of notifying the user thru an alert message. The Alert component looks like this.

const Alert = ({ message })=>(
  <div class=”alert alert-error”>
    <p role=”alert”>{message}</p>
  </div>
)

So if there's an error we will show the user an Alert component with a message else we don't. So our accessibility tests will be as follows.

• it should show no message on focus
• it should show a message if any field is blurred without providing the value
• it should show a message when provided with wrong credentials

For testing of my components, I use testing-library by Kent C. Dodds. It's one of the best testing libraries available also they promote testing the way a user will interact with your component.
I've created a repo with tests and components.

Fin

So that was it! I'd love to hear your thoughts on this. Please do comment or email me about your takeout on this and if I miss something do let me know.🤝