The ARIA affect

It always seems like an after thought. We rush to meet deadlines and implement awesome user interfaces. Then when we are hours from releasing we finally look at the things that we didn’t get to, things that we think are less important to the end-user such as:

• Code optimization
• Unit Testing
• Improving or implementing a site search
• Improving SEO

Then usually at the bottom of the list we think to ourselves — “What about accessibility?” Then we hurry up and run the Chrome dev tools accessibility audit and if we pass a majority of tests we call it good.

After all the work we have done to implement a super awesome website, one of the most important things we can do to help users is often not given the time or quality it deserves.

There are many things to consider when creating accessible sites:

• Navigating with the keyboard
• Color contrast ratios to accommodate those with color blindness and other vision deficiencies
• Audio transcripts for videos
• etc…

Here we will only address making a site accessible to those with vision impairments.

Understand the Problem: The First Step

We often like to jump in and come up with a solution before we fully understand the problem. This leads to solutions as in the photo below, where the initial problem statement probably was:

• “People in wheel chairs can’t get up the stairs.”

After questioning and understanding the issue the problem statement would have been updated to:

• “People in wheel chairs cannot get in the door, because of the stairs.”

We have great intentions, but in the end fail

This is true about web accessibility for the visually impaired also. HTML is inherently accessible. The most important improvements you can make to a website is to lay out a page in a semantic manner. Here are a few checks to make:

• HTML head element contains a title element
• Content (before styles are applied) is readable like a book:
• The page should include a page header (h1) followed by content sections with sub headers and content
• All image and video elements have alt attributes
• There is a defined end of content or footer
• Main navigation is inside nav tags
• All links and buttons perform how intended (links navigate to another page and buttons trigger events on the page to make it do something)

Now that the basics are taken care of we can move to making JavaScript page actions accessible. If you don’t do anything with JavaScript then you can skip the rest of the article. That’s right, if:

• There are no changes to the DOM that get triggered by user interaction via JavaScript

and

• You wrote the page semantically and added the ADA specific attributes (alt and title) that should be added anyway

Then your site is already accessible to the visually impaired. If you do use user-event based JavaScript to update the DOM then —

Welcome to ARIA (Accessible Rich Internet Applications)

For brevity I will only go over a few use cases, for full documentation visit the W3C accessibility pages here.

There are two use cases that usually send developers up the wall, because they are not responsive or are hard to make accessible…Tab Panels, and Modals. They are truly the cause of many night mares.

First: Tab Panels —

Here is an example of code that might be written for a tab panel:

All the functionality is handled by JavaScript and as such a screen reader will not provide the user any feedback on what is actually on the screen. The user could be confused about the context of what is being read.

To solve this we add a few attributes to the elements:

• role — Tells the screen reader what the element is
• aria-controls — Tells the screen reader what element will be triggered from a user action
• aria-labelledby — Tells the screen reader what element labels the content that is visible

Here is an example of the accessible code:

Second: Modals —

The non-accessible code:

Again to fix it, the ARIA attributes are just like in the tab panel example except that they point to different references:

The one difference with the modal is that we need to make sure we bring keyboard focus to the element. If we don’t do this the user would lose context, as we have now obstructed everything behind a block element. To do this you just focus the keyboard on the first element that the keyboard would interact with. In the example above, this would be the close button:

document.querySelector('#modal button').focus();

The Value of Being Accessible

In my industry it is not about the bottom dollar, but about the ability to reach as many people as possible and share messages about Christ and His gospel. Providing websites that are accessible in any industry can provide real value.

According to the US Census Bureau, as of July 2012, there were 8.1 million people, or 3.3% of the US population that were visually impaired. That is a huge number for US markets alone. Imagine the number of people worldwide that could be reached if your website was accessible.