How hard can it be to configure an iOS app to make sure that VoiceOver switches to the app's language? (Answer: really, really hard)

In a previous post, I described how to configure the iOS screen reader VoiceOver to handle multiple languages, allowing the user to manually switch to the language of an app.

This is something that screen reader users who are proficient in more that one language almost always need to change manually when they want to use an app that is not localised to the device's system locale.

However, it doesn't seem to be impossible to configure apps to trigger VoiceOver to switch language automatically. When using VoiceOver with Safari, it switches to the language specified in the document.

I decided to investigate what programmers need to do to in order to make the screen reader switch language automatically in an app. In fact, I was on the verge of promising to do so in my previous post about manually changing the language that VoiceOver uses. Luckily I came to my senses and remembered that I should never assume that I can perform a housekeeping task in Xcode, no matter how normal and straightforward I think the task should be. After a lot of experimentation and some helpful suggestions, I have finally found a solution, so here goes.

There is a setting called Localization native development region in Info.plist but the graphical editor has a short list of languages. You can change it to another language if you switch to the source editor, but it does not take effect in the project settings. So after changing Info.plist, you need to edit the project file as well:

1. Close the project in Xcode and open the file project.pbxproj in an external editor. 
2. Search the file for properties called developmentRegion and knownRegions. Replace "en" with the actual locale.

The changes will be reflected on the project's info panel. Attempting to achieve the same result from the Xcode graphic editor does not seem to completely get rid of English in the settings above.

Now we've told the app what its locale is, and that it only has one known locale. Or? Frustratingly, though it seems highly plausible that the locale used to display strings in the app correlates with the desired VoiceOver language, it has no effect on what VoiceOver thinks it should do. It doesn't matter what you do with the project localization settings, having a base language or not - I tried.  Short of providing support for the system locale, the correct language does not get picked.

After asking for help on stack overflow I got a tip from the user Mats which led to a solution: setting the accessibilityLanguage in code in the application. Modify didFinishLaunchingWithOptions with the following addition:

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        // Insert your application's locale

        application.accessibilityLanguage = "sv"

        return true

    }

This finally triggers the screen reader to read the accessible elements in the app in the selected language.

Note that anybody who has written an accessible application should set the accessibilityLanguage, whether the app is localised or not, as you could have users who whose device's system locale is one that you do not support. For localised applications, you will need to detect which locale was used and match the accessibilityLanguage to that one.

Configuring the iOS screen reader VoiceOver to work with more than one language

A quick tip for users who need for the iOS screenreader VoiceOver to work with more than one language.

By default when you turn on VoiceOver, the screenreader language is the same as the device's default language. But what if you have apps in another language, or want to visit websites in another language?

You can switch language on the go by navigating to the VoiceOver Speech settings, that is, open General, Accessibility, VoiceOver, Speech. At the end of this view, there is a section called ROTOR LANGUAGES. You can additional languages as needed.

Switch language on the fly by opening the rotor, turning until you hear the languages setting and flicking up and down to find the desired language (more information on using the rotor in Apple's guide to the VoiceOver rotor).

It is reasonably common for web sites to identify the language of the content, and where this has been done, and it seems that the VoiceOver/Safari combo automatically picks the right language if it has been configured, i.e. there is no need to actively change the language in the rotor.

For apps the situation is different. I have as yet not been able to figure out what would trigger an automatic language change in a native iOS app (whereas VoiceOver does switch language in apps that rely on displaying web content if that has language markup).  Specifying the base language for the app, and ensuring that the locale configuration does not contain any leftover language files does not seem to be sufficient. I'll add an update if I find a solution.

Update: the solution is posted in How hard can it be to configure an iOS app to make sure that VoiceOver switches to the app's language? (Answer: really, really hard)

"Some important buttons on the main screen remain unlabeled. Fortunately it's not too hard to figure out what they do with some trials."

What sort of user experience is this? An all too common one, if you are using a screen reader. The title is a quote from a review of the iOS version of the Duolingo app on the AppleVis site, where blind and low-vision users help each other use Apple products and apps running on those platforms. Here is the review in full:

In spite of issues making recent versions totally unusable, this version is once again usable. However, even though it is [usable], there are definitely some annoying problems to watch out for. The first is that some important buttons on the main screen remain unlabeled. Fortunately it's not too hard to figure out what they do with some trials. The second is that there is no way to tell what color your tree is. This means that you can't determine if you need to strengthen weak skills or not. You also can't easily figure out which skills are complete. The third issue is that it's not always possible to reread what you've typed, in questions where you're expected to enter your answer via the keyboard. In spite of these major problems, I still use the app regularly, because the app is really good at what it does.

 Review by Aron C on the AppleVis web site. First added on August 13, 2013; updated on October 4, 2017. Emphasis mine.

The review has over 70 comments, many of which involve posters helping each other figure out how what to do when they have gotten stuck. For example, at one point a suggested workaround for reaching the settings included temporarily turning off the screen reader to tap a button.

The comment thread ought to be required reading for anybody involved in the production of user interfaces, not least to dispel any doubts that people with vision impairments use smartphones and have reasonable expectations on usability just like everyone else.

Things are about to change, at least for one class of applications. As of September 23, 2018 the EU directive on the accessibility of the websites and mobile applications of public sector bodies is in force. It became Swedish law on January 1 2019: Lagen om tillgänglighet till digital offentlig service (in Swedish, published by the Agency for Digital Government). New public sector web sites need to be accessible by September 23, 2019; existing ones by September 23, 2020; and mobile apps by June 23, 2021.

The Swedish publication states that "the requirements to which web sites and mobile applications will need to conform are yet to be decided" (my translation) as they are still in progress. It adds that they will likely be based on a European standard based on WCAG 2.1 AA, a document that lists requirements both for web and mobile apps. I have to admit to being surprised by the fact that there is a compliance date in the relatively near future without any official requirements (all too familiar in the software industry, I know!). But assistive technology is not new, nor is legislation in the area, with  the US congress having enacted Section 508 of the Rehabilitation Act of 1973 in 1998. There should be plenty of experience to draw on.

Lack of specifics notwithstanding, it can safely be assumed that the standards will require accessibility for users without vision, users with limited vision, and users with limited color perception. For these user communities, the implementation techniques involved in supporting them are well understood, whether it be for mobile or web apps, so there is no reason to wait - good usability (not to mention good governance) means access for everybody.

While the mobile app compliance date is a couple of years out, adopting an approach of wait and see  is not a good idea. Apart from the common decency argument, accessibility is a lot like internationalization - it can be added afterwards, but things will go a lot more smoothly if everybody involved understands from the get-go that dynamically sized fonts, like message translations, mean that the size of elements is not fixed. (Also, it is not unusual that actions which improve screen reader experience constitute usability improvements at large.)

I am going to evaluate some Swedish public sector apps, both mobile and web, to see how they fare with respect to screen readers and accessible font sizes, and will post the results here. First out will be the iOS versions of "Mina Sidor" published by by Försäkringskassan (the Social Security Administration) and BankID, an app that allows users to authenticate themselves electronically that is one of the accepted means of authenticating with government agency sites. Until then!

PS. If you want to try out a screen reader on your smartphone, the iMore accessibility guide is a good resource for getting started on iOS devices. Google's Talkback guide explains how to use the Android built-in screen reader.