Accessibility of the BankID iOS app

The BankID app

A month ago, I wrote a blog post about the EU directive that requires public sector web and mobile apps to be accessible. At last, here is the first instalment in the promised reviews of public sector iOS apps.

While the BankID app is not a public sector app - the ID is issued by the user's bank and managed through the BankID application - it is a common strategy for electronic identification in Sweden. Users use it to authenticate with websites and apps of government agencies, banks, healthcare providers etc., and also to sign documents. For public sector iOS apps, the BankID app is often the only means of authentication, so unless it is accessible, those applications aren't either.

The good news is that this app is fairly accessible with screen readers and devices configured to use large text size, at least for the most common scenario. It also seems that the team behind it responded quickly when a serious VoiceOver issue was reported (see this post on the TB Teknik blog, in Swedish).

Use scenarios

Authenticating with an app running on the same device

If a user wants to authenticate with a mobile app that runs on the same device as the BankID app, the source app starts the BankID app directly. The BankID app displays who is requesting the authentication, and the user can go ahead and enter their security code. The code is processed and if correct the user is returned to sending app, now authenticated.

Authenticating with a web app using social security number

If the user wants to authenticate with a web application, or with an app that is running on a device other than the one with the BankID app, the typical procedure is to enter a social security number in the source application prior to manually starting the BankID app. Once the authentication request is available to the BankID app, it displays the name of the entity that requests authentication, and allows the end user to enter a security code. The success or failure is propagated to the source application.

Authenticating with a web app using a QR code

An alternative procedure is for the website or app to present a QR code. In this case the user also starts the BankID app manually, then taps a QR code button. This opens a camera view where the user scans the QR code. On successfully scanning the code, the app displays the name of the entity that is requesting authentication and the user enters their security code as in the previous scenarios.

Signing a document or transaction

When signing a document the signing procedure is initiated from app where the user is authenticated. The user manually starts the BankID app, reviews the text to be signed, and then enters the security code.

Accessibility

Larger text sizes

Supporting larger text sizes in an iOS app involves two separate tasks. First the developers have to ensure that all text in the app is configured to be displayed with dynamic font sizes. Second, they need to make sure that the app displays OK if the end user ramps the text size up to the maximum size, to avoid that text is truncated, hidden or overlaps with other text. This typically involves reviewing the layout so that text elements can grow as needed, and sometimes specifying maximum font sizes for individual elements.

This app uses dynamic font sizing for some of the text. I tested on a small screen with the accessibility font size turned up to max (for instructions, see "Making the font even bigger" on this apple support page). A lot of text is both scaled and laid out to fit on a small screen without needing to scroll horizontally, but some notable exceptions are the Settings button and the QR code button (Screenshot 1 below).

Screenshot 1: QR code and settings button labels are not scaled

When authenticating, details about the authentication request are scaled, but not the navigation bar items, and the security code textfield label is truncated (Screenshot 2). For what it is worth, navigation bar items often do not scale very much on Apple's accessible apps either, and the buttons are in standard places.

Screenshot 2: authentication mode

The QR code scenario has no buttons other than the navigation bar buttons, and the text on these buttons do not scale (Screenshot 3).

Screenshot 3: QR code scanner view

In the non-QR code authentication scenarios, the important text is scaled. This is however not true of the signing scenario. The name of the entity requesting the signature is scaled, but the details of what the user is going to sign are not (Screenshot 4). 

Screenshot 4: Signing a document

This text needs to be scaled too, possibly combined with the option of viewing the whole text in a separate view.

VoiceOver

VoiceOver language selection

The BankID app is localised to English and Swedish. If the device's locale is neither of those two, the text in the app defaults to English, but VoiceOver starts in the device language. I blogged about a workaround for this problem for end users in  Configuring the iOS screen reader VoiceOver to work with more than one language, and described a solution for developers so that end users don't have to manually change the language 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)

Usability of direct or social security number authentication

If you start the BankID app manually without having first initiated authentication through another app or web site, initial focus is set on the text "Ready to use. Start a login or a signature on a web page or in another app" as seen in Screenshot 1. So this is the first thing that is read out, which is good. In addition to the label, three other accessibility elements are identified, the QR code button, the "Settings" button and the "About" button, so you can reach all three. Settings is a standard table view.

If you start the app after having initiated authentication by entering your social security number into a different application, the app moves directly to a new view controller, with focus on the first element on that controller which happens to be the "Cancel" button on the navigation bar (Screenshot 2, repeated here).

Screenshot 2: authentication mode

Swiping through the elements on the view, you reach

1. The heading ("Identification")
2. The user's name (which is rendered with a button, although tapping the button does not have any effect)
3. The label "I identify myself at"
4. The label of the entity requiring authentication
5. The textfield where you enter the security code

The textfield for entering the security code (5) is not the iOS standard textfield. A standard textfield configured to mask the input plays a click when you enter a character, but this is a custom version with an asterisk as a mask for the character input, so the VoiceOver feedback is the word "Star" for every entered character. This had me very confused the first time - I thought I had accidentally entered a star.

Even though this view has a "Cancel" button, the escape gesture (two finger scrub in a Z-pattern) has not been implemented.

Once you've entered the code and tapped Identify, the app is configured to announce both when the authentication is in progress, and when it is complete, which is good.

If you enter the wrong code, an alert is displayed. On closing the alert, focus is transferred to the first item on the view again (the "Cancel" button), and the user has to manually transfer focus to the security code field.

Authenticating with a social security number is functional and the updates when authentication is in progress are very good. There are a couple of changes that could make it even better:

• Although iOS VoiceOver users probably are used to it, it is odd to place the initial focus on the "Cancel" button when displaying the new view. A more efficient UI would transfer directly to the information of which entity is requesting authentication (or at least to the view heading), and implement the escape action as a quick way to cancel. 
• When the view is displayed after the user has entered the wrong code, focus should be placed on the textfield for the security code when the alert is closed.
• Replace the button that displays the name of the user with a label
• For efficiency, it would be quicker if you didn't need to swipe through two separate accessibility items to find out the source of the authentication request (3, "I identify myself at" and 4, "<Entity>"). This could be achieved by suppressing 3 as an accessibility elements and setting an accessibility label on 4.
• Replace the confusing "Star" feedback from the security code textfield.
• Implement the escape gesture. 

Usability with respect to QR code authentication

QR code authentication is a whole other kettle of fish.  Websites wishing to use this mechanism need to think through the UX carefully, so that screen reader users are informed that the QR code mechanism is used, and that the QR code is displayed. The web site I used to test the functionality did neither - VoiceOver focus was not transferred to the QR code but remained on a no longer visible button, in such a way that the VoiceOver focus frame was rendered across and over the code. The user needs to be informed that a QR code for the BankID app is displayed, maybe with a reminder to make sure that their screen is lit up. It wouldn't hurt to say approximately where on the screen the code is positioned either. In general it is fair to say that this strategy requires UX design and good coding skills from the site developers.

However, this is supposed to be about the BankID app, so let's assume that the source app has done the right thing. From the BankID app, this procedure starts by tapping the QR code button. This brings us to a new view (Screenshot 3, repeated here) with a nav bar with a "Back" button and a "Switch Camera" button.

Screenshot 3: QR code scanner view

Initial focus is on the "Back" button. There is no heading on this view,  and"Switch camera" is the only other accessibility element.

Because of the focus switch, the user can infer that there has been a change in view, but there is no information on what to do. Switching to the front camera isn't very useful for this task (unless perhaps the rear camera is broken), though in this case it is a hint that a camera view is involved.

The escape gesture does work from this view and has the same effect as the "Back" button.

I attempted to move the phone slowly in front of the monitor and was able to capture codes most of the time though it took patience.

When the QR code is captured, the app switches view to enter a security code. This is the same view as is displayed in Screenshot 2. At this point you get the feedback that the view has changed because the screen reader focuses on the "Cancel" button on that view.

There is a significant delay after the QR code has been found until the security code view is displayed, but there is no auditory feedback in this interval. This means that as a user, you don't know that you have succeeded in reading the QR code, and you keep moving the device trying to locate it until this happens.

This mechanism is not for the faint of heart!

There are a number of things that the BankID app could do better in this scenario.

• The user needs to be told what is expected of them, so some kind of text element has to be added. It could be a heading (which doesn't even have to be visible to non-screen reader users). Space is not a limitation since the heading can have an accessibility label that can be as long as needed. However, while this would work for screen reader users, the ubiquity of this app is such that users with cognitive impairments need to be able to use it too. Some form of visible instruction is a good idea. 
• As well as explaining what to do, it would be helpful to include information about how much time the user has to carry out the task.
• Because there is a long delay between the code capture and the audio feedback from switching to the next view,  there needs to be audio feedback as soon as the code has been captured.
• The "Back" button should be labelled "Cancel" to match the other views. 

Usability with respect to signing 

The view used to sign has the same components as the authentication view, plus the text to be signed. VoiceOver reads out the text to be signed so this works as well as the authentication view does. 

 Summary 

For VoiceOver users, this app works reasonably well for authenticating in the non-QR code scenario, and for signing. With some changes, it would work even better.  The QR code authentication method is barely possible to execute (and that is assuming that the site that requests the authentication understand the challenges on their side).

The app works OK with large text sizes except for signing, where the text to be signed does not scale.