On the usability of touch screens to screen readers

Recently, Katie Sherwin of the Nielsen Norman Group published an article on the NNG website summarizing her experience with the VoiceOver screen reader for iOS devices, and her suggestions for designing better interactions for blind users. The article has some good design suggestions overall: creating cleaner copy with streamlined code is always a good thing. So is including alternative text for images, making sure all interactions work with the keyboard, and the hierarchy of the content is clearly  indicated by headings that separate it into logical sections. On these suggestions, I am in full agreement with the author.

Where I disagree with her is on the representation of what the experience of using a mobile device is really like for actual blind users. The author herself acknowledges that she only started experimenting with the screen reader after attending a conference and seeing how blind users interacted with their devices there. It is not clear how much time she has had to move beyond the most basic interactions with VoiceOver. Thus she states that “screen readers also present information in strict sequential order: users must patiently listen to the description of the page until they come across something that is interesting to them; ; they cannot directly select the most promising element without first attending to the elements that precede it. ”

This may be accurate if we are talking about someone who has just started using VoiceOver on an iPhone or iPad. It ignores  the existence of the Rotor gesture familiar to many power users of VoiceOver. With this gesture, users actually can scan the structure of a web page for the content they want to focus on. They can see how the page  is organized with headings and other structural elements such as lists, form elements and more.  Many users of VoiceOver also use the Item Chooser (a triple-tap with two fingers) to get an alphabetical list of the items on the screen. Both of these features, the Rotor and the Item Chooser, allow users to scan for content, rather than remaining limited to the sequential kind of interaction described in the NNG article.

As for the point about the cognitive load of the gestures used on a touch screen device like the iPhone, it should be pointed out that the number of gestures is actually quite small compared with the extensive list of keyboard shortcuts needed on other platforms. I do agree with the author that typing remains a challenge when using the onscreen keyboard, but there are other options available to make text entry easier: the user can choose to use any of the many Bluetooth keyboards available on the market for a more tactile experience; dictation is built in and has a pretty good level of accuracy for those who prefer using their voice; and new input modes introduced in iOS 8 and 9 allow for handwriting recognition as well as Braille input.

To help new users with the learning curve (and the cognitive load), Apple provides a built-in help feature that is only available in the VoiceOver settings when the feature is active. Once a user goes into the help, he or she can perform gestures to hear a description of what they do. Another benefit for users is the fact that many of the gestures are the same across the Apple ecosystem. Thus, a VoiceOver user can transfer much of what they have learned on an iOS device to the Mac, which has a trackpad roughly the size of an iPhone, the new Apple TV with its touchpad remote, and even the Apple Watch (with a few modifications to account for the limited screen real estate). Finally, I have found that learning the gestures is as much a  matter of muscle memory as it is about remembering the gestures and what they do. The more time you spend performing the gestures, the easier they become. As with any learned skill, practice makes a difference.

Again, there is a lot of good advice in this article as it relates to the need for more inclusive designs that minimize unnecessary cognitive load for users. However, a key point that is missing from that advice is the need to get feedback on designs from actual people who are blind. The way a blind user of VoiceOver interacts with his or her iOS device will often be a lot different from the way a developer just becoming familiar with the feature will do so (same goes for a usability expert).

IOS 6 Accessibility Features Overview

At today’s World Wide Developer’s Conference (WWDC) Apple announced IOS 6 with a number of accessibility enhancements. I am not a developer (yet!) so I don’t have a copy of the OS to check out,  so this post is primarily about what I read on the Apple website and on social media. A few of these features (word highlighting for speak selection, dictionary enhancements, custom alerts)  were tucked away in a single slide Scott Forstall showed, with little additional information on the Apple website. So far, these are the big features announced today:

  • Guided Access: for children with autism, this feature will make it easier to stay on task. Guided Access enables a single app mode where the home button can be disabled, so an app is not closed by mistake. In addition, this feature will make it possible to disable touch in certain areas of an app’s interface (navigation, settings button, etc.). This feature could be used to remove some distractions, and to simplify the interface and make an app easier to learn and use for people with cognitive disabilities. Disabling an area of the interface is pretty easy: draw around it with a finger and it will figure out which controls you mean. I loved how Scott Forstall pointed out the other applications of this technology for museums and other education settings (testing), a great example of how inclusive design is for more than just people with disabilities.
  • VoiceOver integrated with AssistiveTouch: many people have multiple disabilities, and having this integration between two already excellent accessibility features will make it easier for these individuals to work with their computers by providing an option that addresses multiple needs at once. I work with a wounded veteran who is missing most of one hand, has limited use of the other, and is completely blind. I can’t wait to try out these features together with him.
  • VoiceOver integrated with Zoom: people with low vision have had to choose between Zoom and VoiceOver. With IOS 6, we won’t have to make that choice. We will have two features to help us make the most of the vision we have: zoom to magnify and VoiceOver to hear content read aloud and rest our vision.
  • VoiceOver integrated with Maps: The VoiceOver integration with Maps should provide another tool for providing even greater  independence for people who are blind, by making it easier for us to navigate our environment.
  • Siri’s ability to launch apps: this feature makes Siri even more useful for VoiceOver users, who now have two ways to open an app, using touch or with their voice.
  • Custom vibration patterns for alerts: brings the same feature that has been available on the iPhone for phone calls to other alerts. Great for keeping people with hearing disabilities informed of what’s happening on their devices (Twitter and Facebook notifications, etc.).
  • FaceTime over 3G: this will make video chat even more available to people with hearing disabilities.
  • New Made for iPhone hearing aids: Apple will work with hearing aid manufacturers to introduce new hearing aids with high-quality audio and long battery life.
  • Dictionary improvements: for those of us who work with English language learners, IOS 6 will support Spanish, French and German dictionaries. There will also be an option to create a personal dictionary in iCloud to store your own vocabulary words.
  • Word highlights in speak selection: the ability to highlight the words as they are spoken aloud by text to speech benefits many  students with learning disabilities. Speak selection (introduced in IOS 5) now has the same capabilities as many third party apps in IOS 6.

These are the big features that were announced, but there were some small touches that are just as important. One of these is the deep integration of Facebook into IOS. Facebook is one of those apps I love and hate at the same time. I love the amount of social integration it provides for me and other people with disabilities, but I hate how often the interface changes and how difficult it is to figure it out with VoiceOver each time an update takes place. My hope is that Apple’s excellent support for accessibility in built-in apps will extend to the new Facebook integration, providing a more accessible alternative to the Facebook app which will continue to support our social inclusion into mainstream society. You can even use Siri to post a Facebook update.

Aside from the new features I mentioned above, I believe the most important accessibility feature shown today is not a built-in feature or an app, but the entire app ecosystem. It is that app ecosystem that has resulted in apps such as AriadneGPS and Toca Boca, both featured in today’s keynote. The built-in features, while great,  can only go so far in meeting the diverse needs of people with disabilities, so apps are essential to ensure that accessibility is implemented in a way that is flexible and customized as much as possible to each person. My hope is that Apple’s focus on accessibility apps today will encourage even more developers to focus on this market.

Another great accessibility feature that often gets ignored is the ease with which IOS can be updated to take advantage of new features such as Guided Access and the new VoiceOver integration. As Scott Forstall showed on chart during the keynote, only about 7% of Android users have upgraded to version 4.0, compared to 80% for IOS 5. What that means is that almost every IOS user out there is taking advantage of AssistiveTouch and Speak Selection, but only a very small group of Android users are taking advantage of the accessibility features in the latest version of Android.

Big props to Apple for all the work they have done to include accessibility in their products, but more importantly for continuing to show people with disabilities in a positive light. I loved seeing a blind person in the last keynote video for Siri. At this keynote, Apple showed another  blind person “taking on an adventure” by navigating the woods near his house independently. As a person with a visual disability myself, I found that inspiring. I salute the team at Apple for continuing to make people with disabilities more visible to the mainstream tech world, and for continuing to support innovation through inclusive design (both internally and through its developer community).

Accessibility in iBooks 2 and iBooks

Today’s post will focus on some of the lessons I have learned about the accessibility of ebooks created with iBooks Author and accessed on the iPad with iBooks 2.

I was pleasantly surprised to learn that Apple included an option for adding a description for images and other objects when it released iBooks Author. I don’t remember this feature being discussed much at the event where Apple unveiled iBooks 2 and iBooks Author, and only found out about it while test driving the software.

An even better surprise was learning that closed captions are now supported for any video that is embedded in an iBook. This is a great feature that will benefit a range of different learners (not only those with hearing disabilities). I think these new accessibility features of iBooks Author and iBooks 2 will go a long way toward facilitating the adoption of iBooks in the schools by meeting legal requirements for accessibility set by the U.S. government (for a summary of the legal requirements, please see the Dear Colleague letter and the follow-up clarification from the U.S. Department of Education).

Apple has published a support document  with  advice for making iBooks created with iBooks Author more accessible.  However, the article focuses mostly on the accessibility of images and other visual content, and does not include any information about closed captions. I would add a couple of bullet points to the advice given in the Apple support document:

  • the article suggests adding descriptions for all images, including background images. Web accessibility guidelines state that decorative images should have a null or empty alt attribute so that they are skipped by a screen reader, but there is currently no way in iBooks Author  to indicate that an image should be skipped by VoiceOver on the iPad. In my testing, I found that when you leave the description field for an image empty in iBooks Author, VoiceOver will read the entire file name when it comes across the image in iBooks 2. This is a problem because most people don’t use very descriptive file names before they add their images to a document. In my test iBook, I forgot to add a description for one of the placeholder images included in the iBooks Author template I selected. When I accessed the iBook on my iPad, VoiceOver read the following: “1872451980 image”. Imagine how confusing this would be to someone who is blind and relies on the VoiceOver screen reader to access content in iBooks.  For the time being, I would suggest following the guidance from Apple and marking up all images, including those that are used for decorative purposes, but I would recommend marking up  decorative images (those that don’t add any content that is essential for understanding) with the word “Background” in the description. By default, VoiceOver will say the word “image” so it is not necessary to add that to the description. While it would be better for the image to be skipped by VoiceOver if it is not essential, I would rather hear a quick, single-word announcement that is much easier to ignore than a long number read aloud in its entirety by VoiceOver, or an unnecessary description for an image that does not add in any way to my understanding of the content.
  • as much as possible, image descriptions should focus on the function of each image rather than its visual appearance. Writing descriptions (or alternative text as it is more commonly known in the web accessibility world) is as much an art as it is a science, and much of it is subjective. There are many sites that provide information on how to write good alt text for images on websites, but I have found very little guidance on how to write descriptions for other online content such as ebooks. My recommendation would be to focus on three C’s when writing descriptions for images in iBooks Author: Context, Content and Conciseness. First, I would ask myself if the image is properly described in the surrounding text. If it is, then it might be more appropriate to mark it up as a decorative image (“Background”). Next, I would ask myself “what information does this image convey?” and focus on the key idea or concept supported by the image rather than its visual details. There could be a few exceptions where you might need to focus on the visual details of the image, but these cases should be the exception rather than the rule. The final consideration is to keep the description as brief and concise as possible. I would try to keep it to no more than 8-10 words if possible.

The second aspect of accessibility supported in iBooks Author is closed captioning. If a movie added to an iBook in iBooks Author has been captioned, you can view the captions in iBooks 2 on the iPad by going to Settings, Video and making sure Closed Captions is set to On. If you know a file has been captioned and you don’t see the captions on the iPad, you may need to go into the Settings app and turn the captions off and then on for the captions to show up. This appears to be a bug that will likely get fixed in a future update to iBooks or IOS.

To create a captioned file, I have found that a workflow using MovieCaptioner and Compressor has worked well for me. I like MovieCaptioner for creating the captions because it is affordable and easy to learn. To learn more about how to create captions with MovieCaptioner you can view this tutorial I have made available on the Tech Ease website at the University of South Florida.

The only difference with my current workflow is that rather than exporting a captioned QuickTime video file from MovieCaptioner I’m only using the software to create the SCC file that has the caption text and timecodes. I then use Compressor to make sure the video file is in the correct format for the iPad and to add the captions. I found that when I exported the movie from MovieCaptioner I would get an error message in iBooks Author and the software would refuse to import the movie. Once I have exported my SCC file (Export > SCC in MovieCaptioner), I use Compressor to combine the two as follows:

  1. Open Compressor and choose Add File from the toolbar, then locate the desired video on your hard drive.
  2. In the Settings pane (Window > Settings) choose the Destinations tab, then find Desktop (or your preferred destination ) and drag it into the Batch window.Drag Destination from Settings pane to Batch window.
  3. Switch to the Settings tab and choose Apple Devices, H.264 for iPad and iPhone, then drag that setting on top of the destination in the Batch window.
    Drag H.264 for IPad and iPhone setting into the Batch window
  4. With your movie selected, open the Inspector (Window > Inspector or click the Inspector button on the toolbar), select the Additional Information tab and then Choose to find the SCC file on your computer.
    Select Choose from the Additional Information tab in the Inspector
  5. Select Submit to start the export process.

Once your movie has been exported from Compressor you should be able to drag it right into your iBook in iBooks Author to add it as a widget. As with images, make sure you provide a description in the Inspector.

Students with disabilities have traditionally had a difficult time with access to textbooks. iBooks Author provides a platform for making textbooks more accessible for all learners as long as a few accessibility principles are kept in mind. What an exciting time to be working in educational technology and accessibility!