0

I wondered if it was possible (and desirable from an accessibility functionality point of view) to have Voice Over announce the title of each new view that the user goes onto. So something like Voice over saying

"Address Book, header"

followed by the active selection being on the back button

"Back button"

At first I tried explicitly calling out this by using the notification function and constructing the string that I'd like Voice Over to say. This seemed to work when the user went into a newly pushed view, but didn't work when returning to that same view. Even though my hook was in my VC's ViewWillAppear method and so was being called for both of these.

I am a little confused as if I push on a view modally, sliding up from the bottom of the screen then the default iOS behaviour (without any extra prompting by my code) is for it to announce the view menu title then move onto the back button. Yet when push segueing into new views on my nav controller it just seems to want to select and only announce the back button.

I appreciate back button selection is a standard and sensible default, also that perhaps a user who knows there way around an app may get tired by having the new views announce themselves. But to me it felt like it may help keep things clear for users, especially new users if views announced themselves as they appear.

It's the fact that iOS itself seems to behave differently depending on how the view is presented that just makes me wonder if I'm doing something wrong. Is this a good idea and is there a standard way to get this behavior working consistently?

Cheers

jimbobuk
  • 1,211
  • 12
  • 25

2 Answers2

1

I would say that this is not desirable from an Accessibility Point of view. The default iOS behavior, despite being non-ideal from time to time, is something that users will be accustomed to.

For example: if your browsing around a website, and it has funky looking buttons. Eventually you get use to these funky looking buttons. If you then saw a normal looking button, would you not be a little confused for a second, and say "hey what's different about this button". It would give you pause right?

From an Accessibility point of view, sometimes the default behavior is best (as long as it is generally accessible) than something that is even MORE accessible. Because, expected behaviors become just that... expected. When you turn on VoiceOver for other applications, is this behavior normal?

In general, when testing this, test against Apple's applications, and follow their guidelines and behaviors.

MobA11y
  • 18,425
  • 3
  • 49
  • 76
  • Thanks for your reply. I agree testing against core apps is a great idea of seeing what's possible. In this case however I find that the core apps seem to do what I want to have my app do, but I don't know how they do it. The settings app reads out as follows.. "settings" on the first page. Into General... "General Settings back button". Into Accessibility, "Accessibility General Back Button". It says the same as you pop views back up to the root. So how do they do this? Have they set the accessibility label for the back button to read out the title before the button? – jimbobuk Jun 17 '15 at 21:13
  • I've discovered what the problem is.. my titles of my views are being assigned as views so that I can embed an image as well as the title text. I assign these titleViews as follows - self.navigationItem.titleView = . When done this way iOS does NOT read out the accessibility label of this view properly. If however I assign the text title just to myself as follows - self.title = then this title text is read out how i want as the prefix to the back button label. It seems that there's a bug or something i'm not doing with my custom title views. – jimbobuk Jun 17 '15 at 22:14
-1

If you set the accessibilityLabel of your custom titleView VoiceOver will read it out as the title of the page. Then, it will read out the first item ("Back Button"). In other words:

self.navigationItem.titleView.accessibilityLabel = @"....";
Scott K.
  • 1,761
  • 15
  • 26