Suzanne AitchisonThe results from the latest WebAIM Screen Reader User Survey have recently been published, and I thought I'd share what I think are the five key takeaways for developers.
1. Add Screen Reader Audio Output to Your Definition of "Done"
71% of respondents reported they relied exclusively on screen reader audio for engaging with web content, with 76% reporting using a screen reader due to blindness.
With screen reader audio being so essential, it makes me curious to know how often most developers switch on their screen readers. In my experience, I have found many very skilled and senior developers almost never turn their screen reader on to check their work.
Make screen reading part of your routine
One quick resolution to help take a more accessibility-centered approach to development would be to ensure that as developers, we are including screen reader audio output as part of our definition of "done". Before you push that ticket across the board, take a quick pass of your work with the screen reader on.
If you're not sure where to even begin with your screen reader, you can find some guidance over at Getting Started With Keyboard Navigation and Screen Readers
2. Verify Your Work with a Common Browser/Screen Reader Combination
The latest survey results show a slight change in usage statistics across screen readers, with NVDA now squeaking in just ahead of JAWS. In terms of browser/screen reader combinations, the most popular were:
- JAWS with Chrome (21.4%)
- NVDA with Firefox (19.6%)
- NVDA with Chrome (18%)
- JAWS with IE (11.5%)
- VoiceOver with Safari (9.1%)
The good news for development teams large and small is that NVDA is free to download and use! NVDA is available for Windows, so if your development machine is running Windows you should definitely make sure you have it installed.
For Mac users, you have VoiceOver and Safari available straight out of the box.
3. Heading Levels Are Key
The survey posed the question:
When trying to find information on a lengthy web page, which of the following are you most likely to do first?
A huge 68.8% of responses said "Navigate through the heading levels on the page".
This means that appropriate use of heading levels is absolutely essential to engaging screen reader users. If a user can't find the relevant heading, or if your headings are poorly organised, it is likely you are going to fail at engaging them.
Need a refresher on how to use heading levels?
Check out the W3 tutorial on Headings
If you work in a component-based system like React, you should also take steps to make sure your components can respond flexibly to heading level requirements - check out my previous post on this:
4. Don't Surface Essential Content Only in PDFs
The vast majority of respondents (75%) indicated that a PDF document poses significant accessibility issues to them. This doesn't mean that we can't offer users the option to download key information in PDF format, but it does mean that we should always ensure that PDFs are not the sole way to find and consume that content.
Think about whether information like your privacy policy, terms and conditions and so is currently available other than PDF format. If it isn't, then it should be.
5. We Have Plenty of Work To Do
Compared to the last survey in 2017, there was a slightly less positive perception about the state of web accessibility, with only 40% of respondents believing web content has become more accessible (42% believed it has stayed the same, and 18% that it is less accessible now). Respondents without disabilities had a more favourable view than those with disabilities.
When I think about all the advances that have been made in web development in the last two years, I can't help but think that if we applied the same enthusiasm to accessibility that we do to new JS frameworks etc, then we could easily see a more positive response to this question in 2021 🙂
You can check out the full survey results over at WebAIM - Screen Reader User Survey 8
Did you find this post useful? Please consider buying me a coffee so I can keep making content 🙂
