By the end of this lesson you can
- Explain how screen readers work and how people navigate with them.
- Design with semantic structure: headings, landmarks, lists and labels.
- Annotate designs with accessible names and roles.
The idea
A screen reader turns on-screen content into speech or braille. Common ones are JAWS and NVDA on Windows, VoiceOver on Apple devices and TalkBack on Android.
How people navigate
Screen reader users rarely listen to a page from top to bottom. They jump by headings, landmarks (header, navigation, main, footer), links and form fields. That makes structure essential.
Semantics
Semantic code describes what things are: a button is a button, a heading is a heading, a list is a list. Screen readers announce the role (button), name (Add to basket) and state (expanded, selected).
What designers specify
- Heading structure: one H1 per page, logical levels without skipping.
- Landmarks: which areas are header, navigation, main and footer.
- Accessible names for icon buttons ("Close dialog", not "X").
- Unique link text: "Read more about pricing", not five "Read more" links.
- Alt text for meaningful images; decorative images marked as such.
- Announcements for dynamic changes ("3 results found").
Why it matters in real projects
Without good structure and labels, screen reader users face a confusing stream of "button, button, link, image". Designers decide much of the structure and naming, so annotating it removes guesswork for developers. It also improves search engine understanding and benefits voice control users, who say the names of controls to activate them.
A realistic example
A screen reader user visits a recipe site. Every recipe card has a heart icon announced as "button" with no name, and headings jump from H1 to H4. Navigating by heading is useless, and they cannot tell what each button does.
The designer annotates the page: H1 for the page title, H2 for each recipe name, heart buttons named "Save [recipe name]" with a pressed state, and a live announcement "Saved to your recipes". After the fix, the user can scan recipes by heading and save them confidently.
Step by step
Try a screen reader
Turn on VoiceOver or NVDA and browse a familiar site.
Navigate by headings
Use heading navigation and note gaps.
Annotate headings
Mark heading levels on your design.
Annotate landmarks
Mark header, nav, main and footer regions.
Name controls
Write accessible names for icon buttons and links.
Specify announcements
Note what should be announced on dynamic changes.
Common mistakes
Mistake Choosing heading levels for size.
Instead Choose levels for structure; style separately.
Mistake Icon buttons without names.
Instead Give every control an accessible name.
Mistake Repeated vague link text.
Instead Make links meaningful out of context.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 1 h
Accessibility annotations
Annotate a screen for screen reader users.
Steps
- Annotate heading levels and landmarks.
- Name every icon button and ambiguous link.
- Write alt text or mark images decorative.
- Specify announcements for dynamic changes.
Deliverable
An annotated screen ready for developers.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- Screen readers announce role, name and state.
- Users navigate by structure.
- Designers specify headings, landmarks, names and alt text.
- Annotations remove guesswork.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
Your notes
Marking complete updates your course and roadmap progress.