← Go Back

Screen Reader Compatibility

What is screen reader compatibility?

Screen reader compatibility means your product can be used effectively with assistive technology that reads content aloud (e.g. NVDA, JAWS, VoiceOver, TalkBack). Text, structure, and interactive elements must be exposed so users can navigate, understand, and operate the interface. It builds on semantic HTML, keyboard navigation, and ARIA when needed.

Use it when: you’re building or auditing any web or app interface. WCAG and accessibility require that content and functionality be available to assistive technologies.

Copy/paste checklist

  • [ ] Semantic HTML – Use headings (h1–h6), landmarks (nav, main, aside), buttons and links for actions, labels for form controls. Don’t rely on divs and spans for structure or behaviour.
  • [ ] Text alternatives – Images have alt text (or are marked decorative); non-text content has a text equivalent.
  • [ ] Labels and names – Every form field has an associated label; every interactive element has an accessible name (visible or via aria-label/aria-labelledby).
  • [ ] ARIA when needed – Use ARIA for custom widgets (e.g. tabs, dialogs) when native HTML isn’t enough; don’t override good semantics.
  • [ ] Keyboard and focus – Keyboard navigation and focus management work; screen reader users often navigate by keyboard.
  • [ ] Test – Test with at least one screen reader (e.g. NVDA or VoiceOver) on one key flow; fix what’s missing or wrong.

Why screen reader compatibility matters

  • Many users with visual or reading-related disabilities rely on screen readers to access content and apps.
  • WCAG requires that content be perceivable and operable by assistive tech; screen readers are a primary test.
  • Accessibility isn’t complete without it; automated checks can’t replace real screen reader testing.
  • Good structure (headings, landmarks, labels) also helps SEO and usability for everyone.

What good screen reader compatibility includes

Checklist

  • [ ] Headings – Logical heading levels (one h1, then h2, h3 as needed); no skipping levels; headings describe the section.
  • [ ] Landmarks – nav, main, aside, header, footer (or ARIA roles) so users can jump by region.
  • [ ] Forms – Every input has a visible or programmatic label; errors are associated and announced.
  • [ ] Dynamic content – Live regions (aria-live) for updates that users need to hear (e.g. errors, success messages); focus management when context changes.
  • [ ] No information only by shape or position – “Click the green button” isn’t enough; use name/label.
  • [ ] Tested – At least one flow tested with a real screen reader; issues documented and fixed.

Common formats

  • Semantic HTML first: Use native elements (button, a, input, label, heading, main, nav) so screen readers get behaviour and structure for free.
  • ARIA to supplement: Use ARIA roles, states, and properties when you build custom components (e.g. role="dialog", aria-expanded, aria-describedby).
  • Testing: Manual test with NVDA (Windows), VoiceOver (macOS/iOS), or TalkBack (Android) on a representative flow.

Examples

Example (the realistic one)

Page: Settings. Structure: One h1 “Settings”; h2 per section (Profile, Notifications). Form: Each input has a visible

Common pitfalls

  • No headings or wrong order: Screen reader users can’t skim by heading; or levels jump (h1 to h4). → Do this instead: Use one h1 and a logical h2/h3 structure; don’t skip levels.
  • Unlabelled controls: Input or button has no accessible name. → Do this instead: Use
  • Decorative images not hidden: Screen reader reads “image” or filename. → Do this instead: Use alt="" for decorative images, or aria-hidden="true" where appropriate.
  • Dynamic updates not announced: Error or success message appears but isn’t announced. → Do this instead: Use aria-live (polite or assertive) for important updates, or move focus to the message.
  • Only automated testing: axe or similar doesn’t catch everything. → Do this instead: Run at least one manual test with a screen reader on a key flow.
  • Screen reader vs keyboard: Keyboard navigation is required for most screen reader use; fix keyboard first, then verify with a screen reader.
  • Screen reader vs ARIA: ARIA exposes roles, states, and names to assistive tech; use it when HTML isn’t enough. Semantic HTML is still the base.
  • Screen reader vs WCAG: WCAG criteria (e.g. 1.1.1 Non-text Content, 4.1.2 Name Role Value) are what screen reader compatibility helps you meet.
  • Accessibility – screen reader compatibility is part of it.
  • WCAG – conformance requires assistive tech support.
  • Keyboard navigation – screen reader users typically use the keyboard.
  • ARIA – for custom widgets and dynamic content.
  • Focus management – focus and announcements work together.
  • Microcopy – labels and messages are what screen readers read.

Next step

Pick one critical flow and test it with one screen reader (e.g. NVDA or VoiceOver). Navigate by headings and Tab; complete the flow; note missing labels, wrong order, or unannounced updates. Fix the issues and retest. Read ARIA if you have custom components that need roles and states.

Related Terms