Habits you can adopt to achieve accessibility
Tags: a11y, webdev, mobility, inclusion
Published: 2020-05-18 07:44:02

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](https://www.who.int/disabilities/world_report/2011/report/en/)) 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`
```html
<div class="button button-primary">
  Click Me!
</div>
```
Now what's bad in it is `div`s 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.
```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](https://mdn.github.io/learning-area/accessibility/html/table-layout.html). 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.

```html
<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.

```html
<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.
```html
<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](https://developers.google.com/web/tools/lighthouse)
It's an open-source, automated tool for improving the quality of web pages.
- [eslint-plugin-jsx-a11y](https://www.npmjs.com/package/eslint-plugin-jsx-a11y)
Static AST checker for accessibility rules on JSX elements.
- [react-axe](https://www.npmjs.com/package/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](https://www.w3.org/WAI/tutorials/forms/notifications/).
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.
```js
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](https://testing-library.com/) by [Kent C. Dodds](https://twitter.com/kentcdodds). 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](https://github.com/mkamranhamid/accessible-components) 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.🤝