Our Journey to Accessibility: Part 1

Over one billion people have some form of disability [1]. In other words, around 15% of the population experiences some kind of auditory, cognitive, neurological, physical, speech or visual impairment. Moreover, this percentage is growing due to a rise in chronic health conditions and an aging population.

Here at Empathy.co, we decided it was time to expand our work on Web Accessibility, by increasing our efforts to create products accessible to everyone, providing equal web access, benefits and capacity to all users. Through our process, we discovered that these changes were beneficial to many people, not just people with disabilities. Even those experiencing temporary illness, recovering from an injury, or simply dealing with a slow or faulty internet connection gain from the implementation of accessibility measures.

So, where do we start?

To make our applications accessible, first we need to understand who should be involved and how. According to WCAG 2.0 (Web Content Accessibility Guidelines), there are 61 success criteria for web accessibility. The distribution of these criteria across the different roles in the web development lifecycle looks as follows [2]:

As you can imagine, most of the responsibilities lie on frontend development, but many other not-so-intuitive roles should also be involved. Please note that although Project Management is not directly involved when implementing any of the 61 success criteria, it should ensure accessibility is taken into account at each step of the SDLC and that every team member understands their role in this matter.

WCAG Principles

The Web Content Accessibility Guidelines (WCAG) is an international standard, created by the Web Accessibility Initiative of the World Wide Web Consortium to provide a single shared standard that meets the needs of individuals, organizations, and governments internationally. Following these guidelines will make a web page generally easier to use and make the content accessible to people with one or more of the following disabilities: cognitive limitations, learning disabilities, speech disabilities, deafness and hearing loss, blindness and low vision, limited movement, photosensitivity and combinations of these [3].

WCAG comprises four main principles: Perceivable, Operable, Understandable, and Robust (POUR). In the following sections, we will explain their meaning and implications, using WCAG 2.1 AA documentation as a reference.

Perceivable

Users should be able to identify and interact with content on the UI through the browser or assistive technologies. Some of the guidelines following this principle are:

• All non-text content presented to the user has a text alternative that serves the equivalent purpose.
• Captions, audio descriptions or any other alternative presenting equivalent information are provided for time-based media (audio or video content, either pre-recorded or live).
• Content information, relationships, reading sequence and purpose of an input field can be programmatically determined.
• The content view is not restricted to a single display orientation.
• Specific contrast ratio and text spacing are required.
• Color is not used as the only visual means of providing information.
• Scrolling in more than one direction is unnecessary when content is scaled.

Operable

Users should be able to interact with all controls and elements using a mouse, a keyboard, or an assistive device. Moreover:

• Content does not “trap” keyboard focus within subsections, and the focusable elements receive focus in a meaningful order.
• Characters’ key shortcuts should have the possibility to be turned off, remapped or activated only on focus.
• Time limits can be turned off, adjusted or extended.
• There is a pause/stop/hide mechanism for any moving, blinking, scrolling or auto-updating information.
• Web pages have titles, headings and labels that describe the topic or purpose. When links are present, each link’s purpose can be determined from the link text or together with its link context.
• All functionality can be operated with a single pointer without a path-based gesture, and it is possible to cancel a pointer to prevent accidental or erroneous input.
• For UI components with labels that include text or images of text, the name contains the visually presented text.

Of course, there are more guidelines, but we won’t cover them all this time around.

Understandable

Content and functions on the site should be easy to understand. This can be accomplished by following the subsequent guidelines:

• The language of each web page and each passage can be programmatically determined.
• A UI component receiving focus or changing its settings should not initiate a change of context.
• Navigational mechanisms that are repeated occur in the same relative order unless a change is initiated by the user.
• Components that have the same functionality are identified consistently.
• Labels or instructions are provided when content requires user input.
• If input error is detected, the error is identified and described in text. Moreover, if the suggestions for correction are known, they will be provided to the user.
• There is a way to review, confirm and correct data.

Robust

The application should be compatible with different browsers, platforms and devices; and be available for a wide range of technologies. To achieve this purpose, we must commit to the following:

• Content can be parsed: elements have start and end tags, are nested according to specs, etc.
• Name, role and values can be programmatically set for all UI components.
• Status messages can be programmatically determined in content implemented using markup languages.
  

Enough theory, what's next?

Going back to the WCAG 2.0 success criteria chart, it is clear that our primary focus should be on the frontend development, improving our current code and making sure every component built from now on is accessible. So we decided to look at our archetype, a living prototype that grows at the same pace as the X Components features, in order to understand where there was room for improvement. For this, we used:

• LightHouse: A Chrome extension, also available integrated into Chrome DevTools, which executes multiple page audits and creates a detailed report. Besides accessibility, it can give you hints on how to improve other areas of your website, such as SEO or performance.
• WAVE: A browser extension that provides visual feedback, injecting icons and indicators into the website.

We realized that we could improve our accessibility by adding an ESLint Vue.js accessibility plugin. Once installed, we enabled all the recommended rules at once so it could analyze all Vue.js files and identify the related accessibility violations. From then on, the application wouldn’t be able to run if any of the recommended rules were ignored. Sounds good!

But unfortunately, it's not that simple. As UI sophistication increases due to web capabilities' expansion, building accessible components and relationships between them becomes more difficult. To ensure we are aware of and understand all this complexity, we are currently immersed in the ARIA Authoring Practices Guide, analyzing and learning how to build accessible versions of common UI design patterns, such as modals, grids, accordions, and checkboxes.

As our journey to accessibility continues, I’ll be back to keep you updated. Stay tuned!