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.
- 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
altattribute 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.
- 1
Always use semantic HTML instead of relying only on <div> and <span>.
- 2
Provide descriptive
alttext 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.
Scenario Questions
0-2 years experience
- 1You need to add a new button to a page. How would you write the HTML so that a screen reader announces it correctly?
- 2If 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
- 1We 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.
- 2Our 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
- 1Design an accessible component library that ensures screen readers correctly interpret dynamic content updates, such as live regions. What patterns would you enforce and why?
- 2When 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
- 1Our 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?
- 2Across 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?