Screen Reader Accessibility: How to Make Your Website Work for Users Who Cannot See It

Close your eyes and try to use your favorite website. You cannot see the layout, the colors, the images, or the navigation bar. You can only hear what the page sounds like when it is read aloud, one element at a time, from top to bottom. Can you figure out where you are? Can you find the information you need? Can you fill out a form, buy a product, or contact the company?

This is what using the web is like for someone who is blind or has low vision. They rely on software called a screen reader to interact with websites. And far too often, the experience is frustrating or impossible because the site was not built with screen reader users in mind.

Screen reader accessibility is one of the most important and most frequently overlooked areas of web accessibility. In this guide, we will explain what screen readers are, how they work with web content, what WCAG requires, and the specific steps you can take to ensure your site works for users who cannot see it.

A screen reader is a software application that converts the content of a computer screen into spoken language or braille output. It allows people who are blind or have low vision to use computers, smartphones, and websites without needing to see the screen.

Screen readers do not just read text. They interpret the structure and meaning of a web page and present it in a way that makes sense without visual context. They announce headings, links, buttons, form fields, images, lists, tables, and other elements, giving the user a mental model of the page.

Common Screen Readers

There are several widely used screen readers, each with its own strengths and characteristics:

JAWS (Job Access With Speech): A commercial screen reader for Windows, widely used in workplace and government settings. JAWS is powerful and feature rich, but it is expensive and has a steeper learning curve.
NVDA (NonVisual Desktop Access): A free, open source screen reader for Windows. NVDA is extremely popular because it is free and actively maintained. Many accessibility testers use NVDA as their primary testing tool.
VoiceOver: The built in screen reader for macOS and iOS. Because it comes free with every Apple device, VoiceOver has introduced many people to screen reader technology for the first time.
TalkBack: The built in screen reader for Android devices. Like VoiceOver, it comes preinstalled and is free to use.
Narrator: The built in screen reader for Windows. While historically less capable than JAWS or NVDA, it has improved significantly in recent years.

Each screen reader has its own commands, gestures, and quirks. A site that works perfectly with NVDA might have issues with JAWS, or vice versa. This is why testing with multiple screen readers is important for thorough accessibility work.

Who Uses Screen Readers?

Screen readers are used by a diverse group of people:

People who are blind rely on screen readers as their primary way of accessing digital content. For them, a website that does not work with a screen reader is completely inaccessible.
People with low vision may use screen readers in combination with screen magnification software. Some users switch between magnifying the screen and having content read aloud depending on the task.
People with cognitive disabilities sometimes use screen readers to have text read aloud, even if they can see the screen. Hearing text spoken can help with comprehension and focus.
People with motor disabilities who cannot use a mouse may use screen readers with keyboard commands to navigate efficiently.

Understanding this audience is the first step toward building websites that work for them.

How Screen Readers Interact With Web Content

To make your site accessible to screen readers, you need to understand how they process and present web content. Screen readers do not read a page the way a sighted person scans it visually. They interact with the HTML structure and use it to build a nonvisual representation of the page.

When a sighted user lands on a page, they take in the entire layout at a glance. They can see the header, the navigation menu, the main content area, the sidebar, and the footer all at once. They can quickly identify where the important content is and skip to it.

A screen reader user cannot do this. The screen reader reads the page in a linear fashion, one element at a time, typically from top to bottom. The user has no overview of the page. They experience it sequentially, building a mental model piece by piece.

This means the order and structure of your HTML matters enormously. If your HTML is well organized, the screen reader will present content in a logical sequence. If it is not, the user will encounter confusion, repetition, and dead ends.

Screen readers offer shortcuts that let users jump between specific types of elements. For example, a user can:

Press a key to jump to the next heading.
Press a key to jump to the next link.
Press a key to jump to the next form field.
Press a key to jump to the next list.
Press a key to jump to the next table.
Pull up a list of all headings on the page and jump directly to one.
Pull up a list of all links on the page and choose one.

These navigation shortcuts are how screen reader users efficiently move through a page without listening to every word. If your headings, links, and landmarks are properly structured, users can quickly find what they need. If they are not, users are forced to listen to the entire page linearly, which is slow and frustrating.

Modern screen readers can navigate by HTML5 landmarks. Landmarks are elements like <header>, <nav>, <main>, <article>, <aside>, and <footer> that define regions of the page. Screen readers announce these regions and let users jump between them.

For example, a screen reader user might hear “main region, navigation region, complementary region” and can jump directly to the main content. Without landmarks, the user has to tab through everything to find where the main content begins.

Virtual Buffer

Most desktop screen readers use something called a virtual buffer. When a page loads, the screen reader captures a snapshot of the page’s HTML and presents it to the user. The user navigates through this buffer using screen reader commands, not browser commands. When the user activates a link or button, the screen reader hands control back to the browser.

This is important to understand because it means screen reader users are often navigating a static representation of the page, not the live DOM. Dynamic content changes (like AJAX updates or modal dialogs) need to be explicitly announced to the user, or they will not know anything changed.

The Web Content Accessibility Guidelines (WCAG) include many success criteria that directly affect screen reader users. Here are the most important ones.

1.1.1: Non text Content (Level A)

Every image, icon, chart, and graphic that conveys information must have a text alternative that serves the same purpose. This is the alt attribute on <img> elements. For decorative images that carry no information, an empty alt attribute (alt="") tells the screen reader to skip the image entirely.

Without alt text, a screen reader may announce the file name (like “IMG_4827.jpg”) or simply say “image,” which tells the user nothing.

1.3.1: Info and Relationships (Level A)

Information, structure, and relationships conveyed through visual formatting must be programmatically available to assistive technologies. This means:

Headings must use actual <h1> through <h6> tags, not just bold or large text.
Lists must use <ul>, <ol>, and <li> tags, not just bullet characters.
Tables must use proper <table>, <th>, <tr>, and <td> markup with appropriate scope attributes.
Form fields must have associated <label> elements.

If you convey relationships visually (like grouping related fields in a box) but do not encode those relationships in HTML, a screen reader user will not perceive them.

1.3.2: Meaningful Sequence (Level A)

The order in which content is presented in the HTML must make sense when read sequentially. Screen readers follow the DOM order, not the visual order. If CSS repositions elements visually but the HTML order is illogical, screen reader users will encounter a confusing, out of order experience.

1.4.1: Use of Color (Level A)

Color must not be the only way to convey information. For example, if a form field is highlighted in red to indicate an error but there is no text label saying so, a screen reader user will not know there is an error. The screen reader cannot detect color. You need text or markup to communicate the same information.

2.4.2: Page Titled (Level A)

Every page must have a descriptive title in the <title> tag. Screen readers announce the page title when the page loads. Without a title, the user has no idea what page they are on, especially when switching between browser tabs.

2.4.4: Link Purpose (Level A)

The purpose of every link must be clear from the link text alone, or from its surrounding context. Screen reader users often navigate by pulling up a list of all links on a page. If every link says “click here” or “read more,” that list is useless. Each link should describe its destination.

2.4.6: Headings and Labels (Level AA)

Headings and labels must be descriptive. A heading that says “More Info” is not as helpful as one that says “Pricing Plans.” Screen reader users rely on headings to understand page structure and navigate quickly. Vague headings make this difficult.

3.3.2: Labels or Instructions (Level A)

Form fields must have labels and instructions when content requires user input. Every <input>, <select>, and <textarea> should have a properly associated <label>. Without labels, a screen reader user has no idea what to enter in each field.

4.1.2: Name, Role, Value (Level A)

For all user interface components, the name, role, and value must be programmatically available to assistive technologies. This means:

Custom widgets (like tabs, accordions, sliders) must expose their role (what they are) and state (expanded, collapsed, selected, etc.) to screen readers.
The component must have an accessible name (a text label).
Changes in value or state must be announced to the user.

This is where ARIA comes in. The role attribute, aria-label, aria-expanded, aria-checked, and similar attributes provide the information screen readers need to understand custom widgets. For more on this, see our guide on using ARIA for web accessibility.

4.1.3: Status Messages (Level AA)

Status messages (like “form submitted successfully” or “3 items in cart”) must be announced to screen reader users without stealing focus. This is done using ARIA live regions, which we will cover later in this guide.

For a broader understanding of how these criteria fit into the WCAG framework, see our guide on the levels of WCAG compliance.

Now let us look at the specific problems that make websites difficult or impossible for screen reader users.

1. Missing or Poor Alt Text

This is the most common screen reader accessibility issue. Images without alt text are announced as “image” or the file name. Images with generic alt text like “photo” or “graphic” are equally unhelpful. And images with keyword stuffed alt text designed for SEO rather than human understanding create a frustrating listening experience.

The fix: write concise, meaningful alt text for every image that conveys information. Describe what the image shows and why it matters in context. For decorative images, use alt="".

2. Improper Heading Structure

Screen reader users navigate by headings. If a page has no headings, the user must listen to the entire page linearly. If headings skip levels (jumping from h1 to h3 without an h2), the heading outline is confusing. If headings are used for visual styling rather than structure, the outline does not reflect the actual content.

The fix: use headings to create a logical outline of your content. Start with one h1 that describes the page, then use h2 for major sections, h3 for subsections, and so on. Never skip levels, and never use a heading tag just to make text look bigger.

3. Unlabeled Form Fields

A form field without a label is a mystery to a screen reader user. They hear “edit text” but have no idea what to type. Common causes include using placeholder text instead of a label, or using a <label> that is not properly associated with its field.

The fix: use a <label> element with a for attribute that matches the field’s id. Placeholders are not a substitute for labels because they disappear when the user starts typing, and screen readers may not announce them.

For a comprehensive guide, see our article on accessible forms.

4. Vague Link Text

Links that say “click here,” “read more,” “learn more,” or just “here” give screen reader users no context. When they pull up a list of all links on a page and see fifteen instances of “read more,” they cannot tell which one goes where.

The fix: write link text that describes the destination. “Read our WCAG compliance guide” is clear. “Read more” is not.

5. Missing HTML5 Landmarks

Without HTML5 landmark elements (<main>, <nav>, <header>, <footer>, <aside>), screen reader users have no way to jump to specific regions of the page. They must tab through everything sequentially.

The fix: wrap your page sections in the appropriate landmark elements. At minimum, every page should have a <main> element around its primary content.

6. Missing Page Titles

If every page on your site has the same <title> (or no title at all), screen reader users cannot distinguish between pages when they have multiple tabs open. The page title is the first thing announced when a page loads, and it appears in the browser tab list.

The fix: give every page a unique, descriptive title that includes the page name and the site name.

7. Dynamic Content Without Announcements

When content changes dynamically (a success message appears, a shopping cart updates, new search results load), screen reader users will not know about the change unless it is explicitly announced. This is one of the most common issues in modern, JavaScript heavy web applications.

The fix: use ARIA live regions to announce dynamic changes. We will cover how to do this in the next section.

8. Non Semantic Custom Widgets

When interactive elements are built with <div> and <span> instead of semantic HTML, screen readers do not know what they are. A “button” built as a <div onclick> is announced as plain text, not as a button. The user does not know it is interactive.

The fix: use native HTML elements (<button>, <a>, <input>, <select>) whenever possible. When you must build custom widgets, use ARIA roles and attributes to communicate their function and state.

9. Inaccessible Data Tables

Tables that lack proper header markup are nearly impossible for screen reader users to understand. A screen reader announces cells one at a time, so without knowing which column header or row header applies to each cell, the data is meaningless.

The fix: use <th> elements for headers, with scope="col" or scope="row" attributes to clarify their relationship to the data cells. For complex tables, use the headers attribute to explicitly associate cells with their headers.

10. Auto Playing Audio

If a page has audio that starts playing automatically, it interferes with the screen reader’s speech output. The user cannot hear the screen reader over the auto playing audio, making the page effectively unusable.

The fix: never auto play audio. Provide a visible, accessible play button and let the user choose to start the audio.

How to Make Your Site Accessible to Screen Readers

Now for the practical steps. Here is what you need to do to ensure screen reader users can fully use your website.

1. Use Semantic HTML Everywhere

This is the single most important principle. Semantic HTML is the foundation of screen reader accessibility. Native HTML elements communicate their meaning automatically:

<button> is announced as “button.”
<a href> is announced as “link.”
<input type="checkbox"> is announced as “checkbox.”
<nav> is announced as “navigation region.”
<main> is announced as “main region.”
<h1> through <h6> are announced as headings at their respective levels.
<ul> and <ol> are announced as lists with the number of items.

When you use these elements, screen readers understand your content without any extra work on your part. When you use <div> and <span> for everything, you force the screen reader to guess, and it usually guesses wrong.

2. Write Meaningful Alt Text

For every image that conveys information, write alt text that describes what the image shows and why it matters. Follow these guidelines:

Be concise. Aim for 125 characters or fewer.
Be descriptive, not technical. “A chart showing revenue growth from 2020 to 2025” is better than “bar chart, 800x600, blue bars.”
Do not start with “Image of” or “Picture of.” The screen reader already announces it as an image.
Consider the context. If the image is a link, the alt text should describe the destination, not the image.
For decorative images that add no information, use alt="" so the screen reader skips them.

3. Structure Headings Logically

Create a heading outline that mirrors the structure of your content:

One <h1> per page, describing the page topic.
<h2> for major sections.
<h3> for subsections within those sections.
Never skip heading levels.
Never use headings purely for visual styling. Use CSS for appearance, HTML for structure.

4. Label All Form Fields

Associate every form field with a <label> element:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

The for attribute on the label must match the id on the input. This allows the screen reader to announce the label when the field receives focus, and it also increases the click target for mouse users.

If you cannot use a visible label (for example, a search field with a magnifying glass icon button), use aria-label to provide an accessible name:

<input type="search" aria-label="Search the site" placeholder="Search...">

5. Use Descriptive Link Text

Every link should make sense on its own, without surrounding context. Instead of:

<a href="/pricing">Click here</a> to see our pricing.

Write:

See our <a href="/pricing">pricing plans</a>.

This ensures that when a screen reader user pulls up a list of links, each one clearly describes its destination.

6. Add HTML5 Landmarks

Wrap your page sections in landmark elements:

<header>
  <nav><!-- navigation menu --></nav>
</header>
<main>
  <article><!-- main content --></article>
  <aside><!-- sidebar --></aside>
</main>
<footer><!-- footer content --></footer>

Screen reader users can jump between these regions, making navigation much faster. If you cannot use the HTML5 elements for some reason, use ARIA roles (role="main", role="navigation", etc.) as a fallback.

7. Write Unique, Descriptive Page Titles

Each page should have a <title> that includes the page name and your site name:

<title>Screen Reader Accessibility | Accessible Metrics</title>

This helps screen reader users know where they are and distinguish between tabs.

8. Make Dynamic Content Accessible With ARIA Live Regions

When content updates dynamically, use ARIA live regions to announce the change:

<div aria-live="polite" id="status-message"></div>

When you update the content of this element via JavaScript, the screen reader will announce it without moving focus. Use aria-live="polite" for non urgent updates (the screen reader waits until it finishes speaking before announcing). Use aria-live="assertive" for urgent messages (the screen reader interrupts to announce immediately).

For form validation errors, use role="alert":

<div role="alert">Please enter a valid email address.</div>

This announces the message immediately when it appears.

9. Build Accessible Custom Widgets

When you need a custom widget that cannot be built with native HTML, use ARIA to make it work with screen readers. For example, a custom tab interface:

<div role="tablist">
  <button role="tab" id="tab1" aria-selected="true" aria-controls="panel1">Overview</button>
  <button role="tab" id="tab2" aria-selected="false" aria-controls="panel2">Details</button>
</div>
<div role="tabpanel" id="panel1" aria-labelledby="tab1">Overview content</div>
<div role="tabpanel" id="panel2" aria-labelledby="tab2" hidden>Details content</div>

Key points:

Use role to tell the screen reader what the element is (tab, tabpanel, tablist).
Use aria-selected to indicate which tab is active.
Use aria-controls to associate each tab with its panel.
Use aria-labelledby to give each panel an accessible name.
Use hidden to hide inactive panels from screen readers.

For more detailed guidance, see our guide on using ARIA for web accessibility.

10. Mark Up Data Tables Properly

For data tables, use proper header markup so screen reader users can understand the relationship between cells:

<table>
  <thead>
    <tr>
      <th scope="col">Product</th>
      <th scope="col">Price</th>
      <th scope="col">In Stock</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Widget A</th>
      <td>$9.99</td>
      <td>Yes</td>
    </tr>
    <tr>
      <th scope="row">Widget B</th>
      <td>$14.99</td>
      <td>No</td>
    </tr>
  </tbody>
</table>

The scope attribute tells the screen reader which cells are headers and whether they apply to a column or a row. This allows the screen reader to announce each data cell with its associated headers, making the table understandable.

Never use tables for layout. If you need to position content visually, use CSS grid or flexbox.

11. Manage Focus for Dynamic Content

When content changes dynamically (a modal opens, a new section appears, content loads via AJAX), you need to manage keyboard focus so screen reader users know the page changed:

When a modal opens, move focus to the modal or its first focusable element.
When the modal closes, return focus to the element that triggered it.
When new content loads, move focus to the new content so it is announced.
When content is removed, ensure focus does not land on a deleted element.

For more on keyboard focus and navigation, see our guide on keyboard accessibility.

Testing with a screen reader is the best way to find and fix screen reader accessibility issues. Here is how to do it.

The most reliable testing method is to use an actual screen reader. You do not need to be an expert. Here are some starting points:

NVDA (free, Windows): Download and install NVDA. Open your website in Firefox or Chrome. Use the arrow keys to navigate. Press the H key to jump between headings. Press the K key to jump between links. Press Insert+F7 to pull up a list of elements.
VoiceOver (free, macOS): Press Command+F5 to turn on VoiceOver. Use the arrow keys or the VoiceOver rotor (Control+Option+U) to navigate by headings, links, and landmarks.
TalkBack (free, Android): Turn on TalkBack in your Android accessibility settings. Swipe right to move through elements. Use the local context menu to navigate by element type.
VoiceOver (free, iOS): Turn on VoiceOver in your iOS accessibility settings. Swipe right to move through elements. Use the rotor to navigate by element type.

When testing, ask yourself:

Can you understand what the page is about from the title and headings alone?
Can you navigate to the section you need using heading or landmark navigation?
Does every interactive element announce what it is and what it does?
Can you fill out and submit forms?
Are dynamic changes announced?
Is the reading order logical?

2. Test With a Browser Accessibility Inspector

Modern browsers have built in accessibility inspectors that show you how a screen reader will interpret your page:

Chrome: Open Developer Tools, go to the Elements panel, and select the Accessibility tab. It shows the accessibility tree, computed name and role for each element, and ARIA attributes.
Firefox: Open Developer Tools, go to the Accessibility panel. It shows the accessibility tree and lets you check for common issues.
Safari: Open the Accessibility Inspector from the Develop menu.

These tools help you verify that elements have the correct roles, names, and states without needing to listen to the entire page.

3. Use Automated Testing Tools

Automated tools can catch many screen reader accessibility issues quickly:

axe DevTools (browser extension) scans your page for WCAG violations including missing alt text, improper headings, unlabeled form fields, and missing landmarks.
Lighthouse (built into Chrome DevTools) runs an accessibility audit that covers many screen reader related criteria.
WAVE (web accessibility evaluation tool) provides a visual report of accessibility issues on your page.

These tools catch roughly 30 to 40 percent of accessibility issues automatically. They are a great starting point but cannot replace manual screen reader testing. For more on testing tools, see our guide on accessibility testing tools.

4. Test With Real Users

If possible, involve screen reader users in your testing process. They will find issues that automated tools and sighted testers miss. Organizations like the National Federation of the Blind and user testing platforms can connect you with screen reader users for feedback.

For a broader testing approach, see our guide on how to test the accessibility of your website. You can also learn about the differences between automated and manual testing in our article on automated vs manual accessibility testing.

Screen reader accessibility is not just a best practice. It is a legal requirement. The Americans with Disabilities Act (ADA) requires that websites be accessible to people with disabilities, and screen reader compatibility is one of the most fundamental requirements. Title II of the ADA applies to state and local government websites, while Title III applies to businesses and organizations open to the public.

Section 508 of the Rehabilitation Act requires federal agencies and organizations receiving federal funding to make their electronic content accessible. This includes compatibility with screen readers.

Both legal frameworks point to WCAG as the standard for web accessibility. WCAG Level A and Level AA criteria include all the requirements we discussed above: alt text, semantic structure, labels, headings, landmarks, and ARIA for custom widgets.

For more on legal requirements, see our guides on ADA compliance and Section 508 compliance.

Quick Wins to Get Started

You do not need to rebuild your entire site to improve screen reader accessibility. Start with these high impact fixes:

Audit your alt text. Go through your most important pages and make sure every image has meaningful alt text or an empty alt attribute for decorative images.
Fix your heading structure. Make sure every page has one <h1>, headings are in order, and no levels are skipped.
Add labels to all form fields. Check that every input has a properly associated <label> or an aria-label.
Rewrite vague link text. Find every “click here” and “read more” and replace it with descriptive text.
Add HTML5 landmarks. Wrap your main content in <main>, your navigation in <nav>, and your footer in <footer>.
Check your page titles. Make sure every page has a unique, descriptive <title>.
Test with NVDA or VoiceOver. Spend thirty minutes navigating your site with a screen reader. You will immediately understand the user experience and find issues to fix.

Then run a full accessibility scan to catch the technical issues you may have missed. Accessible Metrics checks your site against WCAG 2.1 AA standards, including all the criteria that affect screen reader users.

The Bottom Line

Screen reader users are a significant and important audience. When your website works well with screen readers, you are serving people who depend on this technology to access the digital world. You are also improving your site’s structure and semantics in ways that benefit every user and every search engine.

Screen reader accessibility is not about adding complicated code or exotic features. It is about using semantic HTML, writing clear text alternatives, labeling your form fields, and structuring your content logically. The principles are simple, but the impact is enormous.

Ready to see how your site performs for screen reader users? Run a free accessibility scan with Accessible Metrics and get a detailed report against WCAG 2.1 AA standards, covering alt text, headings, labels, landmarks, ARIA, and dozens of other criteria that determine whether your site works for people who cannot see it.