When it comes to the accessible user experience design, very often, the approach is limited to basics. I mean to all the experience that is possible when, as a user, you can see. I find it very sad that there is not a lot of help in articles, documentation, and descriptions of best practices when it comes to blind users of technology.

This is why I decided to describe the project I started together with a passionate team of developers and testers. We aimed to improve the accessibility of our main product: the mobile application for passengers, which enables users to hail a taxi. The primary purpose was to improve the accessibility of the app in a way that blind and visually impaired people could use it safely and comfortably. Thanks to that, we hoped these people would feel freer to travel around the cities, where our service was present.

The beginning of the process

We started with the analysis of our app. We looked at the logic of navigation. We checked if the behavior of the application was predictable. We wanted to know if the user was in any way surprised by what was happening with every step. We did it in both directions: we checked it by ourselves (so it was kind of biased by our knowledge of the product). We also asked blind tester to do it all together with us. The second way was more efficient. And more painful, as we discovered how much work is ahead.

Our discoveries (and a lot of work scheduled)

First of all, there was a problem with the focus. We decided to improve it, making sure that the elements have clear borders when they are active. What is more, we identified a quite interesting problem. Having that, we found a solution that benefited both the blind and those without visual impairment. This was the button that informed the user to move to the next step from the start screen. The design was that among many pleasant taxi animations on the map, there was an “Order” button. This created a situation when the users were surprised, because they didn’t know if it was the final step ending in hailing a taxi, or there would be an option to provide additional data regarding the ride (destination address, for example). Users without visual impairment managed this screen well enough, so we weren’t mainly motivated to introduce any changes. When testing the app with the blind persons, however, this became a significant obstacle. So, we went further and changed it ASAP.

Another thing that is worth paying attention to is labeling. By that, I mean descriptions of particular elements in the app. It appeared that we started this process all wrong. Our labels were, in fact, too descriptive. It was the blind testers using assistive technologies every day naturally and dynamically that pointed out our mistake. It came out that simple but logically connected labels giving the user listening to the speech description a clear sense of what is going to happen on the screen once something is activated are quite sufficient.

All texts with information on what is happening on the screen should be as simple as possible. In other words, the info should be succinct and, therefore, self-explanatory. It is important to remember that if there is a button, there is no need to add a description for it because assistive technology is going to do it on the system level. Clarity and simplicity are, therefore, paramount. For me, as a UX designer, it was quite new information, and now I pay more attention to it while designing new wireframes and flows.

In the case of labels, it is always useful to refer to WCAG 2.1 documentation. Apple has also announced that it will put more focus on the issue of accessibility. During the verification process, it will be one of the criteria for positive evaluation and subsequent addition to the App Store. This announcement resulted in a proliferation of various guides on how to, for example, correctly label elements in an app. It is always a good idea to refer to official literature on the subject.

Next important point: contrast and colors. The issue of accessibility concerns not only the blind but also those with, for instance, color blindness. This renders websites or apps where the contrast between the background and the text is too low, or the colors are mismatched effectively inaccessible for the colorblind persons.

In the case of contrast, the ideal value of background to content ratio is 4:5:1. In the case of larger content, the ratio could be 3:1. Although it may sound complicated, it becomes much clearer when you start using contrast tools.

In the case of our app, the main problem was the use of yellow color in the app’s graphics (as derived from the company logo). During the tests, it came out that although the yellow color matched very well with the black background, there was a huge problem when it was projected against white color. What happened was that it suddenly stopped being readable for the visually impaired persons. It took only a few trials to modify the shade of yellow (slightly different from the logo pattern, but still similar), which matched very well with buttons and both black and white backgrounds. We were planning to implement this together with other accessibility fixes.

What can you use to test the accessibility of your product in terms of contrast? In the case of this app, I employed three tools: Color Contrast Analyzer (Chrome plugin), Colorable, and Contrast-Ratio (as seen above). Unfortunately, there is no official tool for testing contrast, so to evaluate if a given website or app is accessible, you need to use third-party software prepared by companies or even written by individual programmers. This means that it is difficult to achieve certainty that your application was developed correctly. It is a rare moment to reach out and gain insights from the testers.

It is also important to remember that if there are so many people struggling with color recognition, it might be essential to check if your application uses color as the only way to mark actionable elements and/or information. This concerns graphs, graph descriptions, action buttons (YES/NO, ACCEPT/CANCEL). When developing your product, you should make sure that besides color, there are additional symbols or descriptions of what a given graph or button represents. A simple trick on how to check your graphic design for color accessibility is to print the screen in the gray color scale. You will instantly see if the information or buttons are readable. Of course, this does not mean that you should stay away from professional tools, but sometimes simple solutions such as gray color printing work best.

Last but not least, tests. While my work on this app, I rediscovered the importance of user tests. Properly conducted research with end-user is very helpful, even if sometimes the feedback is quite painful :). It is vital to watch and listen to your product users. Then it is possible to prepare improvements that will meet users’ needs.

The described app is iTaxi mobile application for passengers, that enables to order taxis.

Photo by Oscar Keys on Unsplash.