18

I'm in the process of making my iOS app accessible and I'm nearly finished. My app contains several custom screen transitions, and when VoiceOver is on it seems to pick either the top-leftmost element to describe after the transition or, occasionally, a random element. UIAccessibilityTraitSummaryElement looked promising but as I understand it only works when the app is started, not after arbitrary transitions.

There doesn't seem to be an accessibility trait or property to specify the preferred order that elements are given VoiceOver focus. Is there any way to force VoiceOver focus?

kevboh
  • 5,207
  • 5
  • 38
  • 54

2 Answers2

20

EDIT: iOS 6 is now available, and as mentioned by kevboh, you can now pass an argument when posting a UIAccessibilityLayoutChangedNotification or UIAccessibilityScreenChangedNotification:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, myAccessibilityElement);

myAccessibilityElement will in most cases be a UIView with isAccessibilityElement set to YES (the default for many views).

Alternatively, you could add the new trait added in iOS6 UIAccessibilityTraitHeader to your accessibility elements' accessibilityTraits, which should have the same result (although I didn't test this yet).

ORIGINAL: There's new API in iOS 6 that can't be discussed here because it is still under NDA, but can be found in the "Accessibility for iOS" video of WWDC 2012 (Session 210).

Failing that though, a workaround could be to manually trigger a announcement to override the default focused accessibility label announcement:

UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, @"Your text");
Patrick Pijnappel
  • 7,317
  • 3
  • 39
  • 39
  • Watched the session video last night, that API looks perfect. Thanks! For those looking for the in-video explanation, it occurs around 26:33 in Session 210 - Accessibility for iOS. – kevboh Aug 20 '12 at 13:44
  • 4
    Now that iOS 6 is public: you can pass in an accessibility element when posting a `UIAccessibilityLayoutChangedNotification` or `UIAccessibilityScreenChangedNotification` as the second argument to `UIAccessibilityPostNotification` and VoiceOver will focus on that element. – kevboh Sep 19 '12 at 21:22
  • 1
    I'm a bit confused about this - the documentation says that `UIAccessibilityScreenChangedNotification` is available in iOS 3.0 and later. They say you can pass a string or an accessibility element, but I suspect that although the notification has been available since 3.0, the second parameter can only be an accessibility element since 6.0 - is that right? – jhabbott Sep 27 '12 at 17:27
  • It doesn't seem to work anymore in iOS 8.3. Anyone had any success with this in iOS 8 ? – iDev May 27 '15 at 15:40
6

Interesting explanations to force the VoiceOver focus and reorder the elements as wished are provided thanks to this accessibility recommendations site.

NOTIFY A CONTENT CHANGE

When there is a content change in the current page, it is possible to notify the accessibility API using several types of notifications. To do that, we must send the change notification to the accessibility API using the method UIAccessibilityPostNotification.

There are several types of change notifications but the two most commonly used are:

  • UIAccessibilityLayoutChangedNotification : notifies that a part of the page has changed with 2 possible incoming parameters (a NSString or a UIObject). With a NSString, the notification behaves like a UIAccessibilityAnnouncementNotification with a VoiceOver vocalization. With a UIObject, focus is shifted to the user interface element. This notification is very similar to the UIAccessibilityAnnouncementNotification but should come as a result of dynamic content being deleted or added to the current view.
  • UIAccessibilityScreenChangedNotification : notifies that the whole page has changed including nil or a UIObject as incoming parameters. With nil, the first accessible element in the page is focused. With a UIObject, focus is shifted to the specified element with a VoiceOver. This notification comes along with a vocalization including a sound like announcing a new page.

READING ORDER

Redefining the VoiceOver reading order is done using the UIAccessibilityContainer protocol. The idea is to have a table of elements that defines the reading order of the elements. It is often very useful to use the shouldGroupAccessibilityElement attribute so we have a precise order but for a part of the view only (the rest of the view will be read using the native order provided by VoiceOver).

The best way to illustrate this feature is the keyboard whose keys order isn't necessary the appropriate one. Here's the desired order : 1, 2, 3, 4, 7, 6, 8, 9, 5. Two views are created (blue and grey) and we graphically put the numbers in them as defined hereunder : enter image description here

Illustrations and code snippets (Swift & ObjC) are also available to defining these 2 explanations.

XLE_22
  • 5,124
  • 3
  • 21
  • 72