Blind Users Navigating Websites: Screen Readers & Semantics
Author
Redaksi Disabilitas.com
Blind Users Navigating Websites: Diving into Screen Readers
For sighted users, a web page is a two-dimensional visual experience full of colors, grid layouts, images, and typography. However, for blind users, the web is a one-dimensional linear experience read aloud line-by-line by Screen Reader software.
Understanding how Screen Readers work—and the real-world challenges faced by their users—is the first fundamental step in creating truly inclusive digital products. This article will technically dissect how interface designs are converted into audio and why writing semantic HTML code is the key.
1. How Do Screen Readers Work?
Screen readers like JAWS, NVDA (Windows), and VoiceOver (macOS/iOS) do not visually "see" the screen. Instead, they interact directly with the Accessibility Tree—a data representation built by the browser based on the Document Object Model (DOM).
The "Virtual Buffer" Concept
When a page loads, the screen reader creates a virtual copy of the page content called the Virtual Buffer. Users navigate this buffer using the keyboard (usually the up/down arrow keys), not by moving a mouse cursor.This is why the order of elements in your HTML code (DOM order) is so crucial. If an element is visually positioned on the left, but written at the very bottom of the HTML, a screen reader user will hear it last.
[!CAUTION] The Danger of CSS Manipulation: Do not use CSS properties like
float,flex-direction: row-reverse, ororderto radically change the visual position of elements if it breaks the logical DOM order. Screen readers read the DOM order, not the visual order.
2. Navigating Through HTML5 Landmarks
Blind users rarely read a page sequentially from top to bottom. They use screen reader shortcuts to jump directly to the section they need.
Landmarks are the primary way users "map" a page. With the press of a key, they can see a list of the page's main areas.
Semantic Implementation Example
Avoid using generic `<!-- BAD: Has no semantic meaning -->
<div class="header">...</div>
<div class="sidebar">...</div>
<div class="content">...</div>
<div class="footer">...</div>
<!-- GOOD: Recognized as Landmarks by Screen Readers -->
<header>...</header>
<aside>...</aside>
<main>...</main>
<footer>...</footer>
If you are forced to use <div> (e.g., due to legacy framework constraints), you must use the role attribute from the ARIA specification: <div role="main">. However, the first rule of ARIA is: Use native HTML whenever possible.
3. Heading Hierarchy as the Page Framework
Besides landmarks, the second most popular navigation method for blind users is jumping between Headings (<h1> through <h6>). Screen readers allow users to press the "H" key to jump to the next heading, providing a quick overview of the topics covered on the page.
The Golden Rules of Headings:
1. Use only one ``:
The `` should describe the main purpose of the page (usually matching the `` element).
2. Do not skip levels: Do not use an `` right after an `` just because you visually prefer its font size. The order must be logical (`` -> `` -> ``).
3. Separate visual style from structure: If an `` feels too large, use CSS to reduce its size, do not change its HTML tag to ``.
4. Unambiguous Link Text
Imagine turning on a screen reader feature that summarizes all the links on a page into a List of Links.
If you use text like:
- "Click here"
- "Read more"
- "Learn more"
The list of links a blind user will hear is: "Click here, Click here, Read more". This provides absolutely no context about where the link will take them.
Descriptive Link Solution
Link text must be understandable on its own (standalone).
- Bad: To view the financial report, [click here].
- Good: Please review our [annual financial report].If the visual design insists on using a button that says "Read More", you can visually hide additional context text (using an .sr-only class) that remains readable by screen readers.
<a href="/news/123" class="btn">
Read more <span class="sr-only">about the new accessibility feature release</span>
</a>
5. Conclusion: Accessibility is Accountability
Writing accessible code is essentially writing good, clean, standard-compliant HTML code. When you ignore HTML semantics, you not only make it harder for search engines (SEO), but you literally close the door to your site for millions of users who rely on assistive technologies.
Start by unplugging your mouse, turning on your computer's built-in Screen Reader (Narrator on Windows or VoiceOver on Mac), and trying to make a purchase or fill out a form on the website you are currently building.
References
This article is compiled by referencing the principles of instructional design, disability navigation, and advanced HTML semantics as thoroughly discussed in Practical Web Accessibility by Ashley Firth. The deep technical understanding of Screen Readers and keyboard navigation is adapted directly from the inclusive design philosophy taught in the literature.
` right after an `` just because you visually prefer its font size. The order must be logical (`` -> `` -> ``).
3. Separate visual style from structure: If an `` feels too large, use CSS to reduce its size, do not change its HTML tag to ``.
4. Unambiguous Link Text
` -> `` -> ``).
3. Separate visual style from structure: If an `` feels too large, use CSS to reduce its size, do not change its HTML tag to ``.
4. Unambiguous Link Text
`).
3. Separate visual style from structure: If an `` feels too large, use CSS to reduce its size, do not change its HTML tag to ``.
4. Unambiguous Link Text
`.
4. Unambiguous Link Text
Imagine turning on a screen reader feature that summarizes all the links on a page into a List of Links.
If you use text like:
- "Click here"
- "Read more"
- "Learn more"
The list of links a blind user will hear is: "Click here, Click here, Read more". This provides absolutely no context about where the link will take them.
Descriptive Link Solution
Link text must be understandable on its own (standalone). - Bad: To view the financial report, [click here]. - Good: Please review our [annual financial report].If the visual design insists on using a button that says "Read More", you can visually hide additional context text (using an .sr-only class) that remains readable by screen readers.
<a href="/news/123" class="btn">
Read more <span class="sr-only">about the new accessibility feature release</span>
</a>
5. Conclusion: Accessibility is Accountability
Writing accessible code is essentially writing good, clean, standard-compliant HTML code. When you ignore HTML semantics, you not only make it harder for search engines (SEO), but you literally close the door to your site for millions of users who rely on assistive technologies.
Start by unplugging your mouse, turning on your computer's built-in Screen Reader (Narrator on Windows or VoiceOver on Mac), and trying to make a purchase or fill out a form on the website you are currently building.
References
This article is compiled by referencing the principles of instructional design, disability navigation, and advanced HTML semantics as thoroughly discussed in Practical Web Accessibility by Ashley Firth. The deep technical understanding of Screen Readers and keyboard navigation is adapted directly from the inclusive design philosophy taught in the literature.What do you think?
Give your reaction to this article
Explore Related Insights
Understanding the Legal Landscape and Digital Accessibility Regulations (ADA, EAA, etc.)
The global legal landscape of web accessibility: From the Americans with Disabilities Act to the European Accessibility Act.
The Dangers of Disability Simulations and Building Inclusive Empathy in Companies
Why wearing a blindfold to simulate blindness is harmful. Learn how to build a true inclusive design culture.
Six Keys for Accessible Online Course Development
A strategic guide for instructors and instructional designers to ensure e-learning materials are barrier-free.