How do screen readers interpret HTML

How Screen Readers Interpret HTML

Screen readers are assistive technologies that convert on-screen content into speech or Braille output. They rely heavily on the structure and semantics of HTML to present information in a meaningful way to users.

How Screen Readers Use HTML

1
Semantic Elements – Tags like <header>, <nav>, <main>, and <footer> are announced as landmarks, helping users understand page structure.
2
Headings – <h1>–<h6> tags are read as a structured outline, allowing users to navigate sections quickly.
3
Links and Buttons – Elements like <a> and <button> are identified by role and accessible name (from text or aria-label).
4
Images – The alt attribute is read aloud to describe images; if it is missing, the file name may be announced instead.
5
Forms – <label> elements are read alongside inputs so users know what each field is for.
6
Tables – Headers (<th>) and captions provide context so users can understand relationships between rows and columns.

If HTML is coded semantically and accessibly, screen readers can create a logical mental model of the page. Poor markup or missing attributes can confuse users and make navigation difficult.

Best Practices

1
Always use semantic HTML instead of relying only on <div> and <span>.
2
Provide descriptive alt text for images.
3
Ensure headings are in logical order (no skipping from <h1> to <h4>).
4
Associate form fields with <label> elements.
5
Use ARIA roles and properties only when native HTML does not provide the needed semantics.

Difficulty: 6/10

Topics: semantic HTML, ARIA roles, accessibility tree

Scenario Questions

0-2 years experience

1
You need to add a new button to a page. How would you write the HTML so that a screen reader announces it correctly?
2
If a screen reader reads 'link' for a plain <div> that looks like a button, what is likely wrong and how would you fix it?

2-5 years experience

1
We shipped a modal dialog, but users report that screen readers don't announce its title. Walk me through how you would investigate and fix it.
2
Our product uses custom icons with <svg> elements that have no text. Why might a screen reader ignore them, and what changes would you make?

5-8 years experience

1
Design an accessible component library that ensures screen readers correctly interpret dynamic content updates, such as live regions. What patterns would you enforce and why?
2
When implementing server‑side rendering for a large SPA, what considerations are needed to keep the accessibility tree consistent for screen readers across hydration?

8+ years experience

1
Our legacy codebase mixes presentational tables with data tables, causing screen reader confusion. How would you plan a migration strategy that balances technical debt, SEO, and accessibility?
2
Across multiple product teams we need a unified approach to ARIA role usage and HTML semantics. What governance and tooling would you put in place to ensure consistent screen‑reader behavior at scale?

Follow-up Questions

❓Can you give an example of an ARIA attribute that changes how a screen reader interprets an element?
❓What tools would you use to verify your changes work for assistive technology?
❓How do you balance accessibility fixes against other feature priorities?