Examples for developers—near misses and great experiences
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. :)
I'm going to reply to my own post to create here a list of potential examples in other forum posts:
I wrote an article last year that might have what you're looking for: https://www.applevis.com/blog/ios-developers-taking-your-accessibility-…
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.
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.
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.
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!
As I've just posted in my other thread at the time on a related set of questions, a much belated thanks for all the input in this thread. This was most helpful and informed my presentation to the /dev/world conference at the time... the videos weren't uploaded to the public until a long while after the conference, and so it kind of passed me by. Glad to finally loop back and be able to provide a link here to the video of the presentation for anyone who wants to access it.
I referenced the AppleVis community specifically in the presentation, and my intention was to all attribute each of the individual contributions I was able to include to the people who provided them. In the limited time I couldn't cover absolutely everything of course. /dev/world attendees specifically told me after the presentation that they really appreciated hearing your input and feedback as end users, something that doesn't get a voice that often at developer conferences. So thanks everyone! :)
As someone else mentioned, the Bard Mobile app is an excellent example of an app done corre correctly for Voiceover users: All buttons and tabs are clearly labled and the UI is free from clutter.
An app that I use a lot which I find frustrating to use with Voiceover is the NPR One app. Firstly the screen is cluttered with too much information. It takes many swipes right to get through the screen that is filled with elements to get to the element one is looking for, sort of like looking for a needle in a haystack.
Secondly, not all buttons are actually labeled as buttons and sometimes just appear as text on the screen. This makes it unclear whether double tapping an item will activate and action or not.
Thirdly, some buttons are not properly labeled with their action. An example of this is the "button" near the top center of the screen that is labled as a button, but because the function of the button is not labeled properly, Voiceover has to use it's screen recognition to say "probably a 'Play' button". If this was labeled properly it would simply say "Play" when flicking to this button (as it does when flicking to the "Play" button in the "Now Reading" tab of the Bard Mobile app).
Even if everything is labled properly in an app or web page, too much clutter makes the app or web page difficult for a person who is blind since they have to scan through a lot of useless information to find what they want.
The Pluto TV app needs to be made accessible.
Some apps make excellent use of VO gestures and are accessible. Facebook lets you magic tap to choose a set of actions on a post. This is a clever mode of providing context-aware actions for VO user. I haven't seen this on other apps, but there are myriad uses for this depending not he type of app a developer is creating where certain actions may be required.
One annoyance I point out to developers is that the label for an element should not contain instructions on what to do with that element. I am seeing a new trend where buttons aren't labeled "Buy" or "Comment" or "Continue". The labels are now "Tap to Buy", "Tap to Comment" and "Tap to Continue". This gets way too verbose for the VO user who already knows that they need to tap or double tap the button to perform an action. This is what hints are for. Hints should be implemented in every app. We did this in Venture Zone Game with very specific hints on what each element did and what would happen if a user tapped, dragged or swiped on an element.
Apps like Etsy and Amazon are not built with a native mobile experience in mind as the screens can get cluttered with lots of controls and buttons, tons of headings and very little in the way of an intuitive design like the native Apple Store app.
The biggest offenders for inaccessible apps in my opinion are apps that are made for appliances such as speakers, microwaves, thermostats, grills, home audio gear, TVs and so on. These apps are often web views wrapped in some native code with little in the way of accessibility provided for buttons and other UI elements.
Just my two cents.