Screen-reader compatibility

Screen Reader Compatibility

Screen readers do not all interpret HTML and ARIA identically. How an interface is announced depends on the combination of operating system, browser engine, accessibility API, screen reader and navigation mode (browse/virtual cursor vs. focus/forms mode).

1. Primary Browser + Screen Reader Pairings

Target and evaluate markup against standard real-world pairings:

• macOS / iOS: VoiceOver + Safari (WebKit). Note: VoiceOver in Chrome has subtle differences, and WebKit removes list semantics (role="list") from <ul style="list-style: none"> unless role="list" is explicitly restored when list count semantics matter.
• Windows:
  • NVDA + Firefox or Chrome/Edge.
  • JAWS + Chrome or Edge.
• Android: TalkBack + Chrome (explore-by-touch and swipe navigation).

2. Browse Mode (Virtual Cursor) vs. Focus / Application Mode

Desktop screen readers on Windows (NVDA, JAWS) operate in two primary modes:

• Browse / Virtual Cursor Mode: the user navigates headings (H), landmarks (D/R), links (K), buttons (B), tables (T), lists (L) and form fields (F), and uses Arrow keys to read line-by-line or character-by-character through static text.
  • Implication: if you intercept ArrowUp/ArrowDown on a regular container or put role="application" on a page wrapper, you destroy the user's ability to read text and navigate by headings/landmarks!
• Focus / Forms Mode: entered automatically when focus lands on a text <input>, <select>, role="combobox", role="tablist", role="menu", role="slider" or role="grid", passing keystrokes directly to the widget.
  • Rule: never apply role="application" to an entire page or layout region; reserve it only for self-contained canvas/spreadsheet surfaces that manage 100% of keyboard navigation and announcements themselves.

3. Concise, Natural Announcements (Speech Ergonomics)

Screen reader users listen to announcements linearly at high speech rates. Avoid verbose or redundant markup:

• Do not duplicate role words inside aria-label:
  • Bad: <button aria-label="Close button"> -> announced as "Close button, button".
  • Bad: <nav aria-label="Main navigation"> -> announced as "Main navigation, navigation".
  • Good: <button aria-label="Close"> and <nav aria-label="Main">.
• Avoid giant concatenated accessible names: when a card or table row contains a title, status badge, timestamp, description and three action buttons, do not wrap the entire card in a single <button> or <a href> that reads a 60-word paragraph as its accessible name. Instead, make the card heading the primary link (<a href="...">) and stretch its clickable hit area with a CSS ::after pseudo-element if full-card clickability is desired.
• Hide purely decorative or redundant visual tokens:
  • Add aria-hidden="true" to decorative icons, visual divider glyphs (|, •), duplicate visual badges and background illustrations.
  • Ensure aria-hidden="true" is never placed on a focusable element or its ancestor.

4. Tables, Lists & Description Relationships

• Data tables: ensure <th> cells have explicit scope="col" or scope="row" so cell coordinates are announced when moving across columns and rows (Ctrl+Alt+Arrow in NVDA/JAWS, VO+Arrow in VoiceOver).
• Supplementary descriptions (aria-describedby): use aria-describedby for helper text, format hints ("At least 12 characters"), keyboard shortcut hints or field error messages so they are read after a short pause following the control's name and role without polluting the primary accessible name.