Accessibility Testing in QA

Imagine that you are a color-blind person, trying to adapt to a life without color. Unfortunately, our world is dependent on uniformly perfect color vision, and when some can’t meet the standard, a tremendous emotional rift is often created. To bridge this divide, society makes all sorts of accessibility accommodations. Similarly, as testers, we need to be empathetic when we test an application. A common misconception is that accessibility testing is not required if nobody asks for it.

Empathy is the ability to share the feelings of others. Understanding the problems others face is what makes us good at creating/testing products. It’s always easier to develop/test products for people who have the same conditions since we know our requirements and their reasons better than anybody else. Therefore, many successful products are created when people satisfy a real need. 

The problem with applications to suit only our needs is that, in the tech industry, we are practical people of similar ages, abilities, backgrounds, and financial statuses. As a result, we end up creating applications for people just like us, forgetting that other people may have requirements that differ from or even conflict with our own. To create more practical, usable applications, we need to understand and care about diverse needs and adapt our applications to all.

Understanding Accessibility

Accessibility refers to designing applications, devices, services, vehicles, or environments to be usable by people with disabilities. The concept concentrates on enabling people with disabilities through assistive technology: computer screen readers, object detection, special keyboards, etc. Accessibility is about creating usable technology for everyone whether they have a disability or not.

Accessibility must not be confused with usability, which is the extent to which specified users can use an application to achieve established goals with effectiveness, efficiency, and convenience in a specified context of use.

Creating accessible products is not only an ethical choice, it’s also a wise legal choice. There have been examples in many countries where lack of accessibility is considered discriminatory against those unable to access the applications. Therefore, it’s essential to take the legal aspects seriously. 

Web accessibility is often folded into other access and disability discrimination laws. For example, the law you’re most likely to come across is Section 508 in the US. In Europe, they have the European Accessibility Act. 

The legal stuff can seem pretty scary, but standards and guidelines help us generate benchmarks for and manage our work. In addition, guidelines like the Web Content Accessibility Guidelines (WCAG) act as valuable checks at various stages of a website’s creation and maintenance, giving us structure when deciding how to develop a site. 

WCAG has multiple levels of conformance. Each success criteria in the WCAG 2.1 guideline is designed to be testable. To conform to WCAG 2.1, you need to meet these criteria. Each criterion has a level: 

• Level A: the lowest (minimum) level of conformance 
• Level AA: the middle level of conformance, satisfying both Level A and Level AA criteria 
• Level AAA: the highest level of conformance, meeting Level A, Level AA, and Level AAA criteria 
  
  

Accessibility Testing

Without testing, we can’t tell how our application will hold up when used by real people. The success of an application will depend on whether everyone can achieve their goals via their chosen technologies (assistive technologies). 

When we talk about accessibility testing, we must test an interface against a set of guidelines such as the WCAG (mobile). Still, we may also consider any common issues that the WCAG doesn’t cover. For example, if you’ve got your accessibility policy, test your site against the policy’s criteria. Otherwise, the WCAG 2.1 criteria cover a lot of broad use cases. 

We must consider testing the interface against specific tasks, attempting a goal the same way a user would. These tests could also emulate a particular setup, such as someone trying to accomplish assistive technology tasks. As testers, my recommendation is to focus on the following four areas when we plan for accessibility testing.

• Visually – Is it easy to see?
• Audible – Is it easy to hear?
• Motor – Is it easy to interact?
• Cognitive – Is it easy to understand?
  
  

Visual Disabilities

A vast spectrum of disabilities involves eyesight and gives rise to a wide range of needs. For example, visual impairments affect everything we see on the web or mobile applications and benefit from considerate changes to text sizes, typography, and layouts. 

Color blindness has a significant impact on readability and comprehension. Text colors need to be readable against background colors, and because different people perceive color differently, it is unreliable to use color to signify meaning. People with partial eyesight loss need clear labels, readable text sizes, and high contrast between text and background colors. 

As testers, we need to check image text alternatives; people using screen readers can hear the alt text readout, and people who have turned off images to speed download or save bandwidth can see the alt text. Color contrast: some people cannot read the text if there is insufficient contrast between the text and background. Applications should work fine with image text alternatives and when changing text and background color (the text can be read by a screen reader/Braille display or enlarged and reformatted for people with visual disabilities).

Audible Disabilities

People with hearing loss use written and spoken language to read and communicate, making the web a unique tool. Audio content can be inaccessible when alternative ways to hear the content are not in place. People who are deaf sometimes use sign language, mainly if they’ve been profoundly deaf since birth. Unfortunately, there’s a common misperception that sign language is universal and neatly corresponds to spoken language. 

We should check multimedia alternatives for people who are deaf or some people who are hard of hearing. For example, applications must provide alternative formats such as captions and text transcripts. We should test those multimedia alternatives.

Motor Disabilities

Motor disabilities can make the use of standard inputs and outputs difficult. For example, people may struggle to use a mouse, keyboard, or touchscreen device depending on their physical condition and motor control in their arms, hands, and fingers. Motor impairments can also mean that user reaction time is slow: interfaces requiring interaction at a specific time, particularly in games and animations, may result in missed cues. 

We should make sure our application works ideally using assistive technologies or keyboard commands; Accessible applications enable people to access all content and functionality links, forms, media controls, etc., through a keyboard. Also, we should check the basic structure of our application, navigation, main content, and other sections have good headings; it should be more accessible for people to find their way around the information.

Cognitive Disabilities

Cognitive difficulties are pretty diverse, and the way people interact with the applications will vary depending on their condition. For example, consider the challenges of understanding text, remembering tasks, focusing on a large amount of data, difficulty understanding symbols or interpreting visual information.

We should pay special attention to controlling moving content, flashing, or blinking content including carousels, ads, videos, auto-updating stock tickers, scrolling news feeds, and more. Sometimes those points could be hard for people with attention deficit disorder or visual processing disorders.

Final Thoughts

Let’s be empathetic and include accessibility testing in our projects; accessibility is easy to consider once you start caring about it. The key here is to embrace accessibility (Shift Left Accessibility Testing). Think about it while you design, develop and test your applications; remember, let’s keep applications accessible to as many people as possible.

My suggestion to all testers is to please consider talking about accessibility in your teams; let’s work together and keep applications available to all. Also, we should encourage accessibility testing and ensure nobody gets left out. Accessibility can help us to generate a real impact.