Close your eyes for thirty seconds and try to buy a pair of running shoes on your phone.
You can't see where the checkout button is. You can't see the price tag, whether the shoes are in stock, or what color you selected. Instead, a robotic synthetic voice speaks into your headphones at 350 words per minute, announcing what is currently underneath your finger or keyboard cursor.
That voice comes from software called a screen reader.
For over 300 million people worldwide who are blind, visually impaired, or have cognitive disabilities, screen readers are their eyes on the web. On Windows PCs, millions use free software called NVDA or enterprise software called JAWS. On iPhones, iPads, and MacBooks, Apple includes a built-in screen reader called VoiceOver. On Android phones, it is called TalkBack.
When a website is built cleanly, a screen reader glides through it effortlessly. But when a website is built with messy code, missing labels, and broken buttons, the screen reader experience feels like trying to read a textbook with half the pages torn out and the rest glued together upside down.
Here is what happens behind the scenes, and the three simple fixes that make an immediate difference.
How a Screen Reader Actually "Sees" a Webpage
A common misconception is that screen readers use optical character recognition (OCR) or scan the visual screen like a human eye. They do not.
A screen reader ignores visual styling, CSS colors, drop shadows, and layout columns. Instead, it reads the underlying code—specifically the HTML structure and the browser's Accessibility Tree.
If an element has no name in the code, the screen reader cannot tell the user what it does.
Here is a real example of what a screen reader user hears on a typical modern website:
"Unlabeled button. Link, click here. Image graphic 84930_final.jpg. Heading level four. Unlabeled button."
Imagine trying to enter your credit card number on a page that only announces "Unlabeled button." You have no idea if that button submits your order, deletes your cart, or signs you out. Most users simply abandon the tab and take their business to an accessible competitor.
Why Missing Screen Reader Support Triggers ADA Lawsuits
Under ADA Title III (the Americans with Disabilities Act) and the international WCAG 2.1 & 2.2 standards (Web Content Accessibility Guidelines), websites are legally considered places of public accommodation.
When a digital storefront or portal blocks a screen reader user from reading the terms, finding a phone number, or checking out, it is legally identical to locking the front doors of a brick-and-mortar retail store to wheelchair users. In fact, over 80% of federal website accessibility lawsuits cite basic screen reader failures—such as missing image descriptions or unlabelled form inputs—as the primary legal violation.
You do not need to rewrite your entire codebase to fix the vast majority of these issues. You just need to follow three fundamental rules.
Fix 1: Write Descriptive Alt Text (Alternative Text)
When you upload an image to your CMS or website, your software usually asks for Alt Text (short for alternative text).
Alt text is a short text snippet written in the HTML alt="..." attribute. It is invisible to sighted visitors, but when a screen reader encounters the image, it reads that text aloud.
- The Mistake: Leaving the alt text blank, or letting the CMS default to the file name (
IMG_20261021_0942.png). The screen reader reads out the raw filename, which is annoying and useless. - Another Mistake: Keyword stuffing (
alt="best cheap running shoes buy running shoes online sale"). This confuses blind users and can actually hurt your SEO. - The Correct Way: Describe the actual meaning of the image in one simple sentence. For example:
alt="Navy blue waterproof hiking boot shown from the side angle with orange laces".
If an image is purely decorative—like an abstract background wave or a divider line—leave the alt tag empty (alt=""). That tells the screen reader to skip it entirely so the user doesn't waste time hearing about visual decoration.
Fix 2: Keep Your Headings in Logical Order
Screen reader users rarely read a webpage from top to bottom like a novel. Instead, they press keyboard shortcuts (like tapping the H key) to quickly jump from heading to heading to scan the page.
Think of headings (<h1>, <h2>, <h3>) like the table of contents in a non-fiction book:
- Your page should have only one
<h1>tag (the main title of the page). - Major sections use
<h2>. - Sub-points inside an
<h2>section use<h3>.
A frequent mistake occurs when a content editor picks a heading tag purely because they like its font size. For example, jumping straight from an <h1> to an <h4> because the <h4> looks smaller and neater. When a screen reader user hears "Heading Level 4" right after "Heading Level 1", they assume they accidentally skipped two major sections of your article.
Always use CSS to style font sizes, and use HTML headings to define the actual outline of your content.
Fix 3: Give Every Button and Link a Meaningful Name
Screen readers have a feature that lets users pull up a pop-up list of every link on the page so they can quickly jump to what they need.
If your links say:
- "Click here"
- "Read more"
- "Learn more"
- "Download"
That list becomes completely useless out of context:
Link: Click here.
Link: Click here.
Link: Click here.
Link: Read more.
Which one downloads the pricing PDF? Which one opens the privacy policy? Nobody knows.
Instead, write descriptive link text that explains where the user is going:
- "Read our 30-day return policy"
- "Download the VPAT 2.5 compliance template (PDF)"
- "Schedule a product demo"
Similarly, icon-only buttons—such as a magnifying glass for search, a shopping cart icon, or a mobile hamburger menu—must have an accessible name using standard HTML or an aria-label (e.g., aria-label="Search AccessiLens documentation"). Without that label, the screen reader has nothing to speak except "Button."
How to Test Your Website Right Now for Free
You do not need specialized hardware or expensive software to test your website:
- On a Mac: Press Command + F5 to turn on Apple VoiceOver. Put your mouse away, and navigate your website using only your keyboard's Tab key and Control + Option + Arrow keys.
- On an iPhone: Go to Settings > Accessibility > VoiceOver and toggle it on. Swipe left and right with one finger to hear how iOS reads each element of your app or mobile site.
- On Windows: Download NVDA (NonVisual Desktop Access), which is completely free and open-source, and test your pages in Chrome or Firefox.
Spending fifteen minutes testing your site with a screen reader will show you more usability barriers than any high-level design review ever could.
Once you fix the basic structure, your website becomes faster, easier to navigate for search engines, and truly welcoming to everyone.
