Access testing checks whether software and websites work for people with disabilities

Access testing is the process of checking whether a program, website, or device works for people who have disabilities. It means testing with screen readers (software that reads text aloud), keyboard-only navigation, high-contrast displays, and other assistive tools that real people use every day. A website or app passes access testing when someone using a screen reader can find information just as easily as someone using a mouse, or when someone who cannot see colors can still read text that matters.

Access testing is not a single test you run once. It is a series of checks done by real people and by automated tools, looking for problems that make software unusable for specific groups. A button that looks clickable on screen might be invisible to a screen reader. Text might be too small for someone with low vision. A video might have no captions for someone who is deaf. Access testing finds these problems before the software reaches you.

The reason this matters to you is simple: if you ever lose your vision temporarily (eye surgery, infection), break your arm, or develop hearing loss, you will want the software you rely on to still work. Access testing also helps people who are older, people in noisy environments, and people using devices on slow internet connections. It is not a feature for a small group — it is a foundation that makes software work better for everyone.

Key Takeaways

  • Access testing checks whether people with disabilities can use software, websites, and devices without barriers.
  • Real people using assistive tools like screen readers and keyboard navigation are part of the testing process, not just automated scans.
  • Common problems found in access testing include missing captions on videos, text too small to read, and buttons that screen readers cannot identify.
  • Access testing happens throughout development, not as a final check before release.
  • Standards like WCAG (Web Content Accessibility Guidelines) give testers a checklist of what to look for.

How access testing actually works in practice

Access testing combines two approaches: automated scanning and human testing. Automated tools scan code and flag obvious problems — missing image descriptions, missing form labels, color contrast that is too low. These tools are fast and catch many issues, but they miss context. A tool cannot tell whether a button labeled "submit" actually does what a user expects, or whether instructions make sense to someone using a screen reader.

Human testers then use the software the way people with disabilities actually do. A tester might navigate a website using only the keyboard, never touching the mouse. Another might use a screen reader like NVDA (free) or JAWS (paid) to hear what the website says aloud. A third might zoom the text to 200% to see whether the layout breaks. These testers have real experience with disabilities — many are disabled themselves — and they know what works and what does not.

The tester documents every problem: where it is, what happens, and why it matters. A missing image description might seem small, but if that image is a chart showing your bank balance, it is a serious problem. The development team then fixes the issues, and testing happens again to confirm the fixes work.

Common problems access testing finds

Videos without captions are one of the most frequent problems. Someone who is deaf cannot hear dialogue or sound effects. Someone in a noisy coffee shop cannot hear the audio either. Captions help both groups. The same is true for transcripts — a written version of what someone says in a video or podcast.

Images without descriptions are another major issue. A screen reader user hears nothing when it encounters an image, or it reads the filename ("image_2024_03_15.jpg") instead of what the image shows. If the image is decorative, that is fine — the tester marks it as decorative so the screen reader skips it. If the image contains information, the description needs to convey that information in words.

Color alone as the only way to show information is a third common problem. A chart that shows profit in green and loss in red is invisible to someone who is colorblind. The chart needs labels, patterns, or text to show the difference. Buttons that look clickable to you might not be identifiable to a screen reader if they are not coded correctly. A form field might have a label visible on screen but no label in the code, so a screen reader user does not know what to type.

Text that is too small, links that are too close together, or instructions that assume you can see the screen all create barriers. Access testing finds these problems and gives developers concrete steps to fix them.

Standards and guidelines that guide access testing

WCAG (Web Content Accessibility Guidelines) is the most widely used standard. It is published by the W3C, a nonprofit that sets web standards. WCAG has three levels: A (basic), AA (standard), and AAA (enhanced). Most organizations aim for AA, which covers the most common barriers without requiring extreme effort. WCAG covers websites and web applications.

For software that runs on your computer or phone, Section 508 (in the United States) and similar laws in other countries set requirements. These standards say that government agencies must buy software that is accessible, which pushes private companies to meet the same standards.

The standards are not perfect — they do not catch every real-world problem, and they do not replace human testing. But they give testers a checklist and give developers a target. A website that meets WCAG AA is far more usable for people with disabilities than one that does not, even if it is not perfect.

Why companies do access testing

Some companies do access testing because the law requires it. Government agencies in the United States must follow Section 508. Schools and universities must follow similar rules. Companies that do business with the government must meet these standards too.

Other companies do it because it is good business. A website that works for people with disabilities also works better for older people, people on slow internet, people using phones in sunlight, and people in noisy places. Captions help people learning English. Keyboard navigation helps people with broken arms. Large text helps people with presbyopia (age-related vision loss). The overlap is huge.

Some companies do it because they believe it is the right thing to do. People with disabilities are customers, employees, and community members. Software that excludes them is software that does not work for everyone.

The difference between access testing and usability testing

Usability testing checks whether software is easy to use for the people it was designed for. Access testing checks whether it works for people with disabilities. These are related but different. A website might be usable for a sighted person with a mouse but completely unusable for someone who is blind. Access testing catches that problem.

A good development process does both. Usability testing makes sure the software works for the main audience. Access testing makes sure it works for everyone. The best software passes both kinds of testing.

What happens after access testing finds problems

When testing finds a problem, the development team gets a detailed report. The report says what the problem is, where it is, how serious it is, and what the standard says should happen instead. A missing image description might be marked as medium priority — it is a real problem but not blocking. A button that cannot be activated with a keyboard might be marked as high priority — it makes the software unusable for some people.

The team then fixes the problems in order of priority. After fixes are made, the same tests run again to confirm the problems are actually solved. Sometimes a fix creates a new problem, so testing is iterative — it happens multiple times as the software improves.

For ongoing software (websites, apps that get updates), access testing becomes part of the regular process. Every new feature gets tested before it ships. This prevents new barriers from creeping in as the software evolves.

Frequently Asked Questions

Does access testing mean the software is perfect for people with disabilities?

No. Access testing catches many barriers, but it cannot catch everything. Automated tools miss context. Human testers cannot test every possible disability or every combination of assistive tools. A website that passes access testing is far more usable than one that does not, but real people with disabilities may still find problems that testers missed.

Who does access testing — the company that made the software or someone else?

Both. Some companies have internal teams that do access testing. Others hire outside firms that specialize in it. The best approach uses both: internal testing catches obvious problems early, and outside testers bring fresh eyes and real-world experience with disabilities.

How much does access testing cost?

It varies widely. Automated scanning tools range from free to hundreds of dollars per month. Human testing by specialists costs more — a full access audit of a website might cost thousands of dollars. But the cost of fixing problems after launch is usually higher, so testing early saves money overall.

Can I test my own website for access problems?

You can run automated scans yourself using free tools like WAVE or Lighthouse. You can also download a free screen reader like NVDA and try navigating your site. These catch many problems. But human testing by someone with real experience using assistive tools will find problems that you miss, because you are not used to navigating the way they do.

What is the difference between access testing and compliance testing?

Compliance testing checks whether software meets a specific standard like WCAG or Section 508. Access testing is broader — it checks whether the software actually works for people with disabilities, which includes but goes beyond compliance. A website can be compliant on paper but still difficult to use in practice.