Teaching and Testing iOS App VoiceOver Accessibility Webinar

Blind Access Journal

This approximately one-hour podcast is an audio recording of a real-world demonstration for following a systematic plan that explores, evaluates and tests iOS apps for accessibility with Apple’s built-in VoiceOver screen reader for blind and low-vision users. The August 3, 2016 webinar was presented by Darrell Hilliker and hosted by the Arizona Technology Access Program. A video, including closed captioning, is also available.

• Listen or Pause: Teaching and Testing iOS App VoiceOver Accessibility Webinar
• Download: Teaching and Testing iOS App VoiceOver Accessibility Webinar

Teaching and Testing iOS App VoiceOver Accessibility Webinar Notes

Introduction

Webinar Purpose: introduce and demonstrate a step-by-step plan that provides a straightforward way for advocates, developers, educators and others to quickly explore, learn and improve the accessibility of all apps in Apple’s iOS ecosystem.

What is a Screen Reader?

• A form of assistive technology
• A Software program that turns information shown on a screen of a computer or mobile device into Braille or speech
• Screen readers and accessibility enable blind people to learn, work and live in a technology-based world alongside sighted people.

VoiceOver

• One type of screen reader that was created by Apple
• Has been a built-in feature on all iOS devices since 2010
• Enables Braille and speech access for users who are unable to see the screen
• Speaks screen elements aloud or enables them to be displayed in braille

Accessibility

• True accessibility means that all parts of a platform’s features, benefits, information, policies, procedures, products, responsibilities, rights, services and technologies are developed and implemented in ways that are usable by people with disabilities.
• VoiceOver and other screen readers work best when apps are deliberately developed in ways that ensure compatibility.
• Important for blind/VI individuals to be considered during development and included in the testing process.
• Apple provides developers guidelines for making apps work with VoiceOver.

The Benefits of a Plan for Evaluating and Testing AppAccessibility

• Advocates may use the plan to identify the accessibility issues they report to developers.
• Developers may follow the plan to test their apps.
• Decision makers may incorporate the plan into their user-acceptance testing and other procedures.
• Educators may use the plan as a framework for evaluating the non-visual accessibility of iOS apps.

Starting VoiceOver

1. Press the Home button on the iOS device. (round button located on the bottom middle of the screen)
2. Tap Settings.
3. Tap General.
4. Tap Accessibility.
5. Tap VoiceOver.
6. Hold the VoiceOver switch and swipe to the right to turn it on.
7. (Recommended) Hold the Speak Hints switch and swipe to the right to turn it on.
8. (Optional) Triple tap the screen with three fingers to enable the Screen Curtain. This feature blanks out the screen, resulting in a more realistic environment for nonvisual accessibility testing.

Use Any of These Techniques To Activate VoiceOver Without Sight.

• Press the Home button three times quickly. (Works if the Triple Click Home option in the iOS device’s accessibility settings is configured to use VoiceOver)
• Hold down the Home button and ask Siri to “turn on VoiceOver”
• Connect the iOS device to a computer running iTunes and turn on VoiceOver under the accessibility configuration screen.

The Plan

1. Open the app to be tested.
2. Tap the top of the screen with four fingers.
3. Flick to the right through all elements on the app’s home screen.
1. Are all controls labeled in a way that makes sense when you listen to VoiceOver without looking at the screen?
2. Are you able to choose all buttons and other controls by double tapping them as you hear them spoken by VoiceOver?
3. Does VoiceOver stay focused throughout use or does it become jumpy and read items out of order?
4. When one or more items in a list is highlighted or selected, does VoiceOver say “selected” or provide any other indication of its status?
5. If a list typically enables a sighted user to pull down with one finger, is a VoiceOver user able to update the list by swiping down with three fingers?
6. Are all elements available to VoiceOver or are some items not spoken?
7. Are there features that require the use of custom gestures that are not available to VoiceOver users?
8. If visual cues, such as color, are important, does VoiceOver speak this information?
9. Are all elements presented in a logical order as you move around the screen? If the relationship between elements is important, is it clearly conveyed nonvisually?
10. Listen for special hints, such as “double tap to play,” spoken after the name of each element. If these hints are never heard, make sure hints are enabled in VoiceOver settings.
11. If audio is playing, does its volume decrease, or duck down, while VoiceOver is speaking?
12. Does a two-finger scrub (Z-shaped gesture) activate the escape function of the arrow in the upper-lefthand corner of the screen?
13. Does the app offer accessibility enhancements such as direct touch, keyboard shortcuts, magic tap or specific support for Braille displays, switches or other forms of assistive technology?
4. Flick to the left through the same home screen. Make detailed notes of anything that does not seem to function as expected with VoiceOver enabled.
5. Tap the top of the screen with four fingers.
6. Flick to the right, one element at a time, and double tap the first item where choosing it should lead to another screen.
7. Repeat steps 3 through 5 on every screen the app contains, testing and noting any issues found with all elements.

Reporting and Resolving Accessibility Bugs

If you are a developer, using the notes obtained from testing, make all bug fixes necessary to deliver a fully accessible experience for users who rely on VoiceOver. Consider prioritizing the correction of accessibility bugs according to the order suggested in the plan. See the resources at the end of this presentation for details.

If you are reporting accessibility bugs to a developer, consider using the following format:

• Description: A few concise words explaining the accessibility issue.
• Steps to reproduce: Write down the exact steps you followed to cause the accessibility bug to happen.
• Current behavior: Summarize the incorrect or unexpected behavior you are observing.
• Expected behavior: Summarize the behavior you expect to observe once the accessibility issue has been resolved.
• App and hardware information: Include a statement concisely providing as much information as possible about the version of the app being tested and the iOS device on which it is running.

Example Bug Report

The following accessibility bug was recently filed with Facebook against an important feature in the company’s iOS app.

Description: The details of event invitations are inaccessible to VoiceOver.

Steps to reproduce:

1. Make sure VoiceOver is turned on in Settings > General > Accessibility > VoiceOver on the iOS device.
2. Open the Facebook app.
3. Open any event invitation.
4. Tap the top of the screen with four fingers.
5. Repeatedly flick to the right through the event invitation, pausing after each flick to listen to the information provided by VoiceOver.
6. Note that important information, such as the event’s date, location, time and other details, are not spoken.

Current behavior: In its current implementation, event invitations are inaccessible and virtually useless to blind people using Facebook’s iOS app.

Expected behavior: Blind Facebook users should be able to access event invitations on terms of equality with their sighted friends.

Facebook version 60.0.0.37.141 is running on an iPhone 6 with iOS version 9.3.3.

Accessibility Testing

• If you are a developer, check your work using blind alpha testers, followed by a select group of beta testers from the blind community.
• If you are an advocate, thoroughly test the app according to the plan,then provide detailed feedback to its developer along with your accessibility request.
• If you are an educator, test the app against this plan and any additional laws, policies or regulations your institution may have in place before recommending its use for your blind students.
• If you are a decision maker, test the app against this plan and any additional laws, policies or regulations that apply to your agency, company, organization or personal conscience, then do not recommend or purchase the app if it is not accessible. Provide feedback about your decision to the company that owns the app.

Resources

• VoiceOverEasy Introductory Tutorials
• Accessibility Programming Guidelines for iOS
• Learn VoiceOver gestures
• Test Accessibility on Your Device with VoiceOver
• View Controller Programming Guide for iOS: Supporting Accessibility
• Tips For Accessibility Testing Of iOS Apps
• Information For Developers On How to Build Accessible iOS and Mac Apps
• Tips for Taking Full Advantage of VoiceOver in Your App

We love hearing from our listeners! Please feel free to talk with us in the comments. What do you like? How could we make the show better? What topics would you like us to cover on future shows?

If you use Twitter, letâ€https://s.w.org/images/core/emoji/12.0.0-1/72x72/2122.png" alt="™" style="height: 1em; max-height: 1em;" />s get connected! Please follow Allison (@AlliTalk) and Darrell (@darrell).

http://feeds.feedburner.com/~r/BlindAccessJournal/~4/uEEllhdU46M" height="1" width="1" alt=""/>