Accessibility testing for technology products: a primer


Accessibility is a critical part of all technology.

Not only are there over one billion people with disabilities – 15% of the world’s population – they influence over $13 trillion in annual disposable income for themselves and their families. Beyond that, accessibility is a legal standard set in multiple countries including the Accessible Canada Act in Canada, Americans with Disabilities Act (ADA) in the United States, and other web-specific accessibility laws globally.

But how do you build with accessibility in mind? In short, you test for it – that’s where accessibility testing comes in. 

Blind man with light brown skin holds a smartphone in front of him. He wears opaque black sunglasses, a flat cap and holds a white cane.
A white blind person with long hair sits with their service dog. The person wears sunglasses.

What Is Accessibility Testing?

Accessibility testing is the process of verifying your technology (website, app, etc.) is usable by people with disabilities. 

This typically happens on two distinct levels:  

  • Compliance: Ensuring your technology is built to follow legal accessibility minimums. 
  • Function parity: Ensuring a person with disabilities can achieve the same outcomes from your platform as someone who doesn’t need accessible accommodation.

At Fable, we believe function parity should be the goal of accessibility testing because we believe all technology should be accessible for all users in real life, not just to the letter of the law. 

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.


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. 


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. 


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. 


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. 


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. 

Benefits of Accessibility Testing

Accessibility testing not only helps build high quality technology products, but it also helps with:  

Finding platform bugs: When you run an accessibility test, you go through both the backend and frontend of a technology. This process alone can help you uncover bugs in the codebase before it goes into production.  

Setting up scalable architecture: Many accessibility features rely on well-structured page and system architecture (since that’s how most assistive devices understand web or software pages). This means building for accessibility also means building with more scalable infrastructure from the start. 

Reducing tech debt: Adding accessibility features after the fact is a costly process that, in some cases, can mean ripping and re-building your whole platform. Starting with accessibility sets you up for the future with a relatively minimal investment.