Screen Readers: Designing for a Non-Visual UI
A screen reader navigates your UI's invisible DOM structure, not its visual layout. Think of it as a text adventure where headings are rooms and links are doors. This is essential for all web UIs, checked via alt text and keyboard focus.
Why it exists
The web is a visual medium by default, but its underlying technology is structural. Screen readers exist to bridge this gap for people with visual impairments, making the structural web audible and navigable. Without this translation from visual to non-visual, a large portion of the population is excluded from digital experiences.
The mental model
Think of your webpage not as a visual canvas, but as a structured document, like an outline for a book. A screen reader user doesn't "see" the page; they navigate this outline. They can jump between chapters (H1, H2 headings), get a list of all illustrations (images with alt text), or quickly find a specific form to fill out. If your outline is messy, missing, or illogical, the "book" is unreadable.
How it works
A screen reader is software that parses the Document Object Model (DOM) of a web page, not the visual rendering. It identifies semantic HTML elements like headings, links, and forms. The user navigates this structure using keyboard commands, like pressing 'H' to cycle through all headings or 'F' to find the next form field. The reader announces the element's type and content, such as "Heading level 2, Contact Information" or "Link, Download Report".
When to use it
Designing for screen readers is not optional; it's a core part of building inclusive and compliant web experiences. You must consider it for any website or application. Key practices include: ensuring all interactive elements are keyboard-focusable, providing descriptive alt text for images that convey information, using a logical heading structure to outline the page, and associating labels with form inputs.
When not to use it
You don't "use" a screen reader experience; you design for it. Deprioritizing accessibility is only conceivable for purely aesthetic, non-interactive content that will never be used by a diverse audience—a practically nonexistent scenario. Even a graphical chart needs a text summary or a link to a data table. Ignoring accessibility is a significant business and legal risk.
One canonical example
A user wants to find contact information. On a well-structured site, they use their screen reader to press 'H' until they hear "Heading Level 2, Contact Us". They then navigate the content under that heading. On a poorly structured site using only generic tags, the screen reader sees a wall of text. The user cannot jump to the relevant section and must listen to the entire page from top to bottom, hoping to find the information. The first experience is efficient; the second is a usability failure.
Interview question
Which design practice is most critical for enabling screen reader users to efficiently navigate and locate specific information on a web page?
- a.Ensuring all interactive elements are keyboard-focusable and have clear focus indicators.
- b.Implementing a logical and hierarchical structure using semantic headings (H1, H2, etc.).Correct
- c.Minimizing the total amount of text on the page to reduce listening time.
- d.Providing descriptive alt text for all informational images.
Why? this is the answer
The card emphasizes that screen readers navigate a page's structural outline, and semantic headings (H1, H2, etc.) act as 'chapters' or 'rooms,' enabling users to efficiently jump to specific sections. While other options are important for accessibility, they do not provide the primary mechanism for quick structural navigation to locate information.
Just read this? Test yourself on what you have been reading.
Read the original → w3.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on accessibility — each one lists the topics its interview covers.
See open roles