iOS App VoiceOver Accessibility Teaching and Testing Plan

Thanks for helping raise awareness of accessibility on these extraordinary devices!

This plan is well thought out and should help achieve accessibility goals

I think that a problem with this guide is that it actually doesn't say the purpose of performing the various actions. If I, an unsure iOS developer, were to use your guide, I would certainly hear some things, but I would not understand why I had to tap at the top of the screen with four fingers rather than just tapping on the first on-screen element, or what VoiceOver should ideally announce as I flick through the screen, and what "normal" behaviour is.

Step 4a of your guide says "Are all controls labeled in a way that makes sense when you listen to VoiceOver without looking at the screen? Make detailed notes of anything that does not make sense. This applies to charts, graphics, maps and any other elements that may require special consideration in order to provide equal accessibility."

I would rewrite this statement to be something more like "Are all controls labeled in a way that makes sense when you listen to VoiceOver without looking at the screen, i.e. would a VoiceOver user know the purposes and functions of all on-screen elements if they were using the app without sighted assistance? Make detailed notes of anything that you imagine a VoiceOver user would struggle with when using the app. This applies to charts, graphics, maps and any other elements that may require special consideration in order to provide equal accessibility. However, it should be noted that it is not desirable for VoiceOver users to know about on-screen elements that provide no actual value to the app. This could include extraneous images and text that is solely for visual appeal."

One thing that stood out to me while reading through this, especially when you mention going to other screens of the app, is that developers often don't use the Stock "back button" control type. It might often still be a button that VoiceOver announces as "back" when you flick through it, but thanks to the fact it's non standard the 2-finger scrub gesture is then broken as a result. I'm not sure where would be the best place to mention this in the guide, but developers should test if you can scrub your way back to previous screens.

Similarly I occasionally see lists that support the pull to refresh gesture, and for sighted people they work fine. With VO, you're supposed to do a 3-finger swipe down while at the top of the list to initiate a refresh, and in many cases this works, but I have seen instances of apps where it should work (as noted by text in the app itself), but performing the 3-finger swipe down doesn't work and you have to use the double-tap and hold and swipe down pass-through to force an update.

This is really, really well-written! I do believe however that the phrase, "without sighted assistance could be really helpful. Remember, this guide is, for the most part I'm guessing, aimed at mostly sighted app developers. Keep in mind that because they're just learning how to use VoiceOver, that they may not even understand all the things VoiceOver can actually do, but it's up to them to author the app properly. Using the phrase without sighted assistance could help them understand because they're still going to be looking at it from a visual way, even if VoiceOver is turned on and the screen curtain is on. It just reminds them that we'll be able to use the app independently, without the use of sighted help. I see nothing wrong with using the phrase at all. Also, you may want to remove, or slightly modify the bit about using 4 fingers to touch the screen before swiping through the different elements. Lots of people I know don't do that, even if you might. The idea is to let them know that not everyone does that, so it's not absolutely necessary to place 4 fingers on the screen before you swipe. Remember they're not used to using VoiceOver, it's not a part of their daily routine like it is for us. They're using it for testing purposes and aren't relying on it for every day use. Other than those little bits this looks really good!

Thank you for considering incorporating my ideas. My use of step 4a was an example; you should try to copy my suggestions for the other steps to make your guide as clear as possible. If you do not include sufficient explanation, a developer may try to infer the purpose of performing a particular step. If they infer correctly, then we can applaud them. If they infer incorrectly, they will not have any way to learn the correct way they can implement better VoiceOver support in their app. I too believe that all controls that can be interacted with should have proper text, and, if necessary, a VoiceOver hint. However, my comment about graphics and other visual elements was to say that not all graphics need to be described. For example, on many weather websites, there are graphics that show the weather conditions, e.g. sunny, cloudy, rainy, etc. A screen reader user would not need to know about these graphics (in fact, knowing about this would be unnecessary), and an equivalent would be to have a statement describing the weather which also included the temperature. Likewise, VoiceOver users do not need to know about other colours, visual effects or animations if they are not necessary for the use of the app. However, if they must be used, then VoiceOver users must have equal access to them, even if such functionality would only be very rarely used.

In another comment, you talked about how developers should make notes about behaviour that could be improved. Rather than saying "make detailed notes", you could ask developers to identify areas that could be improved. Then, suggest that they look at Apple's iOS Development Guidelines and choose an approach to render the area more accessible.

To make an app fully accessible, blind people must not have to go and seek sighted assistance. However, I feel that mentioning this will clarify the common misconception that blind people are dependent on sighted people for help and that we are incapable of using our iDevices independently.

I would like to help you with examples. What are you thinking exactly? Perhaps the comments section of this blog post is not the appropriate place for us to discuss this sort of thing as it could make the guide seem less professional. I understand the issue of the text getting too long. I do not think that asking the developer to make copious notes is necessary at every step of the process.

Developers should implement the standard "back" control that can be activated with a two-finger scrub. This allows users of braille displays, and users of the touch screen on apps with complex and lengthy screens to more easily refocus on the previous page.

Keep the part about the top of the screen. Braille display users find this a logical place to start exploring and navigating, and it is a nice reference point. Also, it can help in apps that are quite complex. In some apps, I have seen that doing this gesture can take me into an area where there is no content, thus making that part of the app quite inaccessible.

Darrell,

As others have said, this is a great plan...and the community involvement will only make it better.

Have you given any consideration to possibly including a "How to Use VoiceOver" section at the beginning of the guide? I think this would be helpful to developers who have never used VoiceOver. I don't see this being anything too lengthy, just telling them things like "Instead of single-tapping on an item to activate it, you double-tap when VoiceOver is enabled..."

I agree with Piotr that testing for the two-finger scrub gesture is important. My feeling is that if it is used universally across iOS and Apple apps, then the average user would expect that it would work in third-party apps as well.

In light of the comments of others, I started paying more attention to the flow of the wording for developers to take notes. I think, if a developer is committed enough to testing for accessibility, they are probably going to also take good notes without consistent prompting. For end-users not used to having to systematically document and track issues, more notation may not be as big of an issue.

I'm sure the beta testers and developers already know this. Whether your framework is used or not may not be a factor or considered. From what I know, this plan is far from a time tested method of testing.

thanks for this great article,
would you please any updates for it? would you recommend what shall i read now?