Answer 39 of 50
Designing for Screen Reader Compatibility: What to Consider and Test
Screen reader compatibility rests on a handful of decisions: native HTML elements, a logical heading outline, labeled landmarks, alt text that matches each image’s purpose, labeled form fields with connected errors, predictable focus, and announcements for content that changes. Then it has to be tested with the screen readers your users run. In WebAIM’s July to August 2026 survey of 1,780 screen reader users, JAWS was the primary desktop screen reader for 55.0% of respondents, and 72.2% used VoiceOver on mobile.
Semantic HTML does most of the work
Screen readers announce what an element is: “heading level 2,” “link,” “button.” Use a real button and it is announced, focusable, and operable from the keyboard; style a div to look like a button and it is none of those things until you rebuild them by hand. ARIA can describe an element to assistive technology, but MDN’s reference on aria-required states the limit plainly: “ARIA does not change anything about an element’s function or behavior.” Native elements cost no more effort than styled ones and bring the behavior with them.
Headings are the main way people move through a page
In WebAIM’s Screen Reader User Survey #11, 67.8% of respondents said that when looking for information on a lengthy page, they first navigate through the headings, and 88.3% found heading levels very or somewhat useful. Give each page one H1, H2s for major sections, and H3s within them, so the outline makes sense with all styling removed. The A11Y Project’s accessibility checklist adds a simple rule: “Don’t skip heading levels”; if a level is skipped only for its look, use a CSS class instead.
Landmarks define regions
Landmarks let users jump to the main content, the navigation, or the footer. Use main, nav, aside, header, and footer for those regions, and label repeated landmarks so two navigation regions can be told apart, for example “Main” and “Footer.” One detail catches teams out: the W3C ARIA Authoring Practices guide on landmark regions says “The HTML header element defines a banner landmark when its context is the body element”, and the same applies to footer and the contentinfo landmark. A header nested inside an article or section is not the page banner.
In the 2026 survey, 28.3% of respondents navigated by landmarks whenever available or often, fewer than navigate by headings, so landmarks support headings rather than replace them.
Alt text matches the image’s purpose
- Informative images need a description of what the image conveys, such as “Chart showing sales rising each month from January to December,” not “image” or “photo.”
- Decorative images need an empty
alt=""so screen readers skip them. - Every image needs an alt attribute. WebAIM’s guide to alternative text warns that when an image is the only content of a link or button and the alt is empty or missing, “screen readers might read the image filename or the URL of the linked page”.
- Complex images such as detailed charts need a longer description elsewhere on the page or linked from it.
Designers should mark which images are informative and which are decorative, so whoever writes the alt text knows the purpose.
Forms: labels, errors, and required fields
Every input needs a label tied to it, for example label for="email" matched with input id="email". Placeholder text is not a label; it disappears when people type. Connect each error message to its field with aria-describedby, so a screen reader announces which field is wrong. For required fields, use the native required attribute on input, select, and textarea together with visible text such as “(required)”; MDN reserves aria-required for custom controls that are not native form elements. Field design is covered in designing user-friendly and error-free form fields, and error wording and announcement in designing helpful error messages.
Focus: predictable, and returned where it came from
Focus order should follow the visual order. For widgets such as dialogs and accordions, the ARIA Authoring Practices patterns define the behavior:
| Widget | What should happen | Source |
|---|---|---|
| Modal dialog | Focus moves inside when it opens, Tab cycles within it, Escape closes it, and focus returns to the control that opened it | APG dialog pattern |
| Accordion | Enter or Space expands the panel while focus stays on the header button; Tab moves on to the next focusable element | APG accordion pattern |
| Deleted list item | Focus moves to a sensible nearby element, not to the top of the page | Practice, not a formal pattern |
| Repeated navigation | A "Skip to main content" link lets keyboard and screen reader users bypass it | Practice, not a formal pattern |
The dialog pattern states: “When a dialog opens, focus moves to an element inside the dialog.” It also lists “Escape: Closes the dialog.” The accordion pattern says Enter or Space on a collapsed header “expands the associated panel”, and Tab “Moves focus to the next focusable element”. Moving focus into an accordion panel on open is not part of the pattern; users would lose the header button and its expanded state.
Announce content that changes
Content that updates without a page reload, such as a success message or a new notification, needs a live region to be announced. aria-live="polite" waits for a pause; aria-live="assertive" interrupts. MDN’s reference for the status role notes that “Elements with the role status have an implicit aria-live value of polite,” so role="status" alone is enough for non-urgent updates. Use live regions sparingly: if everything announces itself, nothing stands out.
What to test, and with what
Automated checkers find missing alt attributes, missing labels, and broken heading order. They cannot judge whether alt text fits the image, whether the reading order makes sense, or whether announcements help or annoy. That takes manual testing with real screen readers.
The 2026 WebAIM survey shows which combinations to prioritize:
| Combination | Share of respondents |
|---|---|
| JAWS with Chrome | 31.2% |
| NVDA with Chrome | 17.3% |
| JAWS with Edge | 17.0% |
| NVDA with Firefox | 9.1% |
| VoiceOver with Safari (desktop) | 4.3% |
On mobile, 72.2% of respondents used VoiceOver and 29.5% TalkBack. A practical minimum is JAWS or NVDA with Chrome on Windows, VoiceOver with Safari on iOS, and TalkBack with Chrome on Android. With each one, complete the same tasks:
- Navigate the page by headings and by landmarks.
- Fill in and submit a form, including triggering an error and correcting it.
- Open and close a dialog with the keyboard, and check where focus lands.
- Trigger any dynamic update and listen for its announcement.
- Activate every icon-only button and listen to its name.
Testing with people who use screen readers every day goes further: they navigate faster and differently than sighted testers, and they find problems a novice misses.
Questions teams ask
We have never tested with a screen reader. Where do we start?
Start with one. WebAIM’s article on testing with screen readers advises testing your content “in at least one of these” and offers keyboard shortcut lists for JAWS and NVDA. NVDA is free for Windows, and VoiceOver is built into Apple devices. Learn to move by headings, landmarks, and form fields, then try to complete one core task on your site and note where you get stuck.
Do all images need alt text?
All images need an alt attribute. Decorative images get an empty one; informative images get a description of what they convey.
How do we make carousels and accordions accessible?
Follow the ARIA Authoring Practices pattern for each widget, which defines the roles, states, and keyboard behavior. Accordions need header buttons that report expanded or collapsed state; carousels need visible controls, a way to pause any automatic rotation, and a labeled region.
Our site uses icons without text. Is that a problem?
Each icon-only control needs an accessible name, through visible text or an aria-label on the interactive element. When to show a visible label as well is covered in when to use icons instead of text.
Build with native HTML and a logical heading outline, label landmarks, fields, and icon buttons, follow the ARIA Authoring Practices for focus in widgets, and test core tasks with JAWS or NVDA, VoiceOver on iOS, and TalkBack before release.