What are screen readers, how do they navigate a website, and how can we make our HTML more screen reader-friendly?
Screen Readers and Accessibility
Chances are good you've heard something about screen readers already in your programming journey. It's often mentioned when you're first learning how to embed images into an HTML document, in the context of adding alt tags to images. (I'll explore alt tags more in an upcoming post.) What often isn't discussed is what a screen reader is.
A screen reader is software that lets a blind or visually-impaired user consume information from a computer screen in another format, like audio or braille.
One common misconception is that screen readers are simply text-to-speech software. While synthesized speech is a component of any screen reader, it is only one of several features. A user might not even use this audio feedback. They could connect a refreshable braille display to render the screen reader's output instead. A screen reader is also far more than a "reader"—it's a tool for navigating and using a computer. Screen readers don’t merely repeat the text on the screen, they interpret visual cues—like images, links, buttons, headings, menus, and forms—and allow users to interact with those elements.
Before we get much further, an example of this technology in action would be helpful. Marc Sutton of the University of California San Francisco created an excellent demonstration of how a screen reader navigates a site back in 2016. Take a couple of minutes now to watch this brief demo. (Note: At the end of the video, Marc demonstrates some issues with HTML tables. We won't be discussing those in this post; tables are another topic warranting a post of their own.)
In the video, Marc shows how a screen reader user can use built-in commands to navigate. These shortcuts let users scan a webpage and drill down on areas of interest. Users can jump around to different sections using headings and can also listen to a list of links pulled from the page to find what they're looking for quickly.
A screen reader is a very powerful tool to have at one's disposal. However, it can only perform these handy shortcuts if a page has the proper underlying structure.
Here are three essential areas to consider when building a new HTML document. These steps will help screen reader users easily navigate our page without spending hours reading through our content line-by-line to find what they need.
Steps for Improving Screen Reader Accessibility
Include a Descriptive Page Title
The first step we can take when setting up an accessible HTML document starts at the top: the page's title itself.
The 'title' I'm referring to in this case is the one that displays within your browser's tabs or along the top of the window. It's defined using the <title> tag in the <head> (metadata) section of an HTML document.
<!DOCTYPE html>
<html lang="en">
<head>
<link rel="stylesheet" type="text/css" href="style.css">
<!--This is where you'll define the page title:-->
<title>Title</title>
</head>
<body>
</body>
</html>
The title serves an essential purpose for screen reader users. It's the first thing the screen reader announces upon opening a page or switching to that page from a different tab. A sighted user might decide whether to read a page by giving it a quick scan from top to bottom. This kind of scanning takes longer to do with a screen reader. Well-written titles allow screen reader users to identify the general content quickly. From there, they can decide whether to venture further into the page.
First, each <title> within a site should be unique. If we have many pages within one of our sites, they shouldn't all have the same title. Without a way to tell one page apart from another, a screen reader user will have to go further into the page to know its contents, which is time-consuming.
Relatedly, <title> should be front-loaded, putting the most relevant and unique identifying information first. That way, a screen reader user only needs to spend as long as necessary to find out what's on that page.
<!-- Back-Loaded Version (Avoid This) -->
<title>Dunder Mifflin Paper Company | Contact Us</title>
<!-- Front-Loaded Version (Do This) -->
<title>Contact Us | Dunder Mifflin Paper Company </title>
This practice also helps sighted users distinguish one page from the other if they have many tabs from your site open at once.
While we strive to make each <title> unique and descriptive, we should also keep them brief. A good rule of thumb is to keep the length of a title under 60 characters.
<!--Longer Version - 124 Characters (Avoid This) -->
<title>Michael Scott's Dunder Mifflin Scranton Meredith Palmer Memorial Celebrity Rabies Awareness Pro-Am Fun Run Race For the Cure</title>
<!--Shorter Version -- 51 Characters (Do This) -->
<title>Charity Race for the Cure | Dunder Mifflin</title>
Provide a Meaningful Hierarchy with Headings
A screen reader user listens to our descriptive page title and decides they want to explore it in more detail. Their next step might be to skim the page for a high-level view of what's there. They can do this by jumping between any heading tags (<h1> through <h6>) we've included on our page.
Headings organize our page, giving screen reader users another way to orient themselves to its contents. A screen reader user might start by reading all the level 1 (<h1>) headings in the document. They could then choose to drill down further into a section and read through all the level 2 (<h2>) headings there, then all the level 3 (<h3>) headings, and so on.
<body>
<h1>Heading Level 1</h1> <!-- Reading Order: 1 -->
<h2>Heading Level 2</h2> <!-- Reading Order: 2 -->
<h3>Heading Level 3</h3> <!-- Skipped -->
<h2>Heading Level 2</h2> <!-- Reading Order: 3 -->
<h3>Heading Level 3</h3> <!-- Reading Order: 4 -->
<h3>Heading Level 3</h3> <!-- Reading Order: 5 -->
<h3>Heading Level 3</h3> <!-- Reading Order: 6 -->
</body>
We can assist with this workflow by having headings in the first place. Without them, we're handing our screen reader users a wall of text they'll have to listen to line-by-line to find what they need.
Beyond having headings, we should ensure they work together to create a meaningful hierarchy.
To do this, it's a good practice only to have one <h1> element in the document, which serves as the title for our page. That <h1> could even be the same as the <title> element in the head. Then, our <h2> elements can serve as our top-level section headings. If we need to get more granular within each section, we can use <h3> through <h6> as needed.
When laying out our hierarchy, we mustn't skip headings. <h1> should only be followed by <h2>, which should only be followed by <h3>, etc. Skipping headings (say, by moving from <h1> into an <h3>) could confuse screen reader users, who might wonder if they accidentally skipped a heading.
For the heading text itself, the same rule of thumb we can apply to page titles also applies here -- keep it unique, brief, and descriptive.
<h1>Michael Scott Autobiography</h1>
<!--Don't Do This: -->
<h2>Part 1</h2> <!-- Not unique or descriptive -->
<!--Instead, Do This: -->
<h2>My Childhood</h2> <!-- Describes topic for section -->
<!--Don't Do This: -->
<h2>My philosophy is, basically this. And this is something that I live by. And I always have. And I always will. Don’t, ever, for any reason, do anything, to anyone, for any reason, ever, no matter what, no matter where, or who you are with, or, or where you are going, or, or where you’ve been. Ever. For any reason. Whatsoever.</h2> <!-- Not brief -->
<!--Do This: -->
<h2>My Philosophy</h2> <!-- Brief summary of section topic -->
<!--Move the rest to the actual text content of the section. -->
<p>My philosophy is, basically this. And this is something that I live by. And I always have. And I always will. Don’t, ever, for any reason, do anything, to anyone, for any reason, ever, no matter what, no matter where, or who you are with, or, or where you are going, or, or where you’ve been. Ever. For any reason. Whatsoever.</p>
A common issue I've seen with heading tags is using them for styling purposes, like font sizing. Perhaps <h2> feels too big, and the size of <h3> fits better for our aesthetic. Perhaps the boldness of an <h1> heading is what we're looking for to bring attention to a quote or essential information. In either case, the answer isn't to use a different heading level. This will otherwise lead to a disjointed reading experience for our screen reader users. Instead, we should change the styling within our CSS and stick to using heading tags for page organization.
<body>
<h1>Michael Scott Autobiography</h1> <!-- Reading Order: 1 -->
<h2>My Childhood</h2> <!-- Skipped -->
<p>When I discovered YouTube,
I didn’t work for five days.</p> <!-- Skipped -->
<h2>My Career</h2> <!-- Skipped -->
<p>I am Beyoncé, always.</p> <!-- Skipped -->
<h2>My Philosophy</h2> <!-- Skipped -->
<h1>"You miss 100% of the shots you don't take. -Wayne Gretsky" -Michael Scott</h1> <!-- Reading Order: 2 -->
<p>My philosophy is, basically this. And this is something that I live by. And I always have. And I always will. Don’t, ever, for any reason, do anything, to anyone, for any reason, ever, no matter what, no matter where, or who you are with, or, or where you are going, or, or where you’ve been. Ever. For any reason. Whatsoever.</p> <!-- Reading Order: 3 -->
</body>
Give Context with Link Text
Screen reader users can also get a sense of a page's content using the "list all links" shortcut built into their software. This allows them to skip around the different hyperlinks embedded into the page, which we've coded using <a> tags.
This shortcut is only as powerful as the text we provide within the <a>, as that is what the screen reader announces. The most common pitfall here is using vague text for links, such as "click here," "here," "read more, "more," or "link."
<h1>Sales Team Directory - Dunder Mifflin Scranton</h1>
<ul>
<li>Dwight Schrute | Email: <a href="mailto:dwightschrute@dundermifflin.com">Click Here</a></li>
<li>Jim Halpert | Email: <a href="mailto:jimhalpert@dundermifflin.com">Click Here</a></li>
<li>Andy Bernard | Email: <a href="mailto:andybernard@dundermifflin.com">Click Here</a></li>
<li>Stanley Hudson | Email: <a href="mailto:stanleyhudson@dundermifflin.com">Click Here</a></li>
<li>Phyllis Vance | Email: <a href="mailto:phyllisvance@dundermifflin.com">Click Here</a></li>
</ul>
The same standard we've followed for the text within our <title> and heading elements applies to <a> elements: keep them meaningful but brief. Users should understand where the link will take them without the context of the surrounding text. Here is how the same directory could be more screen reader-friendly.
<h1>Sales Team Directory - Dunder Mifflin Scranton</h1>
<ul>
<li>Dwight Schrute | <a href="mailto:dwightschrute@dundermifflin.com">Email Dwight</a></li>
<li>Jim Halpert | <a href="mailto:jimhalpert@dundermifflin.com">Email Jim</a></li>
<li>Andy Bernard | <a href="mailto:andybernard@dundermifflin.com">Email Andy</a></li>
<li>Stanley Hudson | <a href="mailto:stanleyhudson@dundermifflin.com">Email Stanley</a></li>
<li>Phyllis Vance | <a href="mailto:phyllisvance@dundermifflin.com">Email Phyllis</a></li>
</ul>
If we find ourselves saying, "for XYZ, click here," chances are good we could revise that down to "XYZ" for our link text.
One practice to avoid is using the URL itself as the link text. Unless the link is very basic (e.g., wikipedia.org), a URL is neither brief nor meaningful when read by a screen reader. Instead, it will read like a jumble of characters.
Another practice to avoid is making a link out of an entire paragraph (say, if we wanted to reference a website we pulled a quote from). The screen reader will read that whole passage as part of the link list.
Further Reading
The steps outlined above are not exhaustive -- implementing them all does not automatically make our page accessible. However, they are a good start.
For additional information, check out the MDN docs for each element discussed above. Each has a section about accessibility.
Top comments (0)