Understanding Screen Readers
Screen readers are assistive technologies that present digital content through synthesized speech, braille displays, or a combination of both.
A screen reader does not simply read the visible page from top to bottom. It uses information provided by HTML and the browser to identify headings, links, landmarks, form controls, images, tables, and other content, allowing users to navigate and interact with a webpage in different ways.
How Screen Readers Work
Browsers interpret HTML and expose information about the webpage to assistive technologies. This information can include an element's role, accessible name, state, value, and relationship to other elements.
A screen reader uses this information to communicate both the content and its meaning. For example, it can identify text as a heading, announce that an element is a link or button, identify the label of a form field, and communicate whether a checkbox is checked.
This is one reason correct HTML matters. Two elements may look identical on the screen while providing very different information and behavior to assistive technology.
Semantic HTML
Semantic HTML communicates what content represents rather than only how it should look. Native HTML elements provide browsers with information that can then be exposed to screen readers.
For example, use a real button for an action:
<button type="button">Show Details</button>Rather than making a generic element look like a button:
<div class="button">Show Details</div>The native <button> already provides button semantics, focus behavior, and expected keyboard interaction. Similar benefits come from using appropriate headings, links, lists, tables, form controls, and structural elements.
Headings
Screen reader users can navigate between headings or obtain a list of headings to understand the organization of a page. A logical heading hierarchy therefore provides more than visual formatting; it creates a useful navigation structure.
<h1>Garden Center</h1>
<h2>Plants</h2>
<h3>Vegetable Plants</h3>
<h3>Flowering Plants</h3>
<h2>Garden Supplies</h2>Descriptive headings make this navigation more useful because the user can identify the purpose of each section without reading all of the content that comes before it.
Page Landmarks
Structural HTML elements can identify major regions of a webpage. Screen readers may allow users to navigate between these landmarks rather than moving through every element individually.
<header>
...
</header>
<nav aria-label="Main navigation">
...
</nav>
<main>
...
</main>
<aside>
...
</aside>
<footer>
...
</footer>Elements such as <nav>, <main>, and <aside> communicate the purpose of important page regions. When multiple landmarks of the same type appear on a page, accessible names can help distinguish them when appropriate.
Links
Screen reader users may navigate directly between links or review a list of links on a page. Descriptive link text is therefore particularly useful when the link is encountered separately from its surrounding paragraph.
A vague link provides little information:
<a href="/gardening-guide.html">Click here</a>A descriptive link communicates its purpose:
<a href="/gardening-guide.html">Read the Gardening Guide</a>Meaningful link text benefits screen reader users as well as anyone visually scanning a webpage for useful destinations.
Images
The alt attribute provides a text alternative that can communicate the information or purpose of an image to screen reader users.
<img src="/img/images/tomato-plant.jpg" alt="Tomato plant supported by a wire cage">Purely decorative images generally use an empty alternative so they do not add unnecessary information:
<img src="/img/images/decorative-leaves.png" alt="">Alternative text should be based on the image's purpose and context rather than mechanically describing every visible detail.
Forms and Controls
Form controls need accessible names so screen reader users can understand what information each field requires. A properly associated <label> provides that information for many common controls.
<label for="email">Email Address</label>
<input type="email" id="email" name="email">When the input receives focus, assistive technology can use the associated label to identify the field. Additional instructions and error messages should also be programmatically associated with controls when necessary.
Native controls should be preferred because their roles, states, and expected interaction are already understood by browsers and assistive technologies.
Data Tables
Accessible data tables use table markup to identify relationships between headers and data cells. Header cells should use <th> rather than relying only on bold text or visual styling.
<table>
<thead>
<tr>
<th scope="col">Plant</th>
<th scope="col">Sunlight</th>
</tr>
</thead>
<tbody>
<tr>
<td>Tomato</td>
<td>Full Sun</td>
</tr>
</tbody>
</table>Screen readers can use these relationships to provide context while users navigate through table cells. Tables should be used for tabular data rather than for controlling page layout.
Document Order
Screen readers generally encounter content according to its HTML document order. A logical source order is therefore important even when CSS changes the visual arrangement of content.
Content that appears first visually but occurs much later in the HTML can create a different experience for someone navigating with assistive technology or a keyboard.
Whenever practical, structure the HTML in the same meaningful order in which the content should be read and navigated.
Hidden Content
Content can be visually hidden for many reasons, but different hiding techniques can affect assistive technologies differently. Content removed with the HTML hidden attribute or CSS display: none; is generally removed from presentation to screen readers as well.
<p hidden>This content is currently unavailable.</p>Sometimes text needs to remain available to assistive technology while being visually hidden. This requires a visually hidden CSS technique designed to keep the content available to the accessibility system.
Do not hide visible information from screen readers or expose unnecessary hidden information without understanding how the chosen technique affects different users.
ARIA and Screen Readers
Accessible Rich Internet Applications, commonly called ARIA, provides attributes that can add accessibility information when native HTML alone cannot describe a custom interface adequately.
<nav aria-label="Product categories">
...
</nav>ARIA can provide names, roles, states, properties, and relationships that assistive technologies can use. It does not automatically add keyboard behavior or make an inaccessible custom control accessible.
Use native HTML whenever it already provides the required semantics and behavior. The ARIA Basics tutorial covers ARIA in greater detail.
Testing with Screen Readers
Testing with a screen reader can reveal accessibility problems that are difficult to discover by looking at the page alone. It can help identify unclear headings, poorly labeled controls, repetitive alternative text, confusing link names, incorrect reading order, and missing structural information.
Common screen readers include NVDA and JAWS on Windows, VoiceOver on Apple devices, and TalkBack on Android. Each has its own commands and behavior, so testing should be approached as learning how users navigate rather than simply listening to the entire page from beginning to end.
Useful tests include navigating by headings, landmarks, links, form controls, and tables. Also test interactive components with the keyboard and listen to how their names, roles, states, and instructions are announced.
Best Practices
- Use semantic HTML elements that accurately describe the purpose of the content.
- Create a logical heading hierarchy with descriptive heading text.
- Use HTML landmarks to identify important page regions.
- Write link text that communicates the purpose or destination of each link.
- Provide appropriate alternative text for informative and functional images.
- Associate form controls with clear labels and necessary instructions.
- Use proper header cells and relationships in data tables.
- Keep the HTML document order logical and meaningful.
- Understand whether visually hidden content remains available to assistive technology.
- Prefer native HTML over custom controls whenever possible.
- Use ARIA to supplement HTML when additional accessibility information is genuinely necessary.
- Include screen reader testing as part of accessibility testing rather than relying only on visual inspection.
Summary
Screen readers use information provided through HTML and the browser to communicate webpage content, structure, relationships, and interactive controls. Semantic elements give this information meaning that visual styling alone cannot provide.
Logical headings, landmarks, descriptive links, appropriate image alternatives, labeled forms, accessible tables, meaningful document order, and careful use of ARIA create a stronger experience for screen reader users and a more structured webpage for everyone.