Screen Reader Support

Screen reader support means a Design System works with assistive technology — NVDA (Windows), JAWS (Windows/Mac), VoiceOver (Mac/iOS), TalkBack (Android) — that reads the page aloud and lets visually impaired users navigate and interact.

Screen readers don't see CSS or layout. They read semantic HTML and ARIA attributes. A component is "screen reader ready" when it announces:

Its name: A button says "Submit", a checkbox says "Remember me".
Its role: "Button", "checkbox", "menu item", "modal dialog".
Its state: "Checked", "disabled", "expanded", "error".
How to interact: Implicitly, if the role is correct. A button announces that pressing Enter activates it.

In practice, this means:

Use semantic HTML. <button> not <div onclick>. <a href> not <div> with click handler. <label> with <input> not a label div nearby.
Add ARIA when needed. If you can't use semantic HTML (maybe your design breaks out of form conventions), use role="button" and aria-label to fill the gaps. But semantic HTML is always better.
Label everything. Inputs need <label>. Buttons need visible text or aria-label. Icons need aria-label or a label.
Announce dynamic changes. If content appears or disappears, use aria-live to tell screen readers.

The Design System documents this in component documentation — showing developers which ARIA attributes to add and what semantic HTML looks like. Most components should work out of the box if built with semantic HTML; complex components (Menu, Dialog, Tabs) need JavaScript to manage focus and ARIA state.

Testing: actually use a screen reader. NVDA is free; VoiceOver is built into Mac. Listen to how the component announces itself. Does it make sense? Can you navigate with arrow keys? Can you activate it?

Related: WAI-ARIA · WCAG · Keyboard navigation · Focus management · Accessible design