While my job responsibilities don’t formally include accessibility, Safari is awesome and lets me use my ability chops for the products and sites we make. I had not created an accessibility report for a native iOS app before, so testing Safari Queue was a fascinating experience for me. I’m very pleased that Safari is comfortable with me posting the results of my testing, especially since the results reveal that we have some way to go before the app is perfect. In my experience, transparency about accessibility weaknesses has a strong correlation with companies who have a commitment to fixing those weaknesses.
Queue is pretty accessible! There’s definitely room for improvement, but I spent time reading in Safari using my iPhone with the screen blanked. There were some hurdles, but I managed some not insubstantial reading and navigation without being able to see the screen. That being said, we definitely have some stability fixes to put on our list.
Some notes about accessibility testing
When I’m testing websites, I am adamant that people remember that “accessibility” does not mean “works with a screen reader.” But a native iOS app is not a website, and is primarily (not entirely!) accessibility tested using the iOS built-in screen reader VoiceOver. I’m not a screen reader user, although I am an adaptive technology user, and I’m well aware that a tester’s comfort level with a given adaptation is not necessarily an accurate assessment of how usable the site is by a regular user. The app is likely to be much more usable by a regular user of adaptive tech, as they know their tools very well. At the same time, the niggling inconveniences of using an imperfect app are likely to be much more wearying for the user who deals with inaccessible technology all day than they are for the tester. My usage of VoiceOver is primarily accessibility testing (although not entirely — if you get used to VoiceOver, it’s a great tool for reading while exercising, cooking, or walking to work in yet another snowstorm). I’d love to get feedback from regular VoiceOver users to see if our assessment of Queue is accurate. The most important steps to get a good experience testing the VoiceOver are:
- Use VoiceOver with some regularity. As I mentioned above, it can be a very handy tool even for sighted people if your eyes are otherwise occupied.
- Make sure you read at least some guides to testing with VoiceOver by people who are blind/vision impaired. I’m sighted; don’t trust me too much! People who use a given adaptive technology as a necessary experience are your best guides for testing with that tech. Remember that there are blind/VI developers and testers as well as end-users.
- Navigate on the phone without looking at the screen. VoiceOver has a feature called the “screen curtain” which allows you to navigate with the screen turned off. To enable it, tap three times with three fingers on the screen (getting the timing right for the double- and triple-taps takes some practice). You will also need to test the app with the screen curtain off, in order to see if there were any controls or functionality that were invisible to you when you were testing with the curtain on.
Safari Queue’s main browsing interface is the “queue”: the list of works a reader has queued up for future reading using the Safari web app. I’m distinguishing between Queue-the-app and the concept of a queue of books via capitalization of “queue,” and I realize the distressing irony that my distinction is largely invisible to anyone reading this blog post with a screen reader. Where it’s not clear from context I will distinguish in other ways. When a user enters the app, they’re presented with their queue of books open and a book scrolled over to the right. The experience can be confusing if the user cannot see the page. When testing, I initially tried navigating with the screen curtain on, but eventually disabled it for my exploratory navigation. I’d be curious if any regular VoiceOver users can figure out how to control the book/queue screen, or if they need assistance for the first time through the app. Once I navigated the queue with the screen curtain off, I could do it with the screen blanked out afterwards, so I’m guessing that even if VoiceOver users need assistance, they might only need it once. Eventually, through trial and error, a user touching all parts of the screen may realize they are hitting some text from the book. Once they have managed to focus on the text in the right-hand margin, the user can manipulate all of the usual controls to navigate up and down through the book. Unfortunately, the rest of the buttons/controls are in unusual places in this mode. Additionally, there is no audible notification that the user is moving between the queue and the book. I’m not sure what the ideal way would be to translate this visual interface to the screen reader user experience. The flag button in the top left of the open book interface reports aloud as “flag flag”. A sighted user can determine what the button’s function is from playing with it and seeing that it opens and closes the queue of books, but the state of the book queue is not made available to the screen reader user. It needs better alternative text. Possibly there’s another icon which would be more meaningful to the sighted user as well, which would make its purpose more obvious.
The row of buttons at the bottom of the screen — table of contents, night mode, front resizer, and share — vanishes when the user is scrolling down through the book and reappears when the user scrolls back up. In visual iOS UI, this is becoming a common human interface standard. However, in VoiceOver, there is no spoken indicator that the button bar has vanished or reappeared. (For the VoiceOver tester: scrolling down is a finger swipe up, and scrolling up is a three finger swipe down.) On the iOS Safari browser — Apple’s web browser, not our Safari Queue! — with VoiceOver off, scrolling down makes the button bar vanish, but with VoiceOver on, scrolling down has no effect on the button bar. However, when VoiceOver is running, the behavior changes: the button bar never vanishes, so it is always available to the VoiceOver user. This is a feature we should definitely add to Safari Queue!
Table of Contents
The visual table of contents is a pageable screen of table of contents items, with a close button at the bottom. Navigating in VoiceOver, going down item by item through the TOC (one finger flick down), the item after the last item on the visible page of table of contents items is not the next item in the pageable TOC, but the “close” button, followed by the end of the list. There is no audible indication that a scroll on the page (three finger flick up) will offer more table of contents items. Reading upwards through a secondary page of the TOC (one finger flick up), and arriving at the top of the visible portal, produces the the VoiceOver “no more items” tone, with no obvious indication that further TOC items are available on a previous page. Another accessibility issue in the table of contents is a general usability issue and not a screen reader-specific accessibility problem. One iOS human interface standard is the idea that a tap at the top of the visual portal will scroll to the top of the page. However, if a user is in the TOC in Safari Queue and taps the top of the screen, that selects the TOC item. This is an example of an iOS accessibility issue which is not screen reader-specific; the ability to jump to the top of the page is an accessibility issue for mobility-impaired users. And, of course, following common UI standards is an usability win for all.
There are some problems with controlling the video player while VoiceOver is running. Once the controls fade visually, they seem to be unavailable to VoiceOver. Before the controls fade, some controls (pause/play, and full/exit) are available, but others (timestamp scrubber) are not. Safari does have videos with transcriptions available, but I could not find access to closed captions or transcripts from within the app. This is another one of those non-screen reader specific accessibility issues. Access to transcripts or captions is important for people with a wide range of disabilities — and is another general usability improvement. Safari as a whole is constantly improving the way it makes transcripts accessible, but there are certainly improvements we can make. For example, you can’t currently search only for videos with transcripts and captions. Moreover, the video player in our web application isn’t controllable by screen reader or keyboard, which means there’s no way to enable the captions without a mouse. And of course, we only have captions and transcripts where they’ve been provided to us by video creators; some truly wonderful conference talks (including some about accessibility) are not currently captioned. But I’m confident that the continued improvements we’ve made on captions and transcripts thus far are indication of constant forward momentum.
We don’t create our book content, which means we’re constrained by the accessibility problems inherent to the works we host. Alternative descriptions for images are an across-the-board problem in digital publishing. The technology exists to do it very well, but the workflow in publishing houses is only there in a very few cases. It’s not an easy problem for publishers to fix, either. Think how hard it is for you to learn how to do good alternative text, and then multiply that by every single content creator a publishing house has. Publishing houses are very eager to fix the problem, but it’s nontrivial; anything that can’t be automated is tricky. The end result is that most images in books available via any Safari interface don’t have useful alternative text. Instead, they often have the name of the chapter or the ISBN as the alternative text. I wonder what the most useful standard is? My suspicion is that something such as, “Illustration 13 in Chapter ‘Accessibility is Awesome!'” might be the most useful. At least that gives the screen reader user some context to find out more information. In any case, this is obviously not a problem native to the Queue app. However, accessibility issues with the content will plague users on mobile just as much as they plague users in the web application.
I found these sites all very useful while doing iOS accessibility testing.
- iOS Developer Library: Test Accessibility of Your Device with VoiceOver
- Léonie Watson: Testing and debugging iOS accessibility for VoiceOver
- Pat Pound: Tips for accessibility testing of iOS apps
- Rosie Land: iOS accessibility: a useful guide for testing
- Hiring developers, designers, and testers with disabilities is a fantastic way to improve your site or app’s accessibility. If you don’t have any in-house accessibility experts, Knowbility can hook you up with a network of users with disabilities who will test your app or site.