Designing for screen readers means preserving structure, relationships, names, roles, states, values, reading order, and status in programmatic form. Start with native semantic elements, meaningful content order, explicit labels, and predictable focus. Annotate dynamic changes and test implemented workflows with screen readers because a design file cannot establish actual accessibility.
Who this is for: Designers and product teams documenting how interface meaning and dynamic behavior should work beyond the visual layer.
- Express headings, landmarks, lists, tables, labels, instructions, and relationships in a meaningful content order.
- Give controls clear names and expose roles, states, values, errors, and status without duplicative announcements.
- Test the built workflow with keyboard and screen readers instead of treating annotations as conformance evidence.
Design the content structure
Create a logical reading order independent of visual coordinates. Specify page title, landmarks, heading hierarchy, lists, table headers, groups, and relationships. WCAG 2.2 criterion 1.3.1 addresses information and relationships conveyed through presentation, while other criteria cover sequence and sensory reliance in applicable contexts.
Use real text in designs so heading meaning, repeated links, and instructions can be reviewed. Avoid heading levels chosen only for visual size. A visual card collection may need a list, while a comparison grid may need table semantics. The correct structure follows meaning and interaction, not the component's appearance.
Name controls and content
Every control needs a name that distinguishes its purpose in context. Visible labels should usually contribute to the accessible name so speech and visual references align. Icon-only buttons need explicit names, and repeated actions may need the related object, such as 'Remove Ana from editors,' when surrounding context is not programmatically clear.
Alternative text should convey the image's purpose in context, not mechanically describe every pixel. Decorative images should not add noise. Complex charts need a text alternative or data access appropriate to the information and task. Do not duplicate a caption word for word through unnecessary alternative text.
Specify dynamic behavior
WCAG 2.2 criterion 4.1.2 addresses programmatically determinable names, roles, states, and values for user-interface components. Annotate expanded, selected, pressed, checked, invalid, required, and disabled behavior where relevant. Use native semantics before adding custom ARIA, because incorrect ARIA can misrepresent an otherwise usable control.
For dynamic updates, decide whether the message needs announcement, focus movement, both, or neither. Criterion 4.1.3 covers certain status messages that can be exposed without receiving focus. Routine updates should not interrupt repeatedly. Errors and modal transitions need deliberate focus and reading-order behavior tied to the person's next task.
Test implemented journeys
Review designs through a text outline and annotation pass, then test the actual interface with keyboard and supported screen readers. Move by headings, landmarks, controls, links, forms, and tables as appropriate. Verify names, state changes, errors, status, overlays, route changes, and return after an action removes content.
Screen-reader combinations differ, so define supported platforms from product context and risk. Automated checks can find missing names or invalid markup but cannot judge whether announcements are useful or workflow order makes sense. Include relevant disabled users in research while avoiding claims that a few sessions guarantee conformance.
Annotate a hypothetical disclosure list
Hypothetical settings page shows expandable team sections with icon-only edit and remove actions.
- Specify a page heading, settings landmark context, team list, and meaningful order before visual columns are applied.
- Make each hypothetical team disclosure a button with expanded state and a name tied to that team.
- Name repeated actions with the hypothetical team, expose deletion confirmation, and define focus after removal.
- Test headings, controls, state announcements, modal behavior, and resulting status in the implemented page.
Screen-reader design annotation
Attach semantic and dynamic intent to each consequential workflow.
- Page title, landmarks, headings, lists, tables, groups, reading order, and route-change behavior.
- Control type, visible label, accessible name, description, role, state, value, requirement, and error link.
- Image purpose, alternative text decision, caption, complex-graphic summary, and underlying data access.
- Dynamic event, status announcement, live-region need, focus movement, modal entry, close, and return.
- Keyboard path, screen-reader matrix, automated check, manual result, user evidence, defect, and owner.
Common mistakes
- Using visual position such as 'on the right' as the only way to identify instructions or controls.
- Giving several icon buttons the same generic accessible name even though they affect different objects.
- Adding aggressive live announcements for every update and repeatedly interrupting the person's current reading.
Try one
A save completes without moving focus. Should the design always move focus to the success message?
No. A strong answer considers whether moving focus would disrupt the next task. A concise status message can often be exposed programmatically under criterion 4.1.3 while focus remains on the initiating control. If save changes the available workflow or requires a decision, movement may be justified. The implemented behavior needs screen-reader testing in context.
Sources
- W3C WCAG 2.2 name, role, value criterionCriterion 4.1.2 guidance for programmatically determinable control names, roles, states, and values.
- W3C WCAG 2.2 info and relationships criterionCriterion 1.3.1 guidance for programmatically preserving structure and relationships conveyed visually.
- W3C WCAG 2.2 status messages criterionCriterion 4.1.3 guidance for exposing status messages without moving focus unnecessarily.