Screen Reader Accessibility: How Websites Work with Screen Readers

Screen reader accessibility: how websites work with screen readers

Screen reader accessibility means building pages so people who use screen readers can access the same content and features as sighted users. A screen reader converts page structure, text and controls into speech or refreshable braille. Popular readers include NVDA, JAWS, VoiceOver and TalkBack.

How screen readers read a page

Screen readers do not read the raw HTML. They read the accessibility tree that the browser exposes. That tree shows each element’s role, accessible name, state and value. Semantic HTML gives the accessibility tree correct roles by default. Where semantics are missing, ARIA can add or change roles and names.

Two main interaction modes

• Linear navigation. The user moves through headings, links and form controls in order.
• Virtual cursor or browse mode. The reader announces text and inline elements for reading content.

Key technical building blocks

Semantic HTML

Use native elements first. For example use <button> for buttons, <nav> for navigation, <form> with labelled inputs and <table> with <th> for headers. Native elements supply roles, states and keyboard support automatically.

Accessible names and labels

A screen reader announces an accessible name for controls. Provide names with visible labels, aria-label or aria-labelledby. For images use the alt attribute. If an image is decorative, use empty alt alt=“” so the reader skips it.

ARIA: use it carefully

ARIA can fill gaps but it is not a replacement for semantic HTML. Use ARIA to expose complex widgets or dynamic status messages. Examples that help:

• role=“dialog” for modal overlays
• aria-live=“polite” to announce non-critical updates
• aria-pressed for toggle buttons

Do not add ARIA roles that conflict with native elements. Avoid misusing aria-hidden to hide content from assistive tech unless you are also hiding it visually.

Keyboard focus and order

Keyboard users move focus with Tab and Shift+Tab. Keep focus order logical and match the visual order. Avoid moving focus unexpectedly. Use tabindex=“0” only to make custom elements focusable. Do not use positive tabindex values.

Live regions and dynamic content

Single-page apps and dynamic components must notify screen readers when content changes. Use aria-live regions for updates, and set the polite or assertive level depending on urgency. When a modal opens, move focus into it and restore focus when it closes.

Common accessibility issues and how to fix them

• Missing labels on form inputs. Fix by adding a visible <label> linked with for or by using aria-labelledby.
• Interactive elements built with <div> or <span>. Replace with native control or add proper role, keyboard handlers and accessible name.
• Images without alt text. Provide meaningful alt text, or empty alt for decorative images.
• Poor heading structure. Use headings in a logical outline: h2, then h3 for subsections.
• Improper use of ARIA. Remove unnecessary ARIA that duplicates native semantics.
• Broken focus management in dialogs and menus. Trap focus inside modals and return it after close.

Testing with screen readers: a practical step-by-step workflow

1. Pick one desktop and one mobile screen reader. For example NVDA on Windows and VoiceOver on macOS or iOS.
2. Start with a quick pass using heading navigation. Check for a clear document outline.
3. Use link and landmark navigation. Ensure navigation elements are discoverable and labelled.
4. Test all forms. Tab through each input, submit and confirm error messages are announced and focused.
5. Operate interactive widgets with keyboard only. Check toggle buttons, menus and dialogs.
6. Trigger dynamic updates. Confirm content added or changed is announced via live regions or focus changes.
7. Do a screen-reader-only test. Turn off visual cues and try to complete primary tasks from the reader output alone.
8. Record issues and fix the highest-priority faults first: missing labels, broken keyboard access, and broken focus.

Combine manual testing with automated tools and the browser accessibility inspector. Automated checks catch many low-hanging issues but they do not replace real screen reader testing.

Short comparison of common screen readers

Screen reader	Platform	Notes
NVDA	Windows	Free and widely used for testing
JAWS	Windows	Commercial. Many enterprise users use it
VoiceOver	macOS, iOS	Built into Apple devices
TalkBack	Android	Built into many Android devices

Quick developer checklist for screen reader accessibility

• Use semantic HTML for structure and controls.
• Provide visible labels and accessible names for all controls.
• Ensure correct heading order and meaningful headings.
• Make all interactive controls keyboard operable.
• Manage focus for dialogs, overlays and single-page navigation.
• Use ARIA only when native elements cannot provide the needed semantics.
• Confirm dynamic changes are announced with live regions or focus updates.
• Test with at least one desktop and one mobile screen reader.

Where to learn more

Refer to WCAG 2.1 success criteria for formal standards. WAI and WebAIM publish practical guides and examples. Combine standards reading with hands-on screen reader testing to validate real behaviour.