Screen reader optimization is the practice of building websites so that assistive software like JAWS, NVDA, and VoiceOver can read, navigate, and interact with the page accurately. It depends on semantic HTML, proper ARIA roles, landmark regions, descriptive alt text, accessible names for interactive controls, and a logical document outline. Done well, it makes your site usable for blind and low-vision users without sacrificing visual design.
Around 285 million people worldwide have a visual impairment. Many use screen readers daily. If your site is not optimized for them, you are excluding a significant audience and exposing yourself to legal risk under the ADA, the European Accessibility Act, and similar regulations. This guide covers how screen readers work and the rules for building screen-reader-friendly sites.
How Screen Readers Work
A screen reader is software that translates the visual content of a screen into speech or braille output. The user navigates the page with keyboard shortcuts, hearing each element announced as they move focus. Popular screen readers include:
- JAWS — the dominant commercial screen reader on Windows
- NVDA — free and open source, also Windows
- VoiceOver — built into macOS and iOS
- TalkBack — Google’s screen reader for Android
- Narrator — built into Windows
Each reads HTML through what is called the accessibility tree, a parallel structure that browsers build from the DOM. Your job as a designer or developer is to make sure the accessibility tree reflects the meaning of the page, not just the visual layout.
Reading Order vs Visual Order
Screen readers follow the source order of HTML, not the visual order created by CSS. If you reorder columns with flexbox or grid, the screen reader still reads top-to-bottom in source order. Always design the HTML structure to match the intended reading order, then style it visually with CSS.
Semantic HTML Is the Foundation
Semantic HTML uses the right tag for the right job. A button should be a <button>, not a <div> with a click handler. A navigation menu should be a <nav>. A main content area should be a <main>. These tags give screen readers the information they need to announce what each element is and how to interact with it.
The Essential Semantic Tags
<header>— site or section header<nav>— primary navigation<main>— primary page content (only one per page)<article>— self-contained content like a blog post<section>— thematic grouping of content<aside>— sidebar or supplementary content<footer>— page or section footer<button>— interactive button<a>— link to another page<h1>through<h6>— heading hierarchy
If you build your site with these tags from the start, you get most of screen reader optimization for free. Add ARIA only when semantic HTML cannot express the relationship.
Landmarks and Document Structure
Screen reader users navigate by landmarks, headings, and links. They jump from one <nav> to the next, or skim all the <h2> headings on a page to find the section they want. A well-structured page is fast to navigate; a poorly structured page is a maze.
The Heading Hierarchy
Every page should have exactly one <h1>. Subsections use <h2>. Sub-subsections use <h3>, and so on. Never skip a level. Never use a heading purely for visual styling — if you want bigger text, use CSS.
This matters for visual hierarchy too, but for screen readers it is structural. Skipping from <h2> to <h4> makes the page outline confusing.
Skip Links
A skip link at the top of every page lets keyboard and screen reader users jump straight to the main content, bypassing the navigation. It should be the first focusable element on the page. Hide it visually with CSS, but reveal it on focus so sighted keyboard users can see it too.
Accessible Names for Interactive Elements
Every button, link, and form control needs an accessible name — the text the screen reader announces when the user focuses it. An icon-only button with no text is silent. A form input with no label is announced as just “edit field.” These are accessibility failures.
How to Give Elements Accessible Names
- Visible label text — best option for most cases
- aria-label — for icon-only buttons, like a close X or a search magnifier
- aria-labelledby — references another element on the page
- alt attribute on images — when an image is the only content of a link
- Associated label for form fields — use
<label for="id">
For form fields specifically, see our form design guide. Visible labels are always preferable to placeholder-only patterns.
Alt Text for Images
Every meaningful image needs alt text. Decorative images should have an empty alt (alt="") so screen readers skip them. The rules:
- Describe the content and function of the image, not the image itself
- Keep it concise — under 125 characters when possible
- Skip phrases like “image of” or “picture of” — the screen reader already announces it as an image
- For complex images like charts, use a longer description in the surrounding text or via
aria-describedby - For logos that are also links, the alt text should describe where the link goes, not the visual design
Testing With Screen Readers
Automated accessibility tools catch maybe 30 to 40 percent of issues. The rest require manual testing with an actual screen reader.
How to Test on a Mac
- Turn on VoiceOver: Command + F5
- Navigate with Control + Option + Right Arrow
- Read all: Control + Option + A
- Open the rotor for landmarks and headings: Control + Option + U
How to Test on Windows
- Install NVDA (free) or use built-in Narrator
- Navigate with arrow keys, Tab, and H to jump between headings
- Press D to jump between landmarks
- Press F to jump between form fields
Browser Tools That Help
- Chrome DevTools accessibility tree inspector
- Lighthouse accessibility audit
- axe DevTools by Deque
- WAVE by WebAIM
Run automated tools first to catch the obvious issues, then test manually with at least one screen reader on a real page.
ARIA: When to Use It and When Not To
The first rule of ARIA is: do not use ARIA. Use semantic HTML first. ARIA exists for cases where HTML cannot express what you need — custom widgets, dynamic content, complex grids.
Useful ARIA Patterns
aria-expanded— for collapsible sections and dropdownsaria-current— for the current page in a navigation menuaria-live— for content that updates dynamically without a page reloadrole="dialog"witharia-modal="true"— for modal overlaysaria-describedby— to associate error messages with form fields
Bad ARIA is worse than no ARIA. A <div role="button"> without keyboard support and accessible name is broken in a way that semantic HTML would never be.
Dynamic Content and Live Regions
Modern websites built with React, Vue, or Next.js update content without a page reload. Screen readers do not automatically know about these changes. Use aria-live="polite" for notifications and aria-live="assertive" for urgent alerts.
A toast notification confirming a form submission should be in a polite live region. An error that blocks the user from continuing should be in an assertive region. Use sparingly — over-announcing creates noise.
Common Screen Reader Failures
- Clickable
<div>elements with no keyboard support and no role - Icon-only buttons with no
aria-label - Form fields with placeholder text but no visible label
- Images of text with no alt content describing the text
- Modal overlays that do not trap focus
- Carousels that do not pause on focus
- Custom dropdowns built on
<div>without keyboard arrow-key support - Skip links that are missing or broken
- Page titles that do not change on route change in single-page applications
Most of these come from rebuilding native browser controls. Use the native control when you can.
Frequently Asked Questions
What is the most common screen reader?
JAWS dominates commercial use on Windows, followed closely by NVDA, which is free and open source. On Apple devices, VoiceOver is built in and used by virtually all Mac, iPhone, and iPad screen reader users. Test against at least JAWS or NVDA plus VoiceOver to cover most users.
Do I need ARIA to make my site accessible?
No. Semantic HTML covers most accessibility needs. ARIA is for cases where HTML cannot express a relationship, like custom widgets or dynamic state. Use ARIA sparingly — incorrect ARIA is worse than no ARIA at all.
How do screen readers handle JavaScript-heavy sites?
Modern screen readers fully support JavaScript and the accessibility tree updates as the DOM changes. But you must announce dynamic updates with aria-live, manage focus on route changes, and update the document title for each view. Sites built with React or Next.js need explicit accessibility work at the framework level.
Build It Right From the Start
Screen reader optimization is not a checklist you tack on at the end. It is a way of structuring HTML and managing state. Sites that nail it from day one are easier to build, easier to maintain, and reach more users.
Want a site built accessible by default? Talk to our team or see our pricing.