Awesome a11y
Tags: a11y, web, development, design
Published: 2018-02-27 18:11:35

---
title: Awesome a11y
published: true
description: web accessibility
tags: accessibility,web,development,design
canonical_url: https://dev.to/napicellatwit/awesome-a11y
---
Hi everyone!

Today I am going to discuss about a topic very close to me: 
Accessibility (or a11y for short).

I have worked a little over one year in the Accessibility team, experience that helped me grow, both personally and professionally.
I have recently moved to another team, so before I will partly override what I learned with new information, I though to flush out the main memory on the disk and write down the main pointers for later reference. 
Hopefully with this post I am going to to kill two birds with one stone, both document and share couple of lessons learned.

Quick introduction before we start, what is Web Accessibility?

>From wikipedia: 
Accessibility refers to the design of products, devices, services, or environments for people who experience disabilities.

Specifically web accessibility, refers to the design of web experiences available to `ALL` the users.

I think there is something strange with the previous definition.
Can you guess what I mean? Little clue, the word has been emphasized. 
The weird part is that the definition specifies that a web application is `Accessible` if can be used by `all` our users. 

Let's think about it for a moment. We are about to build a new awesome web app, how a requirement for it would look like?
> Customers must be able to sign in the web app using an email and a password...

We say Customers, but we really mean __all the customers willing to use our app__. `All` is implicit. 

> Clearly we do not want to restrict our app to part of the customers? Do we?

Unfortunately, this is exactly what happens when we start our project neglecting Accessibility. We close our app to lots and lots of customers.

Before we start, let me define some of the terms I am going to use throughout the article.
* assistive technology (AT for short): an umbrella term that includes products, equipment, and systems that enhance learning, working, and daily living for persons with disabilities. In the context of the web, this means tools like screen readers, magnifier, head pointers, etc.  
* screen reader: Software used by blind or visually impaired people to read the content of the computer screen. Examples include JAWS for Windows, NVDA, or Voiceover for Mac.
* magnifier: Allow users to control the size of text and or graphics on the screen. Unlike using a zoom feature, these applications allow the user to have the ability to see the enlarged text in relation to the rest of the screen. This is done by emulating a handheld magnifier over the screen.
* Head pointers: A stick or object mounted directly on the user’s head that can be used to push keys on the keyboard. This device is used by individuals who have no use of their hands.

With that being said, let's start!

### 1 - Design your application with Accessibility in mind from DAY 1.
This means couple of things:
- Favor simple design over complex UI.
This does not mean you can't add dropdown,
carousel, etc. This means that the user must be able to navigate the page without loosing context of where he/she is.
People with cognitive impairments might have issues following long chain of widgets or popups (by the way, try to avoid pop ups, more on that later).
Same for screen reader users. Overall a simple design does not just help AT customers but also non AT customers, which are going to find the experience much more fluid.

- Mind the contrast ratio. According to [colourblindawareness](http://www.colourblindawareness.org/colour-blindness/) color blindness affects approximately 1 in 12 men (8%) and 1 in 200 women in the world . It's a lot of people, lots of customers.
There are lots of tools out there which can help with that (Google has a dev tool that among other things check for contrast ratio).
It's really a low hanging fruit.

### 2 - Try to use HTML native elements
Screen readers describe the context to the user, using metadata associated with the element.
This means that if you use an anchor or a div to create a custom button, the screen reader has no way to detect that's a button, which implies that the user does not know how to interact with the element.
If you really have to use a div for your button, be sure to use the `role` attribute which adds context to element.  
This is not enough though, you also need to take care of keyboard navigation and focus.

> For native HTML `button` elements, the button's onclick event will fire both for mouse clicks and when pressing Space or Enter, while the button has focus. But if another tag is used  to create a custom button, the onclick event will only fire when clicked by the mouse cursor, even if role="button" is used. Because of this, we have to add a separate key event handler to the element so that the button can be triggered when the Space or Enter key is pressed.


```html
<span role="button" 
      tabindex="0" 
      onclick="handleBtnClick()" 
      onKeyPress="handleBtnKeyPress()">
      Save
</span>
```

> The takeaway here, is that it might be a lot work to transform a custom element in one that behaves like a native one. So use a native element whenever you can. If you don't like the look && feel of the element, style it.

On this subject, the [mozilla developer guide](https://developer.mozilla.org/en-US/docs/Web/Accessibility) is invaluable.
It might look like a lot to read...well, it is. But bear with me a little longer. 
See, I really think that reading all the Mozilla docs or the W3C accessibility guidelines is not required to make a web app accessible. 
Instead, a more sensible and scalable approach is to look up in the guidelines the suggested approach for what you are about to build.

### 3 - Test the page with different magnification factors
How does the page look like when a different magnification factor is used? 
Does the text scale accordingly? What about the page structure?
Many users need to use a zoom factor or a magnifier to be able to read the page.
The only way to actually verify how the UI behaves is to test it out.

### 4 - Use headings
Communicate the organization of the content on the page using headings from the highest rank `h1` to lowest `h6`.
Assistive technologies like screen readers, allow to navigate between them, providing an effective way to skip entire sections of the page.  
If something is an heading, use one instead of styling normal text to look like an heading.

### 5 - Use new html5 elements
Similarly to headings, the new elements `header`, `nav`, `main`, and `footer` provide the ability to designate sections of the page.
The elements provide additional information to screen readers, which also support the ability to navigate/jump through them.

### 6 - Announce page changes
Modern web apps are built to react to internal or external events. Some examples:
* Add to cart button changes the status of the cart showing the number of elements in the cart
* A new email received causes an update to the notification bar to show the number of mails to read
* New message in a chat application

All those examples have something in common: the web app react to an event by dynamically changing parts of a page without requiring the entire page to reload.
While these changes are usually visually apparent to users who can see the page, they are not to screen reader users.
How can we fill this gap for our users?  
Enters `ARIA`.
> ARIA defines markup extensions (mostly as attributes on HTML5 elements), which can be used by the web app developer to provide additional information about the semantics of the various elements to assistive technologies.

In this case, an Aria live region can be used.
```html
var result1 = 0;

function update1() {
	result1 = result1 + 1;
	document.getElementById("result1").innerHTML=result1;
}
</script>
</head>

<body>
...
<div id="result1" role="status" aria-live="polite"></div>

<div>
<button onclick="update1();">Update result 1</button>
</div>
...
</body>

```

There are tons of examples on the web, pasting here a link for quick reference:
[example](https://developer.paciellogroup.com/blog/2014/03/screen-reader-support-aria-live-regions/).

### 7 - Get to know ARIA
In the previous section I mentioned that ARIA helps us to provide additional information to assistive technologies.
It's an W3C Recommendation, which means that there might be variation in the implementations among browsers and assistive technologies.
My experience on ARIA is of a project pretty mature and well received by the industry.
For many people in this field way more prepared than me, ARIA is going to become a standard pretty soon.
Again, you do not need to read all the [ARIA guidelines](https://www.w3.org/TR/using-aria/#rule1) before starting building you web app, instead use it as a reference.
There is one important rule to remember while using ARIA:
> __The first rule of ARIA is...do not use ARIA__
This is the exact some concept mentioned earlier about using native over custom elements.
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

### 8 - Avoid the pop up trap
> ME: I have added a pop up to the app for the login, it looks so cool!

Couple of hours later:

> Issue 1: The pop us is not announced by the screen reader so the customer has no idea how he ended up in the login page


> Issue 2: Pop up announced but the focus is still on the background page. Customer can not insert his credentials


> Issues 3: Focus is in the pop up, but the Customer is not able to exit. He is trapped in the popup until he refreshes the page

I don't know about you, but I was ready to give up on pop ups after the second issue.
Joke aside, if you really need it, check if the library you use to style the app already provides accessible pop ups. 
Otherwise stay away from them unless you are willing to spend a significant amount of time on making an accessible pop up.   

### 9 - Provide an alternative text
Do not forget to add an appropriate description of the image in the `alt` attribute.
On the other hand, when an image is used only for decorative purposes (think about a line separator, background images, etc.), add an empty alt attribute `alt=""` or remove the image from the page content and add it as a background image using CSS. 

When dealing with a complex image, such as a chart or map that cannot be described in a couple of lines, then the alternative should be provided elsewhere through `longdesc`.


### 10 - Test the Web app with a screen reader
> It might look like I am stating the obvious, but I think it's important to point out that like any other piece of code we write, __if it's not tested, it does not work.__

Download the cheat sheet for Voice Over (JAWS if you are a windows users), put your headset on, start the screen reader and close your eyes.
Experience what it is like to navigate the website using the keyboard without looking at the screen.
Check that you can reach any part of the page, you can skip sections, there are no focus traps, etc.

## Conclusions
Thanks for reading this far. I might have forgotten something, in which case I'll write a follow up post.

Please comment and share your experience to make this check list even more A11Y awesome.

Thank you!