Access testing checks whether a website or app works for people with disabilities

Access testing is the process of examining a website, app, or digital tool to see whether someone with a disability can use it the same way anyone else can. A tester might be blind and use a screen reader that reads text aloud, or have limited hand mobility and navigate using only a keyboard. The goal is to find places where the design breaks down for these users — buttons that can't be clicked without a mouse, images with no text description, videos with no captions, or text so small it can't be enlarged.

Access testing is different from regular quality testing, which checks whether features work as intended for the average user. Access testing asks a harder question: does this work for everyone, including people whose eyes, ears, hands, or cognitive abilities differ from the majority? Companies do this testing because it's often legally required, because it reaches more customers, and because it's the right thing to do.

Key Takeaways

  • Access testing checks whether people with disabilities can use a website or app as fully as anyone else, using assistive technology like screen readers or keyboard-only navigation.
  • Testers look for specific barriers: missing image descriptions, videos without captions, buttons that don't work with keyboards, text that can't be resized, and color combinations that are hard to read.
  • Many companies hire both automated tools that scan for common problems and human testers with disabilities who use the product the way real users would.
  • Access testing is required by law in many countries for government websites and increasingly for commercial sites, and it also helps companies reach customers they might otherwise lose.

How access testing actually works

Access testing usually happens in two ways. First, companies run automated tools — software that scans a website or app and flags common problems like missing alt text on images, poor color contrast, or heading tags that are out of order. These tools are fast and cheap, but they catch only about 30 percent of real problems. A missing alt text shows up; a confusing navigation structure that makes sense to sighted users but confuses someone using a screen reader does not.

That's why the second part matters: human testing with real users. A company hires testers who are blind, deaf, have limited mobility, or have cognitive disabilities, and watches them try to complete actual tasks on the site. Can they find the contact form? Can they buy something? Can they read the privacy policy? The tester uses whatever assistive technology they normally use — a screen reader, voice control software, a switch device, or just a keyboard. When they get stuck, that's a bug.

Some companies do this testing before launch, some after, and the best ones do both. Testing early catches problems when they're cheap to fix. Testing after launch with real users catches the problems the designers didn't think to look for.

What testers look for

Access testers check for barriers across several categories. Vision barriers include images without descriptions, text that can't be enlarged, color combinations that are too similar to read, and content that only makes sense visually. A chart showing sales trends needs a text description or data table, not just a picture.

Hearing barriers include videos without captions or transcripts, and audio content with no text alternative. A podcast episode needs a transcript. A video needs captions, not just because deaf users need them, but because someone in a noisy coffee shop or a quiet office does too.

Mobility barriers include buttons and links that are too small to click, forms that require a mouse, and pages that don't work with keyboard navigation alone. A person with limited hand control might use voice commands or a single switch, and the site has to work with those tools.

Cognitive barriers include confusing navigation, jargon without explanation, flashing content that causes seizures, and layouts so cluttered that finding anything is exhausting. A person with dyslexia needs clear headings, short paragraphs, and the ability to change fonts and spacing.

Who does access testing and when

Large companies often have dedicated accessibility teams. Smaller companies might hire a consultant to test once a year or before a major redesign. Government agencies are required by law in most countries to do access testing — in the United States, the standard is the Web Content Accessibility Guidelines, or WCAG, which is also used as a baseline in Europe, Canada, and Australia.

Many companies test only when they have to, or only on the main pages. The best practice is continuous testing: checking new features as they're built, not waiting until launch. Some companies hire people with disabilities as permanent staff, not just as testers, because they catch problems that outsiders miss.

The timing matters too. Testing a website after it's been live for three years is better than never testing, but it means fixing problems is expensive. Testing during design — before code is written — is cheapest and fastest.

Why companies do access testing

The legal reason is straightforward: in the United States, the Americans with Disabilities Act requires government websites and increasingly applies to commercial sites. The European Union's Accessibility Directive requires all public sector websites and many private ones. Canada, Australia, and other countries have similar laws. Violating these laws can result in lawsuits and fines.

But there's a business reason too. About one in four adults in the United States has some kind of disability. That's not a small market. A person who is blind might not visit your site at all if it doesn't work with a screen reader. Someone with low vision might leave if text can't be enlarged. Someone with dyslexia might struggle with your font choice. Making your site accessible means more people can use it, which means more customers.

There's also a spillover benefit: many accessibility features help everyone. Captions on videos help people in noisy places. Large, clear text helps older users. Keyboard navigation helps people whose mouse is broken. Good color contrast helps people viewing on a phone in bright sunlight. Access testing often makes a site better for everyone.

The difference between automated testing and human testing

Automated tools are fast and find obvious problems. They can scan thousands of pages in minutes and flag missing alt text, poor contrast, missing form labels, and broken heading structures. They're also cheap — many are free or cost less than hiring a person for a day.

But they miss the real-world experience. An automated tool can't tell whether a screen reader user can actually navigate your site, whether your form makes sense when read aloud, or whether your design is so cluttered that someone with cognitive disabilities gives up. A tool sees code; a human sees whether the code actually works for a real person trying to do something.

The best approach combines both. Run automated tools first to catch the low-hanging fruit, then hire human testers to find the problems that matter most — the ones that actually stop people from using your site.

Common misconceptions about access testing

One misconception is that access testing is only for blind users. In reality, disabilities are diverse. A site can be perfect for screen reader users but unusable for someone with limited hand mobility, or great for deaf users but confusing for someone with ADHD. Good access testing covers all kinds of disabilities.

Another misconception is that accessible sites look boring or stripped-down. An accessible site can be beautiful, colorful, and engaging. It just needs to work for more people. Good design is good design — it's clear, it's organized, and it doesn't rely on one sense or one way of interacting.

A third misconception is that access testing is a one-time thing. Websites change constantly. New features get added, designs get updated, content gets refreshed. Each change is a chance to break something for someone with a disability. Access testing needs to happen regularly, not just once.

Frequently Asked Questions

Does access testing slow down development?

Testing early actually speeds things up. Finding and fixing an accessibility problem during design costs far less than fixing it after launch. Automated tools take minutes. Human testing takes a day or two. Building inaccessible features and then rewriting them takes weeks.

What's the difference between WCAG and other accessibility standards?

WCAG (Web Content Accessibility Guidelines) is the most widely used standard worldwide. It's created by the W3C, a nonprofit that sets web standards. Other standards exist — Section 508 in the US, EN 301 549 in Europe — but they're mostly based on WCAG. If your site meets WCAG, it usually meets the others too.

Can a website be 100 percent accessible?

No, but it can be very accessible. Accessibility is a spectrum, not a checkbox. A site can meet all WCAG standards and still have edge cases that don't work for someone. The goal is to remove barriers for as many people as possible, not to achieve perfection.

Who pays for access testing?

The company that owns the website pays. It's part of development costs, like testing for bugs or security. Some companies budget for it; others treat it as an afterthought. Legal requirements in many countries mean companies have to budget for it whether they want to or not.

Can I test my own website for accessibility?

You can run automated tools yourself for free — WAVE, Axe, and Lighthouse are all available online. But you can't fully test your own site the way a person with a disability would. You don't know what it's like to use a screen reader if you've never used one. Hiring someone to test is worth the cost.