Examples for developers—near misses and great experiences

App Developer

Hi AppleVis community, I'm giving a talk in a few weeks to iOS and macOS developers at the /dev/world conference in Melbourne, Australia: Practical tips to confidently support VoiceOver and Voice Control. The basic thrust of the talk is: "As a developer with relatively intact vision, it’s easy to feel uncertain what ‘good’ sounds like, and to know how to tell if you’ve missed some better practices that might make a big difference to users who are blind or have low vision. This talk presents examples of what a great VoiceOver experience sounds like, and practical tips for how to implement it."

With 25 minutes for the talk, I'll have time to make about five to eight points... Given I want to briefly cover the new VoiceControl features in iOS 13, that leaves time for about five VoiceOver examples.

Clearly, making things actually accessible to VoiceOver control is a minimum baseline. What I'm interested in focussing on is some "near miss" examples—examples where an app is accessible via VoiceOver, but where there is something specific a developer could do that would have made the VoiceOver experience better, more streamlined, closer to best practices, or in some way a pleasure to use.

I would love suggestions from the AppleVis community if you have any examples that you think about be good to cover—or any other 'pet peeves' that you'd like to see put in front of a roomful of iOS and macOS developers in a few weeks time. I will also be mining the AppleVis forums to look for examples that may be already here. :)

Forum: 

#2 Relevant resources

App Developer

#3 This blog post might help

Member of the AppleVis Blog Team

I wrote an article last year that might have what you're looking for: https://www.applevis.com/blog/ios-developers-taking-your-accessibility-g...

I'm going to quote an example of a near miss:

"As an example of poor button labelling, In the Kindle app, the control that, before the last major update, was quite sensibly called "return to book", is now labelled "book actions menu, exit button". This is confusing because it would be quite easy to hear "book actions menu" and think it will open a new menu, or hear "exit button" and think it will close the book. Compared to the old label, it has more words but less information. The label "Return to book" tells me exactly where I’ll be when I tap on it, but "book actions menu, exit button" doesn't tell me whether I will land in the book or in my library."

That's a fairly minor example, and I don't know if you're looking for something more significant, but it was the one that immediately came to mind.

The linked article also has examples of apps that, as the title suggests, are not just good, but great in their accessibility. Weather Gods is one I'd like to draw attention to for its developer's commitment to making what was quite a visual app, with non-standard controls I believe, fully accessible, having VoiceOver users test the app, and taking on board feedback.

Hope that helps.

#4 BARD Mobile as a Good Example?

Hi Duncan and welcome to AppleVis. As a rather new iOS user I have yet to come across many if any apps with poor accessibility. But if I may I'd like to give an example other than WG. WG is fantastic, but since that one has already been mentioned I'd like to give another example. I'm a long-time NLS patron, and have been using BARD Mobile for a little while now. All buttons in this app are clearly labeled, and do exactly what their respective labels say. Additionally, the interface is very good. I also like their method of delivering status updates, i.e., when a user launches the app the status message appears followed by a button labeled "OK". I'd go on but you get my point.

#5 Pet Peeve

One of my personal pet peeves that is an example of something that is accessible, but could be better is when buttons or settings are double labelled. Many apps will have one text string followed by a button that can toggle. But some apps first say the label, and then repeat it again as part of the actual button. It's not a big deal, and it's better than no label, but it bugs me.

And of course I can't think of a specific example. I will keep my ears open for it and add it in this thread.

#6 Thanks everyone

App Developer

Thanks everyone who has given input so far—most appreciated. I'm preparing the talk and the examples in it over the next week and this is going to be most useful. Still time for any other input too. I know that the developers will love to hear the 'voice' of end users in the presentation. I'll be quoting from each of you in my presentation. Thank you!