Get best of the week

How we conducted accessibility testing in Alfa Digital

Digital products should be not only beautiful, convenient and profitable, but also accessible for people with disabilities. This is more important than it seems at first glance. Sometimes this has to be conveyed to the business, to Product Owners and to direct colleagues. But then it turns out to bring your product to a new level. We are with a senior iOS developerfamilkotell about our experience.

Alfa-Bank is part of a special working group created by the Central Bank with the aim of improving the quality of financial products for groups with visual impairments. A special methodology of work and evaluations has already been developed, which all banks adhere to.

And this is how we tested.

image

Users and Scenarios


First of all, we invited people with visual impairment (of different groups) to test.

The first group of visual disabilities is completely blind people who are forced to use special devices and software (screen readers, VoiceOver).

The second and third groups are visually impaired, which, depending on the disease, use such devices or successfully manage without them.

Yes, it is important to note that when you conduct any testing, the result of which will be the completion or even processing of the entire application or its individual functions, it will not hurt to convey its need to the business. Because it also costs, time, effort. Here it turns out such a story that, on the one hand, such actions for people with visual impairments are the social responsibility of the company, on the other hand, as statistics show, up to 30 percent of the country's population may experience temporary difficulties with vision in different situations, and this already impressive figure.

Therefore, we got together and sat down to test with them the four most popular scenarios for using Alpha Mobile. Here they are:

  • application authorization
  • balance check
  • view your accounts (history, status)
  • mobile account recharge

Of course, depending on a particular person, the scenarios can be different - someone often pays for the housing and communal services using a QR code, someone transfers money to relatives, but the most common are these four.

Test Methods and Tools


There is a special GOST R 52872-2012 , "Accessibility requirements for the visually impaired", which describes all the standards in sufficient detail. That is what we use, assigning each found error a corresponding label. In total, all problems found were divided into three categories.

Design problem. For example, at the entrance to the mobile bank, this is the usual window for everyone to enter the pin code, you do not have focus on the input field and the person does not say out loud how many attempts he has to enter the pin.

image

It was so with us. It sounds like a so-so problem, but this is a critical thing. If a person cannot hear whether he entered the pin correctly or not, how many attempts he has left, then he may well exceed this number of attempts. This means that the entrance to Alfa Mobile will be temporarily blocked with all the resulting inconvenience.

Code quality issue. This is when not all the elements you pronounce correctly. For example, in some places the navigation arrows can be voiced as “End of the table” and similar system pieces.

image

The problem of contrast. For example, here, even with normal vision, it is difficult to read the text. You must get rid of this and take this into account immediately.

image
"
There were four main steps in our work:

  • Gathered a group of testers (7 people) and regressed the application
  • Separated from dev-branches, analyzed problems and elements
  • They wrote them down on one plate, prioritized
  • Critical began to edit

Testing really helps Apple's approach to creating products. Firstly, it’s really convenient to test everything directly on the device, the Cupertinians have adapted everything cool.

Secondly, there is Xcode with its accessibility inspector, this utility shows a specific view of buttons and elements when you hover on the screen, you can quickly read everything and understand whether it will be correctly voiced. Actually, in our case, this was the main problem - signing buttons for VoiceOver.


We found defects by evaluating the functionality and convenience of a mobile application that people with vision problems use. Evaluation is carried out by testing the passage of all basic user scenarios.

The more basic user scenarios available to the client and the fewer barriers and difficulties identified during the passage of the script, the higher the rating.

The level of script availability is determined by the most critical issue.

  • critical receives a scenario in which a critical availability problem is detected that does not allow the task to be completed at all.
  • minor receives a scenario in which accessibility issues of medium criticality are detected when users experience significant difficulties in completing the task.
  • low receives a scenario in which low criticality availability problems are detected when users experience some difficulty in completing a task.

How to avoid accessibility defects?


First, use the UI Accessibility Element protocol.

Then you need to improve Voice Over (a special Makoshi function that helps a visually impaired user to work with voice commands and a keyboard):

  • Sign buttons.
  • Add values.
  • Leave a hint.
  • Group controls.
  • Correct the wrong inscriptions.
  • Indicate the type of control: button, inscription, link, etc.
  • Extend buttons or items if they are too narrow (minimum 44: 44)

Here's what else we recommend:

1. Buttons - .accessibilityLabel

Each button must be given a short and resonant name. VoiceOver will hedge, if you forget, it will try to read the text or the name of the icon on the button.

What you need to sign:

  • Buttons with an icon, but without text;
  • Images. If possible, it is better to sign what is shown in the picture.
  • A button and a picture without a label voices the name of the icon, as in Assets

image


2. Values ​​- .accessibilityValue In

addition to the name, you can write a value. For example, when entering the amount of money with textField, you need to sign the name of the account or digital ending, and also indicate the number of rubles.

image

3. Tips - .accessibilityHint

If we want to further clarify the action, we can write a hint in .accessibilityHint. But you shouldn’t rely heavily on prompts: constant explanations bother you, so some users turn them off via the phone’s settings.

The button is voiced as “To another bank”, for explanation, you can leave a hint, what type of transfer, how fast and so on.


4. Group controls - .accessibility

By default, each element is spoken separately. This is inconvenient: the pressure zones are reduced, you may not notice something, so you need to generalize.

Now the cell has several fields: card, money and name, 3 controls per cell. It is necessary to generalize that there was 1 cell and a name, so it turns out closer to the meaning.


How to fix it?

  1. Make the whole cell accessible control. By default, all views are only containers for other elements; VoiceOver ignores them. To mark view as a final element, you must set the cell isAccessibilityElement = true.
  2. Give the cell a name. You can no longer focus on the label, so you need to manually specify the text. accessibilityLabel = specialOffer.title

You can simplify:

  1. Make the whole cell accessible control. Set the cell isAccessibilityElement = true
  2. In accessibilityLabel, write the most important thing: the name of the card and account. Separated by a comma, VoiceOver takes punctuation into account.
  3. In accessibilityValue specify additional information, in our case this is what account, how much money.
  4. Indicate that the cell can be pressed, i.e. this is essentially a button. accessibilityTraits = .button


Total


The USABILITYLAB rankers gave us first place in terms of app availability. This does not mean that we are so cool and have closed all the problems in general, becoming an ideal application, no. But we are working on it, taking into account all the subtleties and features of working with people who have vision problems.

It’s also very cool that this story helped us attract such people - they often send us feedback, and a number of respondents now help to test Alfa Mobile on an ongoing basis.

We work further.

More articles:


All Articles