G3 iMac in a manual wheelchair over an old OS X default desktop image.

Round-up: iOS 8 Accessibility Wishes

MacWorld have been running a series on changes that they’d like to see in iOS 8, so far the list has included changes to The Notification Center, Mail, Calendar and Reminders, and Photos and Camera. Today Steven Aquino has added to the series with: iOS 8 changes we’d like to see: Accessibility.

Steve’s article pretty much sticks to two issues – the impact that the iOS 7 redesign had on accessibility, especially for low-vision users, and the fact that the accessibility settings are hopelessly confused and a huge jumble of things put in no particular order and expecting users to find the specific settings they need is unreasonable with the current setup. I agree with Steve that both these issues are vitally important, but I know there are many other accessibility wishes that lots of users have for iOS 8! This article aims to be a more general round-up of wishes for a wide variety of accessibility needs …

VoiceOver

On Twitter I found VoiceOver users listing their wishes which included adding a pronunciation dictionary, increasing the maximum possible speech rate, allow 3rd-party on-screen keyboards such as the MBraille or Fleksy), change how long notifications are visible on braille displays.

Flesky keyboard
Currently, the Flesky on-screen keyboard only functions in the Flesky app and others that are specifically programmed for it.

Jonathan Mosen has also written a Top 10 Accessibilty Wish List for iOS 8 article as a user of VoiceOver in both audio and braille modes. He especially notes some serious issues with input of contracted braille and notification alerts for audio VoiceOver users.

On-screen Keyboards

Now that more and more input is being done on iOS devices, the issue of on-screen keyboards becomes more urgent.

One suggestion brought up on virtually all the accessibility wish lists I saw was to provide an API so that third-party developers could create specialised keyboards that could be used instead of the standard iPhone/iPad keyboards whenever on-screen text entry is needed. Currently this is something that Android allows but Apple does not.

iPhone on screen keyboard
This QWERTY layout is the only one my iPhone offers.

It’s hard for me to imagine that Apple will allow this – it definitely breaks their “sandboxing” approach so far but it would be an enormous boon to accessibility for many different disability groups.

I’m sure this list is far from exhaustive but groups I have seen mention this desire include:

  • Blind users, wanting keyboards such as MBraille or Fleksy which are optimised for entering text without looking at the screen.
  • Some mouth stick pointer and stylus users who would like keyboards optimised for the smallest amount of movement between key presses, such as Chubon.
  • Users who would like keyboards like the (no longer available) Tiki’Notes 6 Key Keyboard which are optimised for those with fine motor difficulties.
  • Users who have cognitive impairments and memory problems who would like keyboards which are colour-coded and can be arranged in whatever letter order they are most familiar with.
  • Switch users who are accustomed to working in morse code and would like to be able to enter text using morse switches.
  • Users like me who are most familiar with Dvorak or another non-QWERTY keyboard arrangement and would just find it less exhausting to use a layout we are used to.

It seems unlikely that Apple themselves will meet all our conflicting needs, but by allowing third-party keyboards they could allow others to meet all of our needs themselves. Personally, this is definitely my top accessibility wish!

Switch Access

Christopher Hills told me on Twitter that he wants to see app developers given more control over the way Switch Control scans their apps. I would have loved to go into this subject more with him but Christopher was over at the Inclusive Learning Technologies 2014 conference, where I very much wish I could have been!

iOS 7 Switch Control Settings also showing blue switching curser because switch control is turned on.
iOS 7 Switch Control Settings also showing blue switching curser because switch control is turned on.

The switch gaming blog OneSwitch didn’t phrase theirs in terms of iOS 8 but also has some switch access requests:

It’s just not possible to repeatedly, easily and quickly tap/swipe a specific point in far too many apps. If an app is not set-up with decent hot-spots / voice-over items you are forced into a laborious gliding bar auto-scanning X-Y point mode that takes five accurately timed presses of the switch to repeat an action. The gliding bar point mode is well done for basic use, but it’s useless for too many activities..

Text to Speech

Text to speech voices such as those used by VoiceOver and many accessibility apps are another avenue where a third-party API would be a huge accessibility boon.

VoiceOver currently can’t use third-party voices at all, only those which come with the system.

Apps such as Proloquo2Go and Read2Go can make use of the iDevice system voices or install their own voices, but installed voices can’t be shared between apps. This results in many users ending up with multiple copies of the same installed voices, because each app needs a separate copy.

TouchID

More uses for Touch ID for iPhone 5s users (and presumably others when new hardware is released) is something that MacStories’ iOS 8 Wishes article mentioned, as a user interface issue rather than an accessibility issue. It’s another example of something that would be convenient for many “regular” users and could also be a boon to accessibility for those who find typing on the on-screen keyboard slow, painful, on fatiguing. Of course not everybody can use TouchID – it requires that you can physically touch a finger to the sensor which many people can’t do for many reasons – so this always needs to have alternatives available.

Siri

Continuing the theme of “let other developers access this feature” providing an API so that third-party apps can provide functions through Siri is really important for accessibility users and has been mentioned by several accessibility wish list articles including Jonathan Mosen’s. Currently, Siri only has functions that Apple deems are important or necessary enough to add, so for example the Facebook and Twitter apps can be addressed via Siri but most third-party apps can’t.

Siri input screen
Siri running on iOS 7 on my iPhone 5

An API for Siri would allow smaller niche apps to be addressed via Siri, giving Siri users potentially more power and functionality available to them. Given the numbers of users with disabilities who use Siri, this can only be a plus in accessibility terms.

[Edited to add some links to other wish lists which were published after this one, or which I only became aware of after publishing mine:

]

So there’s all the accessibility wishes I could find, including my own. If you have any additional thoughts, please leave a comment at the bottom of this article – I’d very much like to hear them.

– Ricky

2 thoughts on “Round-up: iOS 8 Accessibility Wishes”

  1. Great article Ricky! Yeah 3rd party Siri integration would be a game changer for me as well as many others I would think. I was using a jailbroken iPhone for around six months last year and there were a few things I was doing it via Siri, like controlling Spotify, that you can’t do otherwise. I know there are some technical reasoning behind this but since it can be done there that obviously proves it can be done.

    And another big yes to third-party keyboards. I don’t like the chances of this one happening either but we can always hope!

    Thanks for suggesting that iPhone keyboard app. I was not aware of it. Downloaded!

  2. I would love to see the Zoom option to be like Android zoom interface. Android zoom is at the corner of their screen. It’s easier than pulling the two circles and then make it disappear.

Leave a Reply

Your comment may be held up by our moderation or anti-spam software: please be patient if your comment does not immediately appear. You can include some HTML in comments, but including links or web addresses makes it more likely your comment will be delayed by moderation. Please stick to the comment policy.