Accessibility testing is how you find out whether people using assistive technology can actually read what you published. It works in three passes: an automated scan that catches mechanical failures, manual checks that catch what software cannot see, and a screen-reader run that confirms the whole thing holds together for someone who cannot look at the page at all. None of the passes is optional, because each one finds failures the others miss.
The good news is that the first pass takes minutes, and the third one is less mysterious than it sounds. This tutorial walks through all three, plus the common failures worth checking for first. If you publish e-books or websites, the same logic applies to both, though the tools differ. For related coverage, see How Can Deaf Readers Get The Audio Side Of Books?.
What are you actually testing for?
Accessibility, as Wikipedia defines it, is the design of products, services, or environments to be usable by disabled people, including compatibility with assistive technology such as screen readers. Testing simply measures how far your content falls short of that. On the web, the yardstick is usually the Web Content Accessibility Guidelines, or WCAG, which government mandates such as the Section 508 Amendment to the Rehabilitation Act reference as a standard. You do not need to memorize the guidelines to test against them. You need to know the handful of failures they care about most.
Those failures cluster around six elements. As Texas A&M's eSAIL tutorial lays out, the fundamentals are links, contrast and color, headings, alt text for images, tables, and closed captions. Check those six before anything else, because they account for the bulk of real-world barriers.
What can an automated scan catch, and what can't it?
Automated checkers crawl a page or file and flag rule violations: images missing alt text, form fields without labels, text contrast below the threshold, empty headings. Run one first. It is fast, it is cheap, and it catches the mechanical problems reliably.
Its limits matter just as much. A checker can tell that an image has alt text; it cannot tell whether the alt text says anything useful. It can confirm that headings exist; it cannot confirm they are in a sensible order. MDN's accessibility documentation frames tooling this way: the tools help you find and repair issues, but they sit alongside, not instead of, the assistive technologies real people use. Treat the scan as a to-do list generator, not a verdict.
Which manual checks should every beginner run?
Manual testing means using the content the way a disabled reader might, without the assistive software. Start with these:
- Keyboard only. Unplug the mouse. Tab through the page. Can you reach every link and button? Is the focus visible at all times? Can you escape any menu you open?
- Zoom. Enlarge the text substantially. Does anything overlap, clip, or vanish?
- Color. Text needs sufficient contrast with its background — eSAIL cites a 4.5:1 ratio — and color alone must never carry meaning. If your error message is only distinguishable by its red tint, it fails.
- Links out of context. Read your links aloud without the surrounding sentence. "Click here" tells a screen-reader user nothing. The destination should be clear from the link text alone.
- Tables and headings. Tables should hold data, not layout, and include header rows. Headings should form a logical outline, not jump levels for visual effect.
Each check takes a few minutes once you know what you are looking for. Together they cover most of what an automated scan cannot judge.
How do you test with a screen reader?
A screen reader is software that speaks, or outputs in braille, what is on screen. Every major platform ships one: NVDA on Windows, VoiceOver on Apple devices, TalkBack on Android. MDN notes that these assistive technologies are what people with disabilities actually use to browse, which is why the final pass should happen through one of them.
The beginner's method is simple. Turn the screen reader on, close your eyes if you dare, and try to complete one real task: find a chapter, buy a book, fill in a form. Listen for three things. First, does the screen reader announce headings and landmarks, so you can navigate by structure rather than tabbing through everything? Second, do images get described, or does the reader skip them or announce a filename? Third, does anything update on screen without being announced, such as a cart total or a validation error? Dynamic content that changes silently is one of the most common failures, and only a screen-reader pass surfaces it.
You do not need to become a screen-reader power user. You need to borrow the perspective for twenty minutes, and the disorientation you feel is often the point.
What are the most common failures to catch first?
Across audits, the same failures recur. Before running any tool, skim for these:
- Images with no text alternative, or alt text that repeats the caption or says "image of."
- Low-contrast text, especially light gray on white.
- Vague link text — "read more," bare URLs, "click here."
- Headings used for visual styling rather than structure.
- Videos without captions. eSAIL notes captions were created for deaf and hard-of-hearing viewers but help everyone, from people in noisy rooms to second-language learners.
- Tables with merged or empty cells, used for page layout.
Fixing these six categories resolves most of what a beginner's audit will find. Everything else can wait for experience.
Our analysis: where should a publisher start?
Our analysis, reading the guidance above against a publishing workflow: start with the file you publish most, not the whole backlist. Run the automated checker, fix the six fundamentals, then do one screen-reader pass on a single representative title. That sequence turns an intimidating standard into an afternoon's work, and it catches the failures that matter to actual readers first. For e-book authors specifically, the same fundamentals — alt text, heading structure, meaningful links — carry over into EPUB, and our checklist on what indie authors should check before publishing an accessible EPUB covers that side in detail. This connects to our earlier piece, What Should Indie Authors Check Before Publishing An Accessible EPUB?.
One honest caveat: testing tells you what is broken, not whether your fixes worked for every reader. Standards evolve, tools improve, and real users will find things no audit does. Treat testing as a habit, not a milestone — and when you are ready to go deeper, our guides on alt text for e-books and which checker tools catch real problems pick up where this tutorial stops.
