Screen reader compatibility

Screen readers are assistive technologies that help users navigate and interact with digital interfaces. Popular examples include NVDA, JAWS, and VoiceOver.

For screen readers to work properly, interfaces must expose the right information: structure, labels, states, and relationships. If this is missing or broken, users cannot understand or use your product.

Good compatibility benefits not only blind users but also people with cognitive impairments or temporary limitations (for example: using a device without sight in bright light).

Guidelines for designing compatible experiences with screen readers.

Use semantic HTML whenever possible

Native HTML elements (like <button>, <input>, <nav>) provide built-in accessibility that screen readers understand. Avoid recreating them with divs and spans.

References:

• Using HTML semantics – W3C
• Semantic structure – WebAIM

Provide clear and descriptive labels

Every interactive element must have a label, either visible or programmatically (aria-label, aria-labelledby). Labels should describe purpose, not state (“Search site,” not just “Search”).

References:

• WCAG 3.3.2: Labels or instructions

Announce states and roles correctly

Ensure screen readers can detect states like checked/unchecked, expanded/collapsed, selected/unselected. Use ARIA attributes (aria-checked, aria-expanded) when semantics alone aren’t enough.

References:

• States and properties – MDN Mozilla

Maintain logical reading and focus order

Content must flow in a meaningful order that matches the visual layout. Use headings, landmarks, and proper DOM order. Don’t rely only on CSS positioning.

References:

• WCAG 1.3.2: Meaningful sequence

Support skip links and landmarks

Provide skip links (for example: “Skip to main content”) and ARIA landmarks (role="main", role="navigation") so users can jump quickly to sections.

References:

• WCAG 2.4.1: Bypass blocks

Test with multiple screen readers

Behavior differs between screen readers and browsers. Test with at least NVDA (Windows), JAWS (Windows), and VoiceOver (Mac/iOS).

References:

• Accessibility for everyone – Laura Kalbag

Frequent mistakes that break screen reader compatibility.

Building custom UI with divs and spans only

These are not announced by screen readers unless roles and labels are added.

Not labeling form fields and buttons

Unlabeled controls are invisible to screen reader users.

Forgetting dynamic content updates

Changes (for example: error messages, live notifications) need aria-live to be announced.

Breaking reading order with CSS positioning

Screen readers follow DOM order, not visual placement. Out-of-order markup confuses users.

Key takeaways for screen reader compatibility.

• Use semantic HTML first, it’s the most reliable foundation.
• Always provide clear labels for interactive elements.
• Ensure roles, states, and properties are properly exposed.
• Keep DOM and visual order aligned for logical reading flow.
• Support skip links, landmarks, and dynamic updates.
• Test with real screen readers across platforms.

Screen reader compatibility isn’t optional, it’s fundamental to building products that include everyone.

Scenario: Screen reader audit

Use when auditing an interface for screen reader compatibility: ensuring that all visual information is communicated programmatically to blind and low-vision users.

You are a UX-focused design agent. Audit [interface/feature] for screen reader compatibility and provide specific fixes.

Rules:
- Semantic HTML first — native elements have built-in accessibility behavior:
  Use: button, a, nav, main, header, footer, h1-h6, ul, ol, table
  Replace: div onclick and span onclick with native elements

- Landmark regions — every page must have:
  main — one per page
  nav with aria-label — multiple allowed, each labeled
  header, footer, aside with aria-label

- Every interactive element needs an accessible name:
  Buttons: visible text or aria-label
  Links: descriptive text (not "click here")
  Inputs: label with for/id associated with each input
  Icon buttons: aria-label describing the action
  Images used as buttons: alt text describing the action

- Dynamic content announcements:
  New content after user action: aria-live="polite"
  Urgent alerts and errors: aria-live="assertive" or role="alert"
  Loading states: aria-busy="true" with aria-label="Loading [content type]"

- Reading order: DOM order must match visual order
  Fix visual-only reordering with CSS (order property, position) without changing DOM

- Test with:
  VoiceOver (Mac): Cmd+F5
  NVDA (Windows): free download
  Navigate by: Tab, H (headings), B (buttons), F (form fields), L (lists)

Constraints:
- Never use ARIA to override semantic HTML — use native elements first
- Never announce decorative images — use alt="" for decorative images
- Never build custom interactive components without ARIA keyboard patterns