Screen reader compatibility testing: ensuring your code announces correctly

How Screen Readers Work#

Screen readers convert on-screen text into synthesized speech or Braille. They rely on semantic HTML, ARIA attributes, and well-structured content to provide users accurate information about your website. For screen readers to function effectively, developers must use semantic elements, provide descriptive alternative text, and correctly label interactive components.

Ensuring screen reader compatibility is one part of a larger accessibility strategy. Without understanding the fundamental principles of web accessibility, you risk alienating users, facing compliance issues, or damaging your organization's reputation. Screen reader compatibility sets the foundation for the entire accessible experience.

For an introduction to broader web accessibility principles, read accessible website examples you can verify in a minute. For specific guidance on ARIA, see the ARIA roles for developers guide.

Developing for Screen Reader Compatibility#

Building screen reader compatible content requires disciplined markup choices. The following practices form the foundation of accessible development.

Use Semantic HTML#

Semantic elements like <header>, <nav>, <main>, and <footer> help screen readers understand page structure. Using <button> for interactive elements is preferable to <div> with JavaScript listeners. Semantic elements carry implicit roles and properties that screen readers already understand without additional ARIA markup.

<button onclick="submitForm()">Submit</button>

This code tells the screen reader that the element is clickable and announces it as a button. A div would require additional ARIA attributes to convey the same meaning.

Provide Accessible Labels#

Use <label> elements and ARIA attributes like aria-label and aria-labelledby to add context to form elements and interactive controls. Labels connect a text description to an input so screen readers can announce what the field is for.

<input type="text" id="username" aria-labelledby="usernameLabel">
<label id="usernameLabel">Username</label>

The aria-labelledby attribute associates the input with the label element's id. Screen readers announce "Username" when the user focuses the input field. Plain prose labels improve the experience for all users, not just those using screen readers.

Ensure Proper Focus Management#

Focus management is critical for dynamic content like modals or forms. When a dialog opens, move focus to the first focusable element within it. This ensures smooth navigation for screen reader users and keyboard users alike. Without proper focus movement, users navigating by keyboard may not know a modal has appeared.

document.querySelector('#modal').focus();

Set focus programmatically so that the screen reader announces the modal and the user's next keypress lands inside it. For more on this technique, see the guide to keyboard navigation and focus management.

Alternative Text for Images#

Ensure all images have alt text that describes the content or purpose concisely. Decorative images should have empty alt attributes (alt="") to prevent screen readers from reading them unnecessarily. Decorative images create noise and interrupt the flow of content.

<img src="team.jpg" alt="Our team standing together during a company event">

The alt text should describe what the image shows from the user's perspective, not state that it is an image. Write "Our team standing together" not "a photo of our team".

Testing Screen Reader Compatibility#

Testing your website with actual screen readers is the only way to identify what users will actually hear. Automated checks can verify that semantic elements and ARIA attributes are present, but they cannot tell you what gets announced.

Popular Screen Readers to Test With#

Three screen readers cover most use cases#

• JAWS (Job Access With Speech)
• NVDA (NonVisual Desktop Access)
• VoiceOver (macOS and iOS built-in)

JAWS is the most widely used screen reader on Windows but requires a paid license. NVDA is free and popular with developers for accessibility testing. VoiceOver comes built into Apple devices. Testing with all three reveals how differently each interprets ARIA roles and attributes.

Testing Tools and Techniques#

NVDA (Windows): Download NVDA and use it to navigate your website. Pay attention to how each element is read aloud. Verify that form labels, button purposes, and interactive controls are clearly announced.

VoiceOver (macOS): Activate VoiceOver with Cmd+F5. Navigate through your site and note how elements are announced. Pay attention to whether headings are read as headings and whether list structure is preserved. Listen for consistency across your pages.

JAWS (Windows): Use JAWS to evaluate the experience for users relying on advanced screen reader features. Compare how JAWS announces dynamic content compared to NVDA. Differences matter because users depend on these tools differently.

Establish a Listening Loop#

The only reliable way to verify a screen reader works is to listen to it. Record what you hear for each element, including pauses, prefixes (like "Alert" or "heading"), and the exact wording. Record the screen reader version, browser, and operating system because behavior differs across combinations.

Steps to verify an aria-live region#

• Load the page with screen reader running
• Place focus outside the region
• Trigger the change as a user would
• Write exactly what you heard
• Repeat with focus inside the region
• Record version, browser, OS, and date

That last step is critical. A result with no version and date comparison means nothing six months later when the browser updates.

Common Challenges When Testing with Screen Readers#

Screen reader behavior is not deterministic, and differences between readers reveal unexpected gaps in your implementation.

Dynamic Content Updates#

Use ARIA live regions with role="alert" or aria-live="polite" to announce dynamic updates such as form validation messages. This ensures announcements reach users without requiring focus to move to the region.

<div role="alert">Your changes have been saved successfully.</div>

The role="alert" implicitly sets aria-live="assertive", which prioritizes the announcement. Use it for urgent messages. For non-urgent updates, use aria-live="polite" so the screen reader announces the change at a natural pause in speaking.

Keyboard Navigation#

Ensure all elements are keyboard accessible. Users who rely on screen readers often navigate by keyboard. Custom components must support Tab, Enter, Escape, and arrow keys as appropriate. A component that works with a mouse but not a keyboard is inaccessible to keyboard and screen reader users.

Inconsistent Behavior Across Screen Readers#

Screen readers may interpret certain ARIA roles or attributes differently. Test across multiple readers to ensure a consistent experience. An element announced clearly in NVDA might be skipped entirely in JAWS. Differences exist, and your testing must account for them.

Best Practices for Screen Reader Compatibility#

Keep It Simple#

Avoid overly complex interactions and unnecessary ARIA roles. Stick to native HTML elements wherever possible. A semantic <button> is better than a <div> with ARIA. ARIA exists to fill gaps that HTML cannot, not to replace semantic elements.

Ensure Descriptive Link and Button Text#

Use clear, actionable labels. Instead of "Click here" or "Learn more", use "Read our accessibility testing guide" or "Download the WCAG checklist". Descriptive text tells users what the link does before they activate it.

Use ARIA Only When Necessary#

ARIA is powerful but can confuse users when overused. Native HTML elements carry implicit roles and properties. Use ARIA only when HTML cannot express the meaning your interface requires. Overuse of ARIA can make content less accessible, not more.

For detailed guidance on ARIA implementation, read the ARIA roles for developers guide. Understand what each role requires before applying it.

Meeting WCAG 2.2 standards ensures your website is accessible and legally compliant. If you need a comprehensive review of your site's accessibility posture, a WCAG and ADA compliance audit identifies gaps and provides a clear remediation path.

Conclusion#

Building screen reader compatible websites creates a more inclusive experience for all users. Focus on semantic HTML, provide accessible labels, manage focus appropriately, ensure image alt text is accurate, and test with actual screen readers. Testing with multiple readers across different platforms reveals real gaps that automated checks cannot catch.

If you want to ensure your website works with screen readers, or if you need to audit an existing site for compatibility, accessibility testing services can help. We test with the tools your users actually rely on and deliver a clear path to fix what we find.