Focus control and mobile accessibility

This post follows a presentation I gave at the Mobile+Web Conference in Boston, July 2013. This deals specifically with the impact of providing focusability in mobile applications, whether iOS, Android, or web applications. Each platform provides unique methods and requirements.

What is an accessible mobile application?

Tommy Edison, the Blind Film Critic, shows how he is able to use the Instagram application with VoiceOver to not only take photographs, but to label and share them with his followers.

3 Steps to Accessibility

Accessible applications provide an equal experience to all users. This may sound complicated, but it can be distilled to three key factors.

Perceivable

All content that is presented visually must also be discoverable via a screen reader or other assistive technology.

Operable

All user interactions must be clearly labeled and react to user’s gestures.

This video shows how the Flipboard application is completely accessible. Everything is clearly labeled and the user has full control of the application.

Understandable

Content should be readable. Don’t hide important content within background images or treat complex information as a simple string.

This video shows a flashlight application that is not accessible. The buttons do not have accessibility labels, so the user would need to guess which of the buttons will actually turn the flashlight on and off.

Screen Readers

Screen reader software, such as VoiceOver, TalkBack, or Narrator provide an interface between the user and the application. The SR interprets the user’s gestures and the application’s output. Gestures are unique to screen reader usage, this can be surprising for custom gestures that detect onTouch events.

Go Native

Native components already include appropriate focus behaviors. Use these and your application will inherit the accessibility. You will need to control focus whenever using custom elements In HTML, links and form elements natively receive focus.

iOS Accessibility

isAccessibilityElement: Should an element receive focus?

isAccessibilityElement can be chosen via interface builder or programatically. Make sure this is set to yes for actionable items. Set it to false on parent containers when their children are actionable, i.e. UITableViewCell

This video of Chris Fleizach’s presentation at Stanford University shows how to enable accessibility via Interface Builder. Please watch this complete video, it is one of the best resources for accessiblity on iOS.

Pseudo-Modal Views

Pseudo-modal views are a common problem within IOS applications. While the modal window is separated visually from background components, often times the VoiceOver user is able to access buttons and other interfaces that are invisible. This is easily solved by using accessibilityViewIsModal

The default value for this property is NO. When the value of this property is YES, VoiceOver ignores the elements within the sibling views of the receiving view.
For example, in a window that contains sibling views A and B, setting accessibilityViewIsModal to YES on view B causes VoiceOver to ignore the elements in the view A. On the other hand, if view B contains a child view C and you set accessibilityViewIsModal to YES on view C, VoiceOver does not ignore the elements in view A.

This short video shows a right column that acts as a modal view. However, the user is able to access hidden buttons.

Grouping objects

VoiceOver will typically read elements in a left to right order. Use shouldGroupAccessibilityChildren to define a group of objects that are read in a vertical or other order.

Announcing Screen Changes

We need to let the user know when the screen is changing. Use UIAccessibilityPostNotification to announce the change. You can also move focus to the changed area, which is helpful for modals or dropdowns.

Labels and Hints

Make your content easy to understand by using accessibilityLabel and accessibilityHint. All custom buttons and images will need an accessibilityLabel, which is a text description. The previous flashlight application would be fixed by adding the following accessibilityLabel: flashlightSwitch.accessibilityLabel = @”Turn on the light”;. The accessibilityLabel is also helpful for concatenating strings to create an understandable label on UITableViewCells.

Use the accessibilityHint for interfaces that need a bit more description. This text string is announced after a short pause. flashlightSwitch.accessibilityHint = @”Light up the room”;

Warning: Custom Gestures with onTouch Events

Custom gestures in JavaScript do not work with VoiceOver, as the single finger swipe is used as a key element in VoiceOver navigation. iOS7 introduces a single finger swipe to allow users to access the back button functionality. Depending on where the user begins their swipe, custom JavaScript carousels and other swipe based gestures may not work. ALWAYS include an alternate method for your swipe gestures, such as back and forward buttons

Android

Focus control with android:focusable

Android allows you to define the elements that are focusable and actionable with android:focusable =”true”. When android cannot find an element that is focusable, it will treat the parent as a single text string.

Focus can also be programmed:

• setFocusable()
• isFocusable()
• requestFocus()

Custom views

It takes a bit more work to make a custom view accessible. Use accessibleNodeInfo to define the characteristics of your custom view. You will need to define:

• Position
• Description
• Interaction
• Children

This can result in verbose code. Fortunately, the Google Accessibility team announced a new helper class at GoogleIO 2013. exploreByTouchHelper only needs 5 abstract methods that borrow code you probably wrote for making the visual elements.

Announce screen changes

Announce screen changes with announceForAccessibilityCompat. Send a text string with new information, such as the color or subtotal. Classes with …Compat include backwards compatibility.

 public void setCanvasColor(int color) { mCanvasColor = color; updateSummaryText(); invalidate(); // Provide feedback to users of accessibility // services that screen content has changed. announceForAccessibilityCompat(mContext.getString( R.string.announcement_canvas_color_changed, getNameForColor(color))); } 

Android Lint

Android makes it very easy to test your applications during development. Use the Android Lint tool to find errors and potential problems from accessibility to security. You can also fix the issues quickly. This short video shows how to use Android Lint.

HTML5, Windows8, FirefoxOS, and other Web Apps

Use Native Components

HTML is full of tags that provide unique semantic value to the users. Do not replace semantic markup with generic divs. Links and form elements automatically receive focus and pass events and states.Divs, spans, images, lists, and other tags do not receive focus and events are not automatic. It’s much better to use a <button> than to apply styles and events to a div.

This video shows VoiceOver on iOS announcing various HTML5 form types. This video shows how an iPhone reacts to different form types. This test form uses no javascript and only very simple CSS. Currently, the only form input type that is not given a special interface is the color picker.

Keyboard (swipe) Functionality

Inserting the tabindex=”0” attribute allows an element, that normally does not receive focus, receive keyboard focus. Use this when retro-fitting div-based buttons. Although it’s still better to use a button. Use tabindex="-1" to remove an element from the keyboard flow. However, it can still receive focus via javascript. Support for div based buttons without tabindex is available on mobile devices, but shouldn’t be counted on.

Using .focus()

Let’s assume we have an application that generates a modal window filled with kitten thoughts. We will need to let the user know the window has appeared. We can do this by placing focus on the most important element in that div. In this case, it would be the header.

To place focus on a header, we will need to add tabindex=”-1″. We will then use JavaScript to set focus on the header AFTER it has appeared on the page.

 <h3 id="kitten">Kitten Time</h3> ... $('#kitten').focus(); 

Learn more about making modal and toggled views accessible: Include the Transcript – Toggle Visibility

Live Regions

Live Regions allow screen readers to announce dynamically changing content. This is perfect for subtotals, alerts, and validation messages. The aria-live="polite" attribute tells the screen reader to announce the new content after the user has finished typing. Use “asssertive” for alerts, when you need to notify the user immediately.

This video shows how a screen reader announces the content within a live region.

Loading…

Live regions can significantly improve your application’s usability when applied to the loading message. This is especially important when your app is requesting data and there may be a delay after submitting a request. Add aria-live=”assertive” to the loading image and make sure it has alt=”loading”. This will now be announced when your image is inserted into the screen or toggled display:none/block.

 <img src="loading.gif" alt="loading" aria-live="assertive"> 

Wrap Up

It’s not difficult to make your application accessible for screen readers. Use native components as much as possible, these will already inherit the required accessibility features. Make sure your objects are clearly labeled, can be discovered, and activated.