WebAIM’s 2017 Survey: Increased Use of VoiceOver on iPhones
In December 2017, WebAIM, a non-profit organization well known for its research and work on web accessibility solutions, released their findings from a survey of 1,792 screen reader users who responded in October 2017. This survey, in relation to past WebAIM surveys (surveys #1-#7), shows a continued increase in the use of screen readers on mobile devices and, especially, the use of VoiceOver software on Apple phones. Of the people who responded to the survey, 65.4% said that they are either using their mobile phone as their primary or one of their primary devices to use a screen reader (Source). In addition to the increased use of screen readers on a mobile phone, “iOS usage continued its increase [in the screen reader population] from 32.6% in December 2010” to 75.6% in October 2017 (Source 1, Source 2). For the 75.6% of respondents in 2017 who said that their primary mobile or tablet platform was iOS, they are almost certainly using the native Apple VoiceOver software as their screen reader software (Source).
I have seen in-person how common VoiceOver usage on iPhones is for visually impaired users at the Library for the Blind and Physically Handicapped in Pittsburgh, PA. Two years ago, I sat in on a few of the library’s “Accessible Tech Training” sessions where a staff or group member would demonstrate the accessibility features of a certain iOS app, or they would simply go over more about how to use the accessibility features on mobile devices. The entire group I sat with was using VoiceOver on their iPhones.
Since mobile screen readers, and especially Apple’s VoiceOver, are continuing to increase in use, it seems pertinent for developers and other web creators to better understand how the web is being consumed by these users. To that end, I have made a video demonstrating how to use VoiceOver to test websites for accessibility compliance in the hopes that it will help you or your team craft better, more inclusive websites.
Using VoiceOver for Web Accessibility Testing
YouTube embeds track user data for advertising purposes. You can watch the video on YouTube if you prefer not to grant consent for YouTube embeds.
Video Transcript
Hi, my name is Lindsay and I work as a developer for Sparkbox. Since I started working on the web in 2015, I have been dedicated to finding accessible website solutions.
When I work on a website, I always try to do some quality assurance and accessibility testing on my iPhone 6 using VoiceOver. In this brief tutorial, I’ll show you how to use VoiceOver and some of the features that VoiceOver, and many other screen readers, offer, especially with regard to being able to more effectively browse a web page.
At the moment, there is no other substitute I know of that comes close to the findings and solutions that can be discovered by accessibility testing by hand, that is: having a real person testing a live site, with a screen reader, or via keyboard only—on desktop, mobile, etc. There are definitely tools out there that can help you evaluate the accessibility of your website, but these tools only scratch the surface of the issues present, and using those tools alone will not mean that you have created an accessible web browsing experience for people with disabilities.
To get started, I just want to go through some of the gestures I will be using since you aren’t able to see my hands in this video. Using this assistive touch feature, I can show you where and how my fingers are moving. In order to navigate around my phone, I will mostly be swiping left and right. I will also be swiping up and down from time to control certain types of functionality. Lastly, to use the rotor functionality that I will explain to you a bit later, you must use two fingers to create a twisting motion on your screen—this is definitely the hardest gesture to get down. I generally position my pointer finger on the top and thumb on the bottom while twisting in a clockwise motion.
Now that we have that gesture knowledge, we will turn on VoiceOver and begin! To turn on VoiceOver, we’ll go to our Settings -> General -> Accessibility -> VoiceOver. Slide the VoiceOver toggle to turn that functionality on. And there we go! To slow down or speed up VoiceOver you can click on the “Speaking Rate” range, and swipe up or down to increase or decrease speed. Now, as I mentioned, to move around your phone, you will swipe left to right to go down, and right to left to go up, and to select you will double click.
Since I am a sighted user, I can also click around randomly on the heading or app that I want in order to speed things up, but just remember that most users will probably have to swipe through all of the headings, or all of their apps, to get to their desired endpoint.
Let’s open up Safari now, and this Medium article about one of my favorite conferences I have ever been to—ELA conference in Philadelphia: a conference for women, trans men, and genderqueer people in tech.
I can continue using the left and right swipe behavior you have seen to navigate this website.
I can also use something called “The Rotor” that is a piece of functionality VoiceOver enables. The rotor allows screen reader users to more quickly, and more decisively navigate a web page—I can choose to navigate via headings alone, which is the way many WebAIM survey respondents said is the primary way they use to find information on a lengthy web page (Source). I can also navigate via ARIA landmark roles, Links, Visited Links, Containers, Form Controls, and more—and you can custom set your rotor options under Settings -> General -> Accessibility -> VoiceOver -> Rotor. The rotor is a really useful feature for people who wish to skip a lot of the content that may be unnecessary to them on a webpage (whether it be ads, images, or paragraphs) and get straight to the content they are looking for.
To use the rotor, use two fingers and a twisting motion to activate it as I showed you before. You will see or hear the rotor announced and, as you twist your fingers, you will hear about different options you can use and how many times the different attributes appear on the page. For instance, it might say ‘headings: 25 headings’ or ‘form controls: seven form controls,’ meaning there are seven form controls on the page. To just navigate via headings, select that rotor setting and then use a swipe down motion repeatedly to jump between headings.
I also wanted to point out a couple good and bad things this Medium article does for accessibility software. This article does a really good job with their heading structure, making it easy for someone who wanted to quickly browse the article with the rotor heading function to do so (as we saw). It looks like the authors of this article also put in a helpful alternative image text attribute (alt text) for the Ela Conf image at the top: “Go to the profile of the Ela Conf Organizers.” This tells a screen reader user that this is a link and exactly where it is taking us if you click without them ever needing to know that this is also an image. However, for this other image in the article this is what people using screen readers have to hear spelled out: “1*orerqdYHG3-M66m3x9cJ7Q.jpeg.” There was not an alt attribute provided here, and instead, a random long ID that is the image’s name gets read. What might have been better is if they added some alt text that was descriptive of the image: “women laughing at Ela conference,” or just had an empty string of alt text so the screen reader would know to just skip the image and not read anything.
Lastly, for the header of Medium’s website, this is what a screen reader says: “Homepage Link.” I had inspected this Medium website beforehand on my computer and the reason the screen reader is doing this is that this is a link surrounding an SVG of the words “Medium” and someone just added some text in a <span> tag meant for screen readers that says: “Homepage.” This is ok, but I think it might have been a bit easier and better to add something like an aria-label to the link that said, a bit more descriptively: <a href=”#“ aria-label=”Medium Homepage”> rather than “Homepage” alone.
Now you know a lot more about how to use VoiceOver to test your own webpages, and ways that users with disabilities may want to navigate the web. Check out the article that goes along with this video for more information about the WebAIM survey that I mentioned, and accessibility tools you can use for website testing. Thanks so much!
A More Accessible Web Is A Better Web
For the screen reader users who responded to the 2017 WebAIM survey, 85.3% said that “better (more accessible) websites” would have a bigger effect on improvements to web accessibility—not better assistive technology. It is in our court, as developers, designers, and content strategists to make the web a more accessible place (Source).
As I mentioned in the video above, at this moment in time, accessibility testing by hand gives us the best approximation of how our websites will be perceived by people who may need to use assistive technologies. Not only does accessibility testing provide us with better information about how we can improve our websites, but it also fosters empathy and understanding about the experiences of people who use screen readers alone to browse the web each day. Incorporating a little time for accessibility testing and understanding how to use some assistive technologies gets us one step closer to building a better web.
