EZUD Screen Reader Compatibility and ARIA Roles
Screen Reader Compatibility and ARIA Roles
Screen readers translate visual interfaces into spoken or Braille output. They rely on the accessibility tree — a parallel structure browsers build from the DOM, enhanced by ARIA attributes. When the accessibility tree accurately represents the page, screen reader users can navigate, understand, and operate the interface. When it does not, entire sections become invisible or nonsensical.
How Screen Readers Parse a Page
A screen reader does not “read the screen.” It reads the accessibility tree, which is constructed from:
- Native HTML semantics. A
<nav>element becomes a navigation landmark. A<button>becomes an interactive control with an implicit role. An<h2>establishes hierarchy. - ARIA attributes. When native semantics are insufficient, ARIA roles, states, and properties supplement or override the accessibility tree.
- Computed accessible names. The name of each element comes from its text content,
<label>,aria-label,aria-labelledby,altattribute, ortitleattribute — in a defined priority order.
Screen reader users navigate by landmarks, headings, links, form controls, and tables. They jump between these structural elements rather than reading linearly. A page with no landmark regions, no heading hierarchy, and form inputs lacking labels is functionally a blank wall.
The Five Rules of ARIA
The W3C WAI documents five rules for using ARIA. Violating them is the single most common source of screen reader compatibility failures.
Rule 1: Use native HTML if possible. If an HTML element or attribute provides the semantics and behavior you need, use it instead of adding ARIA. A <button> is always better than <div role="button" tabindex="0">.
Rule 2: Do not change native semantics. Do not add role="heading" to a <button>. Do not add role="button" to a heading. Each element has a purpose; overriding it confuses users and assistive technology.
Rule 3: All interactive ARIA controls must be keyboard operable. Adding role="button" to a <span> does not make it keyboard-focusable or give it click/keydown handling. You must also add tabindex="0", Enter and Space key handlers, and visual focus indication. See keyboard navigation essentials.
Rule 4: Do not use role="presentation" or aria-hidden="true" on focusable elements. Hiding an element from the accessibility tree while leaving it in the tab order creates a ghost — the user tabs to something they cannot identify or interact with meaningfully.
Rule 5: All interactive elements must have an accessible name. A button with no text, no aria-label, and no aria-labelledby is announced as “button” — useless for identifying what it does.
Common ARIA Roles and When to Use Them
Landmark Roles
Landmark roles define page regions. Screen reader users can jump between landmarks like chapters in a book.
| Role | HTML Equivalent | Use When |
|---|---|---|
banner | <header> (page-level) | Native element exists — use <header> |
navigation | <nav> | Native element exists — use <nav> |
main | <main> | Native element exists — use <main> |
complementary | <aside> | Native element exists — use <aside> |
contentinfo | <footer> (page-level) | Native element exists — use <footer> |
search | <search> (HTML5.2+) | Use <search> where supported; role="search" as fallback |
region | <section> with accessible name | Generic labeled region |
Notice a pattern: for landmark roles, native HTML elements almost always suffice.
Widget Roles
Widget roles define interactive components. Use them only when no native HTML element provides the same semantics.
| Role | Purpose | Native Alternative |
|---|---|---|
tablist, tab, tabpanel | Tab navigation interface | None — ARIA required |
dialog | Modal dialog | <dialog> (now well-supported) |
alertdialog | Urgent modal requiring response | None — ARIA required |
menu, menuitem | Application-style menus | None (not for navigation menus) |
tree, treeitem | Hierarchical list | None — ARIA required |
combobox | Autocomplete/typeahead | None — ARIA required for custom implementations |
For in-depth implementation guidance, see our ARIA best practices guide.
Live Region Roles
Live regions announce dynamic content changes without moving focus.
aria-live="polite"— Announces changes when the screen reader finishes its current task. Use for status updates, notifications, chat messages.aria-live="assertive"— Interrupts immediately. Reserve for errors and urgent alerts.role="status"— Implicitlyaria-live="polite". Use for form submission confirmations, progress indicators.role="alert"— Implicitlyaria-live="assertive". Use for error messages and time-sensitive warnings.
Screen Reader Testing Across Platforms
| Screen Reader | Platform | Browser Pairing | Cost |
|---|---|---|---|
| NVDA | Windows | Firefox or Chrome | Free |
| JAWS | Windows | Chrome or Edge | Commercial license |
| VoiceOver | macOS / iOS | Safari | Built in |
| TalkBack | Android | Chrome | Built in |
| Narrator | Windows | Edge | Built in |
Each screen reader has quirks. NVDA and JAWS may announce the same ARIA differently. VoiceOver on iOS handles live regions differently than VoiceOver on macOS. Test with at least two screen reader/browser combinations.
Debugging the Accessibility Tree
Chrome DevTools and Firefox DevTools both have accessibility tree inspectors. Open DevTools, navigate to the Accessibility panel, and inspect any element to see its computed role, name, description, states, and properties. If the tree does not match your intent, the screen reader announcement will not match either.
Common debugging scenarios:
- “Button” with no name: The button contains only an icon with no
alt,aria-label, or visually hidden text. - Missing landmark: A
<div class="sidebar">instead of<aside>or<div role="complementary">. - Empty live region: An
aria-liveregion that exists in the DOM but receives content before the screen reader registers it. Insert the container first (empty), then populate it.
Key Takeaways
- Screen readers navigate the accessibility tree, not the visual page — semantic HTML builds the foundation.
- Follow the five ARIA rules: prefer native elements, do not override semantics, ensure keyboard operability, never hide focusable elements, always provide accessible names.
- Test with at least two screen reader/browser combinations (NVDA + Firefox, VoiceOver + Safari).
- Use the browser accessibility tree inspector to debug mismatches between visual output and screen reader announcements.
Next Steps
- Learn when and how to use ARIA in our ARIA best practices guide.
- Build keyboard-accessible interfaces that work in tandem with screen readers.
- Audit your site with automated testing tools to catch missing names, roles, and landmarks.
Sources
- Using ARIA — W3C Working Group Note — The five rules of ARIA and practical usage guidance.
- WAI-ARIA Authoring Practices Guide — Pattern-by-pattern implementation guidance for ARIA widgets.
- WebAIM Screen Reader User Survey — Data on screen reader usage, preferences, and barriers.
- MDN ARIA Roles Reference — Developer documentation for all ARIA roles.
ARIA usage rules referenced from the W3C WAI “Using ARIA” document and the ARIA Authoring Practices Guide (APG). Screen reader behavior may vary by version — test with current releases.