The accessibility issues a screen reader will find that you won't

You can look at a page and instantly know what it does. The logo is in the corner, the menu is across the top, the call to action is the big colored button, and the body text is the part with all the words. Your eyes do the sorting before you even think about it.

A screen reader does none of that sorting. It reads what the code says, in the order the code says it, and it announces what the code claims each thing is. When the code is wrong or incomplete, the screen reader faithfully passes that wrongness along to the person listening. That gap, between what you see and what the code actually communicates, is where most accessibility problems hide. You will never spot them by looking, because looking is exactly the sense the page was built to satisfy.

Here is what a screen reader catches that a visual review almost always lets through.

Images that say nothing, or say the wrong thing

A photo of a smiling customer means something to you the moment it loads. To a screen reader, that image is whatever its alt attribute says it is. If the attribute is missing, many screen readers fall back to reading the file name, so a user hears "hero underscore final two v3 dot jpg." If the attribute is an empty string on a meaningful image, the image is skipped entirely and the information is simply gone.

The opposite failure is just as common. Decorative images, dividers, background flourishes, and spacer graphics that carry no information should have empty alt text so they are skipped. Instead they often carry verbose descriptions that interrupt the flow with noise. You cannot see either problem, because to your eyes the picture is just there doing its job. The WAI tutorial on alt text is the clearest reference for deciding which images need a description and which should be silent.

Buttons and links that announce themselves as nothing

Modern interfaces are full of controls built from <div> and <span> elements styled to look like buttons. Visually they are perfect. To assistive technology they are generic containers with no role, no name, and no keyboard behavior. A screen reader user lands on one and hears nothing useful, or cannot reach it at all because a plain div is not in the tab order.

Icon-only controls fail the same way. A magnifying glass that you instantly read as "search" is, to a screen reader, an unlabeled button or worse, an image with no text. The hamburger menu, the close X, the share icon, the play button: every one of these needs an accessible name through real button text, an aria-label, or a visually hidden label. You will never notice the gap because the icon tells your eyes everything. It tells a screen reader nothing.

Reading order that does not match visual order

CSS lets you place elements anywhere on the screen regardless of where they sit in the HTML. That power quietly creates one of the most disorienting screen reader problems there is. A sidebar that visually appears after the main content might come first in the source. A cookie banner pinned to the bottom of the screen might be the very first thing announced. A three column layout might read column one, then jump to column three, then back to column two.

Sighted users never feel this because their eyes follow the visual layout, not the DOM. Screen reader users get the DOM order, full stop. The fix lives in the markup, so the only way to catch it is to experience the page the way the code presents it, top to bottom, in source order.

Form fields with no programmatic label

A form looks complete when every field has a caption sitting next to it. But a visible caption is not the same as a connected label. If the text and the input are not linked through a for and id pairing or a wrapping <label>, the screen reader announces "edit, blank" and the user has no idea what to type. Placeholder text does not solve this either, because it disappears on focus and many screen readers do not treat it as a reliable name.

Error messages have the same disconnect. You see red text appear under a field. A screen reader user hears nothing unless the error is wired up with an accessible relationship and an announcement, so they submit the form again and again with no idea what went wrong. The MDN guide to accessible forms walks through the label and error patterns that actually reach assistive technology.

Headings that lie about structure

Screen reader users navigate by headings constantly. It is one of the fastest ways to move through a page, the equivalent of skimming with your eyes. That only works when the heading levels describe a real outline. If a designer picked an <h4> because it looked the right size, or wrapped a whole paragraph in an <h2> to make it bold, the outline collapses. Jumping from <h1> straight to <h3>, or scattering heading tags purely for styling, turns the navigation map into nonsense.

You will never see this. The page looks beautifully typeset either way. The hierarchy lives entirely in the tag names, and the only audience for those tag names is the assistive technology reading them out as a table of contents.

Dynamic updates that happen in silence

Single page apps update content all the time without a full reload. A filter narrows a product list, a toast says "saved," a counter ticks up, a validation message appears. Your eyes catch every one of these changes because something on screen moved. A screen reader announces a change only if the region is marked as a live region or focus is deliberately moved to the new content.

Without that wiring, the page changes underneath a screen reader user with zero feedback. They tap "add to cart" and hear nothing, so they tap again. They submit a search and the results quietly replace the old ones while their cursor sits somewhere else entirely. This is one of the most common and most invisible failures in any interactive interface, and a visual review will pass it every single time.

Why automated checks and human review both matter

A scanner can find a huge share of these problems fast: missing alt attributes, unlabeled form fields, broken heading order, controls with no accessible name, insufficient color contrast. These are the issues that have a clear right answer in the code, and they are exactly the ones a quick visual pass skips. The WCAG 2.2 standard is the reference these checks map back to.

Automated tooling will not judge whether your alt text is actually meaningful or whether your reading order makes sense to a human, and it should not pretend to. But it will surface the structural failures that block a screen reader before they ever reach a real user, and it will do it in seconds across an entire page.

The accessibility checker in AcuityScan's free tools tests a page against these structural rules and reports exactly what assistive technology would struggle with: images with no text alternative, controls with no accessible name, fields with no programmatic label, and heading levels that skip. It runs as one of more than 350 checks across 8 modules in the full site scan, so accessibility gets evaluated alongside performance, security headers, and email deliverability in a single pass.

Run the page you are most confident about. The screen reader does not care how good it looks, and that is the entire point.