Accessibility testing for technology products: a primer

Types of Accessibility Issues

In the broader disability community, individuals may have a variety of needs. As a result, “accessibility” is not one concept. While defining all accessibility is not possible in one blog post, we’ve outlined the primary categories that technology builders should be aware of.

Visual

Most people with vision difficulties need either magnification or contrast changes so they can see what’s on a computer screen. This may include things like a screen magnifier or braille display. 

People with blindness or full vision loss may need alternative navigation features that don’t rely on seeing a screen and navigating with a mouse. This may include voice controls, using a screen reader, and including alt text for images so a screen reader can easily describe the image to a user.  

Vision difficulties and issues run on a spectrum. On one end, you have people with full vision who do not need any visual aids. On the other end, completely blind individuals cannot see anything and need to experience the world in a more tactile or auditory way. Within the vision spectrum there are conditions such as vision impairment, low vision, color blindness, and legal blindness. 

Mobility 

People with mobility difficulties or disabilities need alternative navigation features such as sip and puff, Grid 3 controls, or a switch system. Pages with clear navigation including headings and subheadings will help here as well, since alternative navigation features typically work in a highly structured way.  

Mobility issues in technology revolve around whether a person can use traditional computer navigation and control devices. Mobility challenges include a variety of things such as the inability to use one’s hands fully (due to carpal tunnel syndrome, amputation, or other loss of use) all the way to partial or full paralysis. 

Auditory 

People with auditory disabilities need different ways to engage with any audio-specific elements of a technology, which could just mean the ability to control volumes (if someone has hearing loss or difficulties). People who are deaf or have full hearing loss will need subtitles or closed captioning to understand audio or video presented formats.  

Auditory disabilities are on a spectrum, like visual disabilities, and run from being hard of hearing to complete deafness or deafblindness. 

Seizures 

People who have seizure conditions need the ability to control the user experience in a simple dashboard environment before entering the main user experience. This could mean the ability to modulate color and contrast (for instance, moving to “dark mode”) and the ability to turn off any bright, fast-moving, or flashing features before being exposed to them. 

Seizures are often triggered by things such as flashing lights, fast-moving objects, or other interactive elements common in some websites and software. For a user with epilepsy or similar seizure condition, even regular interactive features can evoke a response. 

Cognitive 

Technology builders should use dyslexia-friendly fonts with sharp contrast to ensure all words stand out clearly on the page. Further, marketing and product teams should use concise, simple copy that is easy for users to understand in both on-page instructions and help documents. The use of visual or audio aids – screenshots or videos with subtitles – can also help users with cognitive impairment get the outcome they need.  

In a software user context, cognitive disabilities include light sensitivity or migraines, autism, and dyslexia. These disabilities hinder someone from engaging with the full, or even partial, experience of a technology due to how their brain processes information. 

Manual vs. Automated Accessibility Testing

Both manual and automated accessibility testing have their place. Here’s what each does best and when to use them in your technology building process.  

Manual accessibility testing 

Manual accessibility testing is when humans look through the platform – both frontend and backend – to see if it is accessible.

This can take the form of in-house quality assurance (QA) checks that also consider accessibility, software testing groups for accessibility features, or real-life outcome testing within the disability community.   

The benefit of manual testing is you get a human perspective, which helps serve the goal of building technology humans can use. The downside is that running these groups can be expensive and manual testing does not scale well. 

Automated accessibility testing 

Automated accessibility testing is when you use specific tools to help you gauge how accessible your technology is. Usually, these tools focus on specific code stacks and can help find errors or problems that might lead to the final product being inaccessible.

The benefit of automated tools is both the time savings and scalability. These tools can guide human effort to make the process more efficient. However, these tools cannot always guarantee that your software will work for people with disabilities, so manual (human) testing is likely still needed.  

Why Accessibility is Critical to Your Business

On top of building a more usable and scalable product, accessibility is also important to the business overall.

• Market access: People with disabilities influence trillions of dollars in disposable income annually but can’t use your products (and won’t buy them) if they are not accessible.
• Deeper talent pools: When you build in an accessible way, it means you can access millions of talented people with disabilities to bring onto your team as freelancers, contractors, or full-time hires.
• Values alignment: Accessibility aligns with most corporate value statements whether it’s a commitment to delivering customer value, a commitment to diversity, or a simply a commitment to building the best products possible.

Practical Guidelines for Accessibility

Building for accessibility in your products and overall business doesn’t need to be complicated. Here are a few practical things to keep in mind.  

Accessibility spans across all digital architecture: Think about your websites, client portals, internal wikis, employee hubs, and more.  

Think about goal achievement, not compliance: Accessibility means people with disabilities can achieve the same outcome from your product as people who don’t need any accommodations. 

Integrate accessibility into regular operations: Outside of product, also ensure that accessibility concepts – like simple architecture and offering multiple (written, audio, and visual) ways to explain a task – flow throughout your HR systems, performance management systems, and marketing and sales language.