How to design for screen readers
Designing for screen readers isn't about checking boxes on some compliance list. It's actually about building web experiences that don't suck for anyone. Screen readers take digital text and turn it into speech or braille, so folks who are blind or have low vision can actually use the web. Good design here means semantic HTML, solid structure, and navigation that actually makes sense.
What is the most important rule when designing for screen readers?
Hands down, it's using semantic HTML. Screen readers depend on the code structure to figure out what's what. When you use proper heading tags (h1 through h6), lists (ul, ol), and landmarks (nav, main, aside), you're giving them a clear roadmap. This lets users skip around sections, jump straight to content, and grasp the whole hierarchy without needing to see anything.
How do you make images accessible for screen readers?
Every meaningful image needs alt text in the alt attribute. The description should be concise and context-aware—what's the image doing here? For decorative images, just use alt="" so screen readers completely skip them. And please, don't start with "image of" or "picture of." The screen reader already announces it as an image, so that's just noise.
Alt Text Decision Table
| Image Type | Example | Recommended Alt Text |
|---|---|---|
| Informative | Chart showing sales growth | "Bar chart: sales increased 20% in Q3" |
| Functional | Search icon | "Search" |
| Decorative | Background pattern | alt="" |
| Complex graphic | Detailed infographic | Provide long description via aria-describedby or link to text version |
How do you handle forms for screen reader users?
Every single form input needs a label connected to it using the <label> element with a for attribute that matches the input's id. Group related fields with <fieldset> and throw in a <legend>. Error messages should be linked to the input using aria-describedby. And for the love of everything, don't use placeholders as labels—they disappear and mess people up.
What is the role of ARIA in screen reader design?
ARIA (Accessible Rich Internet Applications) is for when native HTML just doesn't cut it. Use role for custom widgets like role="tab", aria-label for elements without visible text, and aria-live for dynamic content that changes. But here's the thing—the first rule of ARIA? Don't use it if a native HTML element already does the job. Too much ARIA and you'll just confuse everyone.
Screen Reader Design Checklist
- Use proper heading hierarchy (h1 to h6) in sequential order.
- Provide descriptive link text; never use "click here" or "read more."
- Ensure all functionality is keyboard accessible (Tab, Enter, Arrow keys).
- Test with a real screen reader (NVDA, JAWS, VoiceOver).
- Maintain a logical tab order that matches the visual layout.
- Use
aria-hidden="true"to hide off-screen or decorative elements. - Provide skip navigation links at the of the page.
- Ensure color is not the only means of conveying information.
How do you test if a design works with screen readers?
Automated tools like axe or WAVE can catch obvious problems, but they don't tell you what it's actually like to use the thing. Manual testing is where it's at. Turn off your monitor, use only the keyboard and a screen reader. Listen for a logical reading order, clear announcements, and whether you can actually reach every interactive element. And test with different screen readers and browsers—they behave totally differently.
"Designing for screen readers is not a technical afterthought; it is a fundamental design principle that benefits all users by enforcing clarity, structure, and predictability."
Frequently Asked Questions
Do screen readers read CSS content?
Generally, no. Screen readers ignore CSS-generated content (like ::before and ::after pseudo-elements) because they are not part of the DOM. If you need to include text that must be read, put it in the HTML directly.
Should I hide text visually but keep it for screen readers?
Yes, but only for helpful content like skip links or instructions. Use a utility class that clips the text visually but keeps it in the DOM (e.g., position: absolute; left: -9999px;). Do not use display: none or visibility: hidden, as they hide content from screen readers too.
How do screen readers handle tables?
Screen readers navigate tables using table-specific keys. Use <th> with scope attributes for headers, and avoid using tables for layout. Complex data tables may need aria-describedby for a summary or use <caption> to describe the table's purpose.
What is the difference between aria-label and aria-labelledby?
aria-label directly provides a string label for an element. aria-labelledby references the ID of another element on the page to use as the label. Use aria-labelledby when the label already exists as visible text to avoid duplication.
Short Summary
- Semantic HTML is the foundation: Use proper headings, lists, and landmarks to create a logical structure that screen readers can interpret.
- Every image needs a purpose: Provide descriptive alt text for informative images and empty alt text for decorative ones.
- Forms must be labeled correctly: Always pair inputs with explicit
<label>elements and use<fieldset>for grouping. - Test with real users and tools: Automated checks catch errors, but manual testing with a screen reader reveals the true user experience.