Screen readers transform visual interfaces into audio streams. Every button, every image, every heading becomes spoken words.
For users who can’t see the screen, the screen reader is the entire experience. If your site doesn’t work with screen readers, it doesn’t work for them at all.
Designing for screen reader compatibility isn’t a separate track. It’s embedded in every design decision. The choices that make visual hierarchy clear often make screen reader navigation clear too, when implemented correctly.
Semantic HTML Does Most of the Work
Screen readers understand HTML semantics. They know what a button is. They know what a heading is. They know what a navigation region is.
When you use correct HTML elements, screen readers communicate structure automatically. A heading becomes “heading level 2.” A link becomes “link.” A button becomes “button.”
When you fake structure with styled divs, screen readers can’t tell the difference between content and chrome. That styled span that looks like a heading is just text to a screen reader. The div that functions as a button is just a container.
Semantic HTML costs nothing extra. Using button instead of div with click handler takes the same effort. Using h2 instead of styled p takes the same effort. The semantic version works better for everyone.
Heading Hierarchy Creates Navigation
Screen reader users navigate by headings. They jump from heading to heading to understand page structure and find content.
A logical heading hierarchy matters. H1 for the page title. H2 for major sections. H3 for subsections within those. The hierarchy should make sense when stripped of visual styling.
Skipped levels confuse navigation. H1 followed directly by H4 suggests missing content. Users wonder what they’re skipping.
Heading density affects usability. Too few headings and users can’t navigate efficiently. Too many headings and the outline becomes noisy. Find balance based on content structure.
Landmarks Define Regions
ARIA landmarks and HTML5 sectioning elements divide pages into navigable regions.
Main content lives in main. Navigation lives in nav. Supplementary content lives in aside. Page header lives in header. Page footer lives in footer.
Screen reader users can jump directly to landmarks. “Go to main content” skips navigation. “Go to navigation” finds the menu. These shortcuts depend on proper landmark use.
Multiple instances of the same landmark need labels. Two nav elements should be distinguishable: “main navigation” and “footer navigation.”
Alternative Text Describes Images
Images without alt text are invisible or confusing to screen readers.
Informative images need meaningful descriptions. Not “image” or “photo.” A description of what the image conveys: “Chart showing sales growth from January to December” or “Team members gathered at the annual retreat.”
Decorative images need empty alt attributes. A purely visual flourish that conveys no information should have alt=”” so screen readers skip it entirely. No alt attribute means the screen reader announces the filename, which is worse than nothing.
Complex images may need longer descriptions. A detailed infographic can’t be captured in brief alt text. Extended descriptions through aria-describedby or linked content provide full access.
The designer should know image purpose. Which images are informative? Which are decorative? This guidance helps writers create appropriate alt text.
Form Labels Connect
Every form input needs an associated label that screen readers can announce.
Explicit association uses the for attribute: label for=”email” with input id=”email”. The connection is unambiguous.
Placeholder text is not a label. When users type, the placeholder vanishes. Screen readers may not announce placeholders consistently. Labels persist and remain accessible.
Error messages need connection to fields. aria-describedby links an error message to its input. Without this connection, users hear errors without knowing which field is wrong.
Required field indication must be accessible. A red asterisk that only sighted users see doesn’t help. aria-required or visible text indicating requirement serves everyone.
Focus Management for Interactions
Keyboard users navigate by moving focus. Screen reader users hear what has focus.
Focus order should match visual order. Left-to-right, top-to-bottom in Western layouts. When focus jumps unexpectedly, users get disoriented.
Focus trapping in modals is appropriate. When a modal opens, focus should move inside and stay there until the modal closes. Tabbing should cycle within the modal, not escape to hidden page content.
Focus should move to relevant content after state changes. Delete an item and focus should move somewhere sensible, not get lost. Open an accordion and focus should move to the newly visible content.
Skip links let users bypass repetitive content. A “Skip to main content” link at the top of the page lets screen reader users jump past navigation they’ve heard on every page.
Live Regions Announce Dynamic Content
Content that updates without page reload needs special handling.
ARIA live regions tell screen readers to announce changes. A form submission success message, a notification count update, a chat message arriving.
Politeness levels control interruption. aria-live=”polite” waits for a pause before announcing. aria-live=”assertive” interrupts immediately. Match urgency to actual importance.
Status messages have their own role. role=”status” with aria-live=”polite” is appropriate for non-urgent updates.
Overuse of live regions creates noise. If everything announces itself, users drown in audio. Reserve live regions for genuinely important updates.
Testing Requires Actual Screen Readers
Automated tools catch some problems. Missing alt text, missing form labels, improper heading nesting.
But automated tools can’t tell if alt text is appropriate. They can’t tell if reading order makes sense. They can’t judge whether live regions are helpful or annoying.
Manual testing with screen readers reveals actual experience. NVDA on Windows, VoiceOver on Mac, TalkBack on Android. Experience your site as screen reader users do.
Testing with actual screen reader users provides deeper insight. People who use screen readers daily navigate differently than sighted testers with screen readers. Their expertise catches problems that novice testing misses.
FAQ
Our team has never tested with screen readers. Where do we start?
Start with one screen reader. VoiceOver is built into Mac, NVDA is free for Windows. Learn basic navigation: move by headings, move by landmarks, move through forms. Then try to complete a core task on your site. Note where you get stuck, confused, or annoyed.
We have a lot of images. Do we really need alt text for all of them?
No. Decorative images that don’t convey information should have empty alt (alt=””). Informative images need descriptions. The question for each image: does this communicate something a user needs to know? If yes, describe it. If no, mark it decorative.
Complex widgets like carousels and accordions. Accessibility approaches like carousels or accordions?
Follow WAI-ARIA Authoring Practices for established patterns. These patterns specify required roles, states, and keyboard behaviors. Carousels need proper controls and region identification. Accordions need proper button and expanded/collapsed states. The patterns exist so you don’t have to invent solutions.
Our site uses lots of icons without text. Is that a problem?
Icons alone are inaccessible unless they have text alternatives. Either visible text labels alongside icons, or aria-label on the icon’s interactive element. Icon fonts particularly need alternatives since the font character has no inherent meaning.
Sources
WebAIM. Screen Reader Testing. webaim.org/articles/screenreader_testing
W3C. WAI-ARIA Authoring Practices. w3.org/WAI/ARIA/apg
Deque. Screen Reader User Survey. deque.com
MDN Web Docs. ARIA. developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA
A11Y Project. Accessibility Checklist. a11yproject.com/checklist