Screen Readers and Your Website

What Is a Screen Reader?

A screen reader is software that converts on-screen content into speech or braille output. It reads aloud the text, describes images, announces links and buttons, and provides information about the structure of a page. People who are blind, have low vision, or have certain cognitive disabilities rely on screen readers as their primary way of using computers and mobile devices.

The most widely used screen readers include:

• JAWS (Job Access With Speech): The most popular screen reader on Windows, widely used in professional and educational settings. It is commercial software with an annual license.
• NVDA (NonVisual Desktop Access): A free, open-source screen reader for Windows. It has grown significantly in usage and is excellent for testing.
• VoiceOver: Built into every Apple device -- macOS, iOS, iPadOS. No separate installation needed. This is the most used screen reader on mobile.
• TalkBack: The built-in screen reader on Android devices.
• Narrator: Included with Windows. Less commonly used than JAWS or NVDA but improving with each Windows update.

According to the WebAIM Screen Reader User Survey, JAWS and NVDA account for the majority of desktop screen reader usage, while VoiceOver dominates on mobile. When testing your site, covering NVDA on Windows and VoiceOver on macOS or iOS gives you good coverage of how most screen reader users will experience your content.

How Screen Readers Navigate a Page

Screen reader users do not experience a page the way sighted users do. They cannot scan a layout visually. Instead, they navigate in a linear sequence or jump between structural elements. Understanding these navigation patterns is key to building accessible sites.

Headings as Navigation

One of the most common ways screen reader users navigate is by jumping between headings. They press a key (H in NVDA and JAWS) to move to the next heading, or they open a headings list to see the page structure at a glance. This is why a logical heading hierarchy -- H1, then H2, then H3 -- is so important. Skipping heading levels (going from H1 to H4, for example) creates a confusing experience, like a table of contents with missing chapters.

Landmarks and Regions

HTML5 landmark elements like <nav>, <main>, <header>, <footer>, and <aside> allow screen reader users to jump directly to major sections of the page. A user can skip past the navigation and go straight to the main content, or jump to the footer to find contact information. Without these landmarks, they would have to arrow through every single element on the page.

Links and Buttons

Screen reader users can pull up a list of all links on a page. This means link text like "click here" or "read more" is useless out of context -- the user sees a list of ten items all saying "read more" with no idea where each one goes. Descriptive link text like "view our pricing plans" or "read the full case study" makes all the difference.

Forms

Screen readers enter a special forms mode when interacting with inputs. They rely on programmatic label associations (using the <label> element with a matching for attribute) to announce what each field is for. Without proper labels, a user hears "edit text" with no indication of what information to type.

Why Semantic HTML Matters

The single most impactful thing you can do for screen reader accessibility is use semantic HTML. Semantic HTML means using the correct HTML elements for their intended purpose -- a button for actions, a link for navigation, a heading for section titles, a list for groups of related items.

When a developer uses a <div> styled to look like a button instead of an actual <button> element, sighted users may not notice the difference. But a screen reader has no way to know that particular div is supposed to be interactive. It will not announce it as a button, it will not be focusable with the keyboard by default, and it will not respond to the Enter or Space keys without extra JavaScript.

Proper semantic HTML gives screen readers the information they need for free. No ARIA attributes, no JavaScript workarounds -- just the right element for the job. ARIA (Accessible Rich Internet Applications) attributes exist for complex custom widgets, but the first rule of ARIA is: do not use ARIA if a native HTML element will do the job.

Common Screen Reader Issues on Business Websites

These are the problems screen reader users encounter most frequently on small business websites:

• Missing or meaningless alt text: Images without alt attributes are announced by their filename, which often sounds like "DSC underscore 0472 dot jpg." Decorative images should use empty alt (alt="") to be skipped entirely.
• No skip navigation link: Without a "skip to main content" link, screen reader users must listen through the entire navigation menu on every page load.
• Inaccessible menus: Dropdown menus that only appear on mouse hover are invisible to screen reader users if they lack proper ARIA markup and keyboard support.
• Auto-playing media: Audio or video that plays automatically can talk over the screen reader, making the page unusable until the user finds and stops it.
• Modal dialogs without focus management: When a modal opens but focus remains behind it, the screen reader user has no way to interact with the dialog or know it appeared.
• Dynamic content with no announcements: Content that updates without a page reload (like a success message after submitting a form) will go unnoticed unless an ARIA live region is used to announce the change.

How to Test With a Screen Reader

You do not need to be an expert to do basic screen reader testing. Here is a practical approach to get started:

Practical Checklist for Screen Reader Accessibility

Use this checklist to evaluate how well your site works with screen readers:

• -- Every page has exactly one H1 that describes the page topic
• -- Heading levels do not skip (H2 follows H1, H3 follows H2)
• -- All informative images have descriptive alt text
• -- Decorative images use empty alt attributes
• -- All form inputs have associated labels
• -- Link text is descriptive out of context
• -- The page uses landmark regions (nav, main, header, footer)
• -- The page language is declared in the HTML element
• -- Dynamic content changes are announced via ARIA live regions
• -- No content relies solely on visual presentation to convey meaning