Follow Accessibility Rules for Successful Software

Today, technology is meant for everyone to use it. If your digital product is not accessibility compliant, you risk that more than one billion people cannot use it. Hundreds of billions are big business opportunity. The common misconception is that accessibility is just for people with disability. Even people without disabilities will benefit if our digital product is accessibility compliant. Accessibility has become a key value in creating a digital product.

According to the World Health Organization* more than one billion people worldwide live with a disability. It’s estimated that around 20% of the population has some sort of disability. While the umbrella of accessibility concerns the 20% it also includes pretty much everyone else as shown in the next section.

Accessibility is defined as a "word used to describe whether a product can be used by people of all abilities." There is accessibility of building and physical space with ramps, power door openers, and more. Digital accessibility is about rendering websites, software, and games to be accessible and inclusive for people with disabilities. Digital accessibility is the practice of making digital product usable for the widest range of people possible.

Before we dive into accessibility optimization, let’s make sure that we understand major challenges and standards that we need to follow in order to make sure that our digital product can be used by all people.

Getting familiar with disabilities

Disability is defined as "a mismatch in interaction between the features of a person's body and the features of the environment in which they live."

It’s about everyone.
If you don't wear glasses or contacts, consider how many people you know that do. The fact is that most of us will develop vision impairments as we age. We also develop arthritis, carpal tunnel, or similar disorders that prevent us from using a mouse or keyboard. We don't know the circumstances that will inhibit the way people access the web and mobile. For example, those are that have:

• Vision disabilities (blindness, low vision, color blindness)
• Hearing disabilities (deafness, hard-of-hearing)
• Physical disabilities (lack of motor control, speech troubles, other issues)
• Cognitive disabilities (learning disabilities, distractibility, inability to remember or focus)
• Technical issues (slow connection, screen size, old technology)
• Changing abilities (changing abilities duo to age)
• Temporary disabilities (broken bones, recovery, using site while holding a baby)

Image: Persona Spectrum

“We use a Persona Spectrum to understand related limitations across a spectrum of permanent, temporary, and situational disabilities. It’s a quick tool to help foster empathy and to show how a solution can scale to a broader audience.”
A Microsoft Design Toolkit

We need to consider these scenarios and make it easy as possible for this wide range of people to access the software that we build.

The WCAG Guidelines

WCAG stands for Web Content Accessibility Guidelines.
It's set of international standards for web accessibility guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). The main goal is to provide a detailed set of guidelines for making web content more accessible to many people as possible. There are multiple versions of guidelines as listed below.

WCAG 1.0

First version 1.0 was published in May 1999 and it was first international standard for digital accessibility. It contained a set of 14 guidelines to evaluate the accessibility of the web pages.

Web and assistive technologies evolved over next decade the guidelines were updated to the next version.

WCAG 2.0

It provides 12 guidelines that are organized into four principal categories. Major things that web content must be to be considered accessible (see Understanding the Four Principles of Accessibility for the WCAG definitions). It stands for acronym “P.O.U.R”:

• Perceivable: Information and user interface components must be able to perceive the information being presented.
• Operable: User interface components must be operable. Users must be able to control UI elements (e.g., buttons must be clickable in some way — mouse, keyboard, voice command, etc.).
• Understandable: Information and the operation of user interface must be understandable.
• Robust: The content must be developed using well-adopted web standards that will work across different browsers and assistive technologies, now and in the future.

WCAG 2.1

As we can assume this version extends 2.0. It was published in June of 2018 and become the official recommendation of W3C. 

Understanding WCAG 2.0 and 2.1

As mentioned above this provides 12 guidelines that are organized into four principal categories.

1. Perceivable: Guidelines 1.1-1.4

Information and user interface components must be able to perceive the information being presented.

	1.1	Text alternatives for non-text content like images must be presented.
	1.2	Alternative methods for time-based media like captions and transcript must be presented.
	1.3	Provide ability to present content in different ways, allow for customization without breaking the site.
	1.4	Make it easier to see and hear content.

2. Operable: Guidelines 2.1-2.4

User’s interface components must be operable.

	2.1	All functionality must to be available via the keyboard
	2.2	Provide enough time to read the content and interact with interface
	2.3	Avoid designing/developing contact that cause seizures
	2.4	Help user to navigate, find content and determine where they are focused

3. Understandable: Guidelines 3.1-3.3

User’s interface components must be operable.

	3.1	Text content should be readable and understandable
	3.2	Content and interface should be consistent and predictable
	3.3	Input assistance to help users fix mistakes when interacting

4. Robust: Guidelines 4.1

The content must be developed using well-adopted web standards that will work across different browsers and assistive technologies, now and in the future.

4.1

Address the needs to maximize compatibility of current user agents and assistive technologies

WCAG Criteria and Conformance in Action

In section above we have seen that WCAG consist of 13 guidelines. Each guiltiness contained several success criteria. Each of success criteria meet a certain level of accessibility conformance according to standard.
Level of conformance range from single A to triple A like below:

• A – Lowest level
• AA – Mid-range level
• AAA – Highest level

Each is a subset of the next level up. For example, if a web page meets double of conformance level it also meets a single A conformance level. It’s important to note that meeting the success criteria and conformance level only works on a full page. If part of the page doesn’t meet a double level, then the whole page doesn’t meet a double level.

What are Screen Readers?

A screen reader is a form of assistive technology (AT) that renders text and image content as speech or braille output. Screen readers are essential to people who are blind, and are useful to people who are visually impaired, illiterate, or have a learning disability. They allow the user to interact with the computer, navigating around and entering data on forms using the keyboard. They have a wide array of keyboard shortcuts to make interactions simple. Some of the popular screen readers are Voiceover (Bundled into MacOS), JAWS, Window-Eyes, NVDA, and so on.

Nonvisual desktop access - NVDA

NVDA, Nonvisual desktop access is open-source solution that is completely free and one the best option for developers to test their application. You can download app and configure on windows on the following link: https://www.nvaccess.org/download/

It’s important to note that during the testing you should just use the keyboard and not the mouse. Good way to test is to turn off monitor and see what typical user would experience.
NVDA has two modes:

1. Browse is primary for reading content
2. Focus is for entering data on forms

Primary commands:

• Space (enter focus mode for control)
• Tab (Jump focus to next control)
• Shift + tab (Jump focus to previous control)

Quick Key Commands:

• H- Heading
• K – Links
• B – Buttons
• L – Lists
• D – Landmarks

Testing WCAG compliance

To make digital product accessible and WCAG compliant, we should have a good testing plan and strategy. The following strategy can help you to meet that goal:

• Manual keyboard testing. Using keyboard to ensure we can get and interact with everything.
• Screen reader testing to make sure it works as expected. Readers like NVDA, JAWS, etc.
• Use “semi-automated” testing with tools like WAWE or Accessibility Insights for Web
• Automated testing with tools like AXE Core which run against our code and catch basic errors. It can be part of CI/CD process.
• Ask people with disabilities and get their feedback.

“Semi-automated” testing

One of the best tools for “semi-automated” testing are Accessibility Insights for Web and WAWE web accessibility evaluation created by webbing. WAWE can be used by:

• Navigating to the webpage and pasting URL to the page and running the tool
  https://wave.webaim.org/
• Browser extension for Chrome and Firefox. It’s much more useful for local testing and development. Once you install plugin you can start testing immediately.
  

It’s important to understand the main categories before you start the testing:

	Errors	If you have errors that means you have problems that need to be fixed
	Alerts	Those alerts are not critical, but we need to look into and try to improve behavior. Varying like: form label issues, skipped heading levels, redundant links etc.
	Accessibility features	Alternative text, form labels, skip links etc
	Structure	Elements like heading, list, navigation. They need to be used properly in order help accessibility.
	Aria	Additional features for HTML elements to give more information’s to assistive technologies about our content.

Automated testing

In order to make the process easier the best way to go is automated.  Automated testing can save time during the development phase and educate developers with error that they introduce. Our favorite automated tool is AXE Core created by Deque Labs. It’s testing engine created for HTML that is built to integrate with existing test environment for automated accessibility testing. This testing can be part of our unit and integration testing or CI/CD process.

It’s important to highlight that some criteria cannot be automated. For example: criteria related to mobile device interactions has to be done manually on a device. Automation testing is not a replacement for human but it helps catch some of the low-level issues and it’s far from perfect.

Conclusion

In this article, we realized that around 20% of the population has some sort of disability, and the importance for our business to keep digital product accessibility compliant. Companies who continue to ignore accessibility are already losing customers and will end up losing even more in the coming years.

We got familiar with WCAG standards as well as testing strategy and most popular tools that we should consider for our product.

In the next article, I will demonstrate some of the techniques and the most important implementation that your digital product should have.