Screen readers

Screen readers (NVDA, JAWS, VoiceOver, TalkBack) convert the accessibility tree into speech or braille. Interview answers should cover accessible names, descriptions, reading order, headings navigation, and live regions—not memorizing every verbosity setting.

					<button aria-label="Close dialog">×</button>
<div role="status" aria-live="polite" id="cart-status"></div>
				

| Concept | Practice | |---------|----------| | Accessible name | Visible text, `aria-label`, or `aria-labelledby` | | Description | `aria-describedby` for hints and errors | | Reading order | DOM order matches visual order | | Live regions | `aria-live="polite"` for non-urgent updates |

Test with at least one desktop and one mobile screen reader on critical flows—automated tools do not speak content aloud.

On interviews: difference between name and description; when `aria-hidden` is appropriate; polite vs assertive live regions; virtual cursor vs focus.

Common pitfalls: duplicating visible text in `aria-label`; announcing every keystroke; empty buttons; decorative images with verbose alt text.

The trade-off is announcement verbosity versus timely feedback for dynamic UIs.

Checklist:

• Every control has a meaningful accessible name.
• Dynamic status uses live regions intentionally.
• Hide decorative content from the tree.
• Smoke-test checkout/login with VoiceOver or NVDA.