My Top 10 Accessibility Wish List for iOS 8

As I write this, we’re around 10 days away from the big reveal of iOS 8, which will occur at the keynote that kicks off apple’s Worldwide Developer’s conference. I have everything crossed that Apple will stream the event, due to take place on 2 June at 10 AM Pacific, 1 PM Eastern, 6 PM in the UK, and bright and early at 5 AM on 3 June in New Zealand.
Typically, once the feature set is announced at WWDC, a first beta is released to anyone who is a member of Apple’s iOS Developer Program. That means if you’re willing to pay, you’re able to play. I produced an audio tutorial on how to beta test iOS. If you are interested in trying iOS 8, I recommend picking that up and taking a listen.
Last year, I posted my top 10 accessibility wish list for iOS 7 prior to its release to beta. A few of my wishes even came true! I thought I’d produce an iOS 8 version, open it up for discussion, and find out what you’d like to see in the new release.
1. Improved braille back translation. This was top of my list for iOS 7, and it remains top of my list for iOS 8, with unsatisfactory efforts to address the issues last year. The iPad is revolutionising the classroom, but as an assistive technology consultant, I cannot recommend the iPad as a viable tool for a student learning contracted braille at the moment. Adults can work around the quirks, but we shouldn’t be teaching kids bad braille habits. The iOS back translation, the process by which contracted braille is converted to standard text, is unorthodox and clunky. Let’s walk through an example to illustrate the problem.
Braille the word “Aple” into an edit field using a refreshable braille display connected to your iDevice. Clearly, we meant to write “Apple”, but we accidentally omitted a P. To correct this, route the cursor so you’re in the correct place to insert the second P. Braille the P with contracted braille enabled. Just by inserting that second P, iOS has come back with the word “appeoplele”. What happened? What happened is that the second letter P was fully back translated to the contracted Braille single letter abbreviation for “people”. There are ways around this. You can insert a letter sign before you insert the letter, or you can prefix the inserted letter with the computer braille symbol. You could toggle contracted braille off. You could disable iOS 7’s automatic Braille translation mode and not see anything you’re Brailling until you empty its buffer. None of these steps are necessary in any other company’s contracted braille support. They’re counterintuitive and simply not correct in terms of braille conventions.
Apple has always prided itself on things being super-intuitive. It all just works. For the most part, they deliver on that promise. Braille support is presently not worthy of the Apple name.
2. Notifications alert toggle. I am still genuinely grateful on a regular basis for the fact that we now have access to so many books at the same time they’re released to sighted people. Reading via the Kindle and iBooks app is fantastic. There’s a “but” coming though. It makes for a distracting, disjointed experience to be reading a book, only to be interrupted on a regular basis with notifications. When a notification comes in, VoiceOver stops what it’s reading, speaks at least part of the notification, and then if you’re lucky, resumes reading.
I’d like a setting, available on the rotor and in VoiceOver settings, to be able to specify whether notifications interrupt what’s being read. This would be particularly useful to those of us who make extensive use of custom tones. All the important people in my life have unique ring tones and text alerts. I have a special sound assigned to VIP email. So all this means that when a notification comes in that I know I may want to look at right away, the tone will tell me I should stop reading my book and check my notification. When I hear other alert sounds, I know that they can keep until I want to take a break from my book. It sure would beat being interrupted all the time.
3. Local Dictation. Currently, when you dictate to your iPhone, the voice clip is sent up to a server, and the text is sent back. If you have dodgy cellular coverage or are just dealing with some congestion, this all takes time. Mavericks introduced the option to store voice recognition files locally so there’s no need for server-side processing, and it’s super snappy. It will take some space, but on an iPhone with larger capacity, it’s not a deal breaker, and it would be optional.
I would think the 5S and latest iPad are the only currently available devices on which they’d probably want to offer this feature, due to the amount of processor power involved.
And who knows, maybe Apple might get really ambitious and allow a bit of voice training for really accurate recognition.
4. A keyboard API. I get Apple’s sandbox approach. I really do. There’s an awful lot of malware around on other platforms. But Apple needs to be careful not to make consumers feel deprived of choice and extensibility, and in the highly competitive mobile space, I’m not convinced they have the balance quite right. One way to address this is through use of application programming interfaces, and a keyboard API is high on the list for me. There are many ways we can now get text into a device running iOS, one of the many things that have improved since VoiceOver was introduced in 2009. We can connect Bluetooth keyboards and refreshable braille displays, and touch typing has been added as an option in the virtual keyboard. We’ve also seen a number of apps offering alternative methods of text input. The most popular of these are Fleksy and mBraille.
Fleksy has done some innovative stuff with their SDK, but really, we should have the right to choose our keyboard, built into the OS.
5. Safari accessibility. Browsing the web from anywhere is a cool concept, but it is far too frustrating far too often, because of odd focus issues that persist with Safari. Let me balance that criticism by saying that on pages where it’s available, Reader Mode rocks!
6. Braille Keyboard Manager. I know Apple doesn’t like to have too many options in iOS, but the way we read Braille varies a lot. When using my braille display with my iDevices, I know I’d be a lot more efficient if I could reverse what the thumb keys do. My braille reading style suits having the left panning button advance the display, and the right one reverse. This is the opposite of how Apple have chosen to implement things, and there’s no way of changing it unless you jailbreak. If it’s deemed appropriate to offer brightness and wallpaper settings, then giving us more flexibility over the functions each control performs on a braille display is a reasonable request.
7. More choice of voice. You can get a range of other voices on your iDevice, but they are tied to a specific app. Voice Dream Reader, which has become one of my favourite iOS apps, has an excellent range of voices available. In some cases, those voices may be on your device two, three or more times, taking up valuable space. For example, The Read2Go app uses Ryan and heather, and Voice Dream Reader can use it too, so you may end up with two, three or more copies of the same voice. If you have an 8 or 16GB iPhone, that’s a big deal.
But equally important, these voices should be available to VoiceOver as a whole, giving us much more choice over how our device sounds. Text to speech is a personal and subjective thing. The clearest, most wonderful voice to some is unintelligible or annoying to others, so choice is the best option.
My hearing impairment has an influence over the voices I like to work with, and I’d absolutely love for the Neospeech James voice I use in Voice Dream to be available to the whole phone.
It will be interesting to see if the new Siri voices will be selectable from VoiceOver, or whether their responsiveness isn’t up to it. I understand you can make them available now to VoiceOver if you jailbreak, so if anyone has any experience of how responsive they are under VO, please do share.
iOS 7 made it possible for apps to hook into the built in text-to-speech. That’s an excellent development. Now let’s go one step further by allowing voices to be installed that hook into that API.
8. Liberate Siri! Unless you jailbreak, it’s difficult to get Siri to do anything other than what Apple wants it to do. Facing stiff competition from Google Now, a Siri API would make all the difference, allowing your favourite apps to do cool things with Siri. Imagine if you could ask Siri to search for a book in one of the repositories supported by Voice Dream Reader, perform a voice search through BlindSquare especially for those of us who live in countries where Siri can’t look for businesses, and so much more.
9. More Touch ID coolness. Touch ID is presently available only in the 5s, but newer models of iPhone and iPad are almost certain to include it too. Making greater use of Touch ID is not only beneficial to those of us who use the virtual keyboard with VoiceOver, but it’s also good for those with dexterity issues.
10. Pronunciation Dictionary. This is such a fundamental screen reading feature that I really don’t know why it isn’t there already.
I’ve no doubt Apple will have some cool surprises in iOS 8, for all users and specifically for those of us who use VoiceOver. I will, of course, be covering them in-depth in “iOS 8 Without the Eye”, which you’ll be able to pre-order soon.
In the meantime though, with no one yet under NDA, we can speculate and dream. What would you like to see in iOS 8? I’d enjoy reading your own wishes in the comments.