Finding the Way: screen reader strategies
As a sighted person working to improve accessibility on the web, I take lots of inspiration from the many people promoting the idea that empathy is a key element of accessibility. It is always important to bear in mind that a site that is 100 percent WCAG compliant and throws no errors in an automated auditing tool can still be very inaccessible. Sometimes the thing that makes a website difficult to understand for a screen reader user is the absence of information, and that is a problem that is not identified in automated code scans.
No website is perfect, even for sighted users. That perfection will never be reached, in part because we each have a different idea about what would be perfect. That being the case, I cannot expect a perfect screen reader experience, but I try to create a better screen reader experience when I can. Since I only use a screen reader for testing, it’s often difficult to assess what a full time screen reader user is expecting, is accustomed to, or finds annoying. Where is the trade-off between clarity and excess verbosity or redundancy? I can only imagine.
What would a screen reader user do?
When I’m trying to decide which things are most important to work on improving, I often refer back to the WebAIM screen reader surveys, which I wrote about earlier this year. One question I go back to over and again is the question on finding information. The survey asks this question: “When trying to find information on a lengthy web page, which of the following are you most likely to do first?” I added emphasis to the word first, because this question allowed users to explain just one strategy, not all strategies they use. According to the most recent survey, the top methods that are used first are:
- Navigate through the headings on the page (68%)
- Use the “Find” feature (14%)
- Navigate through the links of the page (7%)
- Navigate through the landmarks and regions of the page (4%)
In addition, 7 percent of respondents reported that they simply read through the page, but it was also noted that this varied with screen reader proficiency. More proficient screen reader users are more likely to use headings first (73%) than those who self-identified as beginners (42%). Less proficient screen reader users are more likely to read through the page.
Correct use and presentation of headers, search, links, and landmarks are the keys to having a website that not only passes muster with an automated testing tool, but also makes sense to actual users of all kinds.
Navigating Through Headings
Headings are important way finders for many screen reader users on a new or complex page, and using them correctly is a vital part of making a site accessible. A page without headers, or without a clear hierarchy of headings, leaves screen reader users without a roadmap to find the information on the page.
Use a single <h1>
If you are from a town where all of the children are above average, then perhaps it makes sense to you when all headings on a page are h1. For many users, however, this is a page structure that is not helpful. Screen reader survey #7 reported that “Preference for a single <h1> that presents the document title has significantly increased from 37.1% in 2010 to 60% in 2017”. The <h1> heading typically belongs at the beginning of the main content area. It’s not specifically a standards violation or a specification nonconformance to have more than one <h1> (in fact, some W3C example pages have two) but in general, each page on a site should have one main point.
Build a hierarchy
Headers should provide readers with an outline of the contents of a page. Using headers correctly means avoiding skipping levels, and not selecting levels in order to achieve the desired styling. If you consistently need to skip levels to get the styles you want, consider revising your stylesheet. In a question last posed in Screen reader survey #4, most screen reader users found structured headings to be very useful (48%) or somewhat useful (35%).
A little ARIA can help
Where page structure is implied by layout to visual users of a page, accessibility can be improved by adding headers that are only seen by screen readers. For example, a search results page might not have a visible header at the top of the results listing, but adding a header for the results area that is only visible to screen readers may be helpful. If the results page has other features above the actual listing, this header can make it easier for users of assistive technologies to easily skip to the results. It is possible to go too far, however, as described by comments in this post on the WebAIM site about overuse of ARIA.
Using the “Find” Feature
Search forms are nearly ubiquitous on websites today. Since search is everywhere, we have an expectation to see certain patterns in placement, layout, and behavior.
Placement
The search feature is usually located in either the navigation, the footer, or in a sidebar. If you don’t know where it is, how do you find the find feature? Placing an ARIA landmark makes that really easy. Most sites have few landmarks, so if a screen reader chooses to scan ARIA landmarks to find major sections of a page, search will be part of that short list. More on landmarks later!
Layout
There are not a lot of parts to a search feature, so layout is not too complex. However, it is important to provide both an input field and a button. By convention, the button goes to the right of the input, and this is important. Since search is essentially a form, all of the things that make a form accessible apply here, i.e., use the correct HTML markup for the form controls, provide appropriate labels (not just placeholders), etc.
Behavior
Departing from convention can make your site experience distinctive, but not always in a good way. If you design a unique experience, be sure that accessibility is not the last thing you think of. For example, consider how non-sighted users will know when the results are loaded. If submitting the search text results in a page reload, this is not a problem. If the results are loaded dynamically silence is not golden, it is confusing.
Navigating Through Links
Writing good link text is sort of like writing good alt text. It takes a little extra thought at first, but once you get in the habit it gets a lot easier. Navigating a list of links was the third most popular first strategy, so it’s another good place to focus your efforts to make your site more accessible. It may not make sense to go back through time to update every link in every blog post, but improving link text moving forward will pay off. Volumes have been written about how to make links more accessible, and here are a few easy wins:
Text links
If all (or many) of the links on your page say “click here,” or “here” etc, then screen reader users will learn nothing by scanning the links on your page. If you are are reading this I am probably preaching to the choir, but I see this often. It’s difficult to break a habit but it can be done. You can usually fix this quickly by rearranging the sentence so that the text link makes sense out of context.
“More” links
These are ubiquitous, and they can easily be modified to make sense out of context. ARIA methods can be used to add information that will be read by screen readers, but better text can go a long way, too. Again, so much has been written about this topic, but in their article “Learn More Links - You Can Do Better,” the Nielsen group presents some great creative examples of better link text.
Image links
There are many ways to code image links, but one quick improvement requires no knowledge of code - don’t duplicate text. If you have text associated with the link, don’t add the same text to the alt attribute, title attribute, and caption field. If the image is wrapped in a link that contains text, and is not providing additional useful information, consider using a null alt attribute (alt=” “).
Navigating Through Landmarks and Regions
While only 4 percent of users chose navigating through landmarks as their first step on a complex page, in a separate survey question about landmarks, 30 percent noted that they always or often use landmarks when they are present. That’s only about a third of the time, but consider this - if most cars only started 20 percent of the time, most car owners would make a habit of heading to the bus stop in the morning instead of checking the garage each morning to see if the car starts today. But if they do try and the car starts, they will probably drive it. If the landmarks usually aren’t there, screen reader users might not bother to look for them.
Good ARIA can be hard to find
ARIA landmarks can be a sticky topic. The W3C ARIA Authoring Practices documentation includes a “Read Me First” section that opens with a warning that no ARIA is better than bad ARIA. There are oodles of articles explaining the consequences of improper ARIA for users of assistive technologies, and even when applied in a technically proper way ARIA should not be overused. Furthermore, screen readers and other assistive technologies are incomplete and inconsistent in their handling of ARIA. This may offer insight on the fact many sites on the web make little or no use of ARIA.
Basic landmarks for regions
With all of the warnings in mind, having a few key landmarks on a page makes it easier for users of assistive technologies to move around. The good news is that simply using good semantic HTML largely eliminates the need to explicitly add landmarks using ARIA roles. In fact, HTML5 validators will post an error if you do this.
- HTML5 elements <header>, <nav>, <main>, and <aside> will be announced with the ARIA roles of “banner,” “navigation,” “main,” and “complementary.”
- The <footer> element is announced as “contentinfo” in most browsers, but Safari does not recognize it so the role should be added to expose the page footer to VoiceOver users.
- There is no HTML element equivalent to the search landmark, so role=”search” should be added to the <form> element that wraps your search field.
That’s it! The WAI-ARIA Authoring Practices document mentioned above is accompanied by a series of pages with ARIA Landmarks Examples. On each page, you can click a button to show the landmarks on the page. Another button will reveal the headings. The examples are all pretty great, too!
Finding the Search Feature
In the absence of a landmark, the search field can be found by looking for form controls. However, if there are lots of controls on the page and the search feature is in a sidebar, footer, or somewhere else other than the top of the DOM order, it may take some digging to get there. Even if it is in the top navigation area, on a site with secondary and utility navigation areas the search feature can be difficult to expose with assistive technology.
I did a quick and unscientific survey of sites to see how widespread the practice of placing an ARIA landmark on the search area is. Here is is a summary of how often I found a landmark:
- Sites that are focused on accessibility: 6 out 8
- Top retail sites in terms of traffic: 4 out of 8
- High traffic non-retail websites: 3 out of 4
Based on this review of 20 sites, the fact that screen reader users don’t often rely on using landmarks is not surprising since the use of landmarks was inconsistent. It was also fascinating to see all of the various ways that search is presented on different sites.
In closing, the modern web offers lots of opportunities for designers and developers to provide unique and visually compelling visitor experiences. That can be lots of fun, but It’s important make sure that creating these experiences for some users don’t make things more difficult for others.
