Design X Accessibility – The One Time Code challenge

It may seem a little bit strange when we put it that way (Design VERSUS Accessibility) but unfortunately it’s what we find most in the application market. Incredible designs with stunning effects, but accessibility is played sideways and makes the user’s life hell.

Accessibility first

Apps are for everyone. This doesn’t simply mean that they are available in the Stores to be downloaded. It means that everyone should be able to use them without restrictions.

A visually impaired user must have access to all features that a not visually impaired user. 

Accessibility must start from conception. Neglect accessibility due to deadlines, or not to care about its importance is a huge mistake. Especially if we mind that accessibility is a right provided by law in Brazil.

Art. 63. Accessibility on the websites maintained by companies with headquarters or commercial representation in the country or by government agencies is mandatory, for the use of the person with disabilities, guaranteeing them access to the available information, according to the best practices and guidelines of internationally adopted accessibility. – LAW No. 13,146, JULY 6, 2015.

In addition to rework and a significant increase in costs, neglecting accessibility may not be limited in the economic scenario. Ignoring accessibility is just like ignoring a group of people; it’s like telling them that they can’t use your app. This makes your brand gain a horrible image in a connected world scenario. Such negative publicity can cause hundreds or thousands of users to stop using your app: either because they are unable to use it, or because of empathy for those who cannot use it.

The OneTime Code

Let’s take an example, that’s very common in most apps. Almost all (ALMOST, but not all) apps that use a second SMS-based authentication factor have code-entry screens similar to the image below:

Beautiful, isn’t it? Each box being a character, becoming active, changing color as the code is entered. But this is an accessibility hell.

The case of the OneTime Code is one of those exceptions for the rule that reading must be the same as what is displayed: “reading” the fields, as they are displayed, causes more confusion than they help.

A visually impaired user, who uses VoiceOver (in iOS case), doesn’t access the fields by clicking on them. The action used to navigate between fields is a horizontal “swipe”, which tells VoiceOver that the user wants to navigate to the next field or to the previous one, depending on the direction of the swipe.

Now imagine that you were a VoiceOver user and are entering your code in those fields. To move from the last character to the first, you would need to perform N swipes, where N is the number of digits your code has.

And the worst part is how this is read. In each field, the reading is done individually, forcing the user to make a mental puzzle to try to assemble his password part by part, if we mind that he is navigating from the first to the last digit. Backwards, this becomes even more challenging.

Make the behaviour closer to concept

In OneTime Code case, despite being composed of N digits (usually 4 to 8), it is a unique code. This is the mental image that the users must have of this code: something unique.

When thinking about Design, a field made up of independent digits that change color when typed may seem very pleasing to the eye; but, when thinking about usability, things change a little bit.

We need to bring behaviour closer to the concept. Visually, we can have the field displayed individually, but in its behaviour, it must be treated as a single field.

In my next post, I will address this situation and this concept, showing how to solve it on iOS.