Overview
iTaxi is a platform that connects users and licensed cab drivers (like FreeNow, Lyft, Uber, or Bolt) in major cities in Poland. We launched in 2013 and redesigned the app in early 2018.
The work on our app has been driven by the simple fact that accessibility is not a trivial problem. According to the World Health Organisation, globally there were 2.2 billion visually impaired or blind people (October 2018). Despite these numbers, the accessibility of digital content still has a long way to go. There have been some positive moves in recent times, in part driven by legal requirements, and big tech companies now have accessibility officers and accessibility teams. However, digital content is generally not designed and coded upfront so that people with disabilities can use it.
The Approach
We started work on improving the accessibility of the iTaxi app in the middle of 2018. We aimed to make both iOS and Android versions of the app simple and convenient for the blind and visually impaired to use. It was a big decision for us. We knew the upgrade would only be noticed by a small, but demanding, group of users who would also be sensitive to any software glitches. We also knew that the cost of such work would be hard to estimate.
The iTaxi app
We studied the Web Content Accessibility Guidelines, WCAG 2.1. These are official rules and guidelines for developing useful and accessible internet services, and they contain specific information with examples of implementation. They are technical documents but not connected with any particular technology. We also examined the available standards of good practice.
We also analyzed our product. We checked its structure and the user experience from the perspective of a person without any visual disability. Then we started to think about how to simplify the ride-hailing process so that it could be managed by a blind or visually impaired person. To do this we had to learn an entirely new approach to designing mobile apps.
Making iTaxi Accessible
We optimistically set out to dedicate one sprint (over two weeks) for the actual work, but soon realized that the modifications were harder to achieve than we had assumed. We devoted the whole summer of 2018 to modifying the iOS version of the app. The one sprint for the accessibility modification extended into two. Since the workload was distributed, we fitted our accessibility-related tasks in between other fixes.
Having developed this first version, we then tested our work with a professional blind tester. The experience gathered during this process was enormous and the list of necessary changes was much longer than we expected. At the end of 2018, we started work on the Android app. We assumed that the knowledge drawn from our work on accessibility for the iOS app would make the work on the Android version easier, but this was only partly true. The operating systems and their corresponding assistive functions are subtly different and require an individual approach. However, we managed to modify the Android app in approximately two sprints and gave it to the next blind tester.
Working With Testers
Our work on improvements was more effective when we understood how the blind and visually impaired used the product. The rules and guidelines helped, but only when we had a deep understanding of the user’s perspective, so the work with testers was invaluable.
That is why, in 2019, we decided to ask for help from accessibility foundations and organizations. We invited testers from the Widzialni (Polish: Visible) Foundation, FIRR (Institute for Regional Development Foundation), and the Polish Association of the Blind. The testers started work on both apps – although we were aware that the iOS version was better developed. To no one’s surprise, the tests produced another list of comments and required fixes. We noticed, however, that each tester approached testing in a different way, describing what was particularly convenient for them.
We analyzed the testers’ comments and selected modifications which would benefit most users. We’re not going to implement all proposed modifications, as some of them would change our business model. Below are some examples of the work we’ve undertaken:
UX improvements
We looked at the logic of navigation and checked that the app’s behavior was predictable so that the user shouldn’t be surprised by what was happening at every step. We also identified a problem and found a solution which benefited both the blind and those without visual impairment. We found we had one step that surprised users because they didn’t know if it was the final step to hailing a taxi, or if there was an option to provide additional data about the ride. Users without visual impairment managed this screen well enough, but we found it was a very important obstacle when testing the app with blind people.
Labelling
Our labels were too descriptive. It was the blind testers using assistive technologies every day in a natural and dynamic way who pointed out our mistake. It transpired that simple but logically connected labels giving the user listening to the speech description a clear sense of what will happen on the screen are quite sufficient. And all text with information on what is happening on the screen should be as simple as possible. In other words, the info should be succinct and self-explanatory.
Contrast and colors
Accessibility concerns not only the blind but also those with, for instance, color blindness. Websites or apps where the contrast between the background and the text is too low or the colors are mismatched become effectively inaccessible for the color blind.
As for contrast, the ideal value of background to content ratio is 4:5:1. Although it may sound complicated, it becomes much clearer when you start using contrast tools. In the case of the iTaxi app, the main problem was the use of yellow in the app’s graphics (taken from our company logo). During the tests, it came out that although yellow matched very well with the black background, there was a huge problem when it was projected against white. It stopped being readable for the visually impaired. It took only a few trials to modify the shade of yellow so that it matched well with buttons and both black and white backgrounds. We plan to continue our work on accessibility this year.
Other Tips and Tricks
The most crucial element in designing for accessibility is an understanding of the end-user’s perspective. We had to learn how the blind or visually impaired use our application, and we were quite surprised by how fast they managed it with assistive technologies. We had assumed that the more descriptive the application was, the easier it would be to use by those less able to see. We thought that these people use the app studiously, carefully going from one element to another. How wrong we were! A blind person can hail a taxi almost instantaneously, provided that the app – meaning us, the designers, developers, managers – doesn’t stop them from doing so.
During testing, we discovered that blind users find things that other users don’t notice. If someone without any visual impairment tries to test the app by blacking out the screen and turning on assistive functions, it will only be partially effective. This is because the visually impaired move their fingers differently on a screen. The best testers are those who naturally use assistive technologies daily.
Native assistive technology is often forgotten. Read-out-loud functions are native to iOS and Android systems. They are part of their assistive technology suites and are easy to activate. Developers should remember that such functionality is already there and make sure that their products work logically and conveniently not only on the visual but also auditory level.
Conclusions
Accessibility is about considering all users. It means that as a product manager, designer, or developer, you have to include those users with disabilities, or the elderly, or those who are less than fluent in the local language. It is really worth remembering that even a small improvement made for the minority is still beneficial for most users as it generally improves the ease of use of a website or an app for every user.
It was only when we started work on improving the accessibility of our app that we realized how much work there was – and still is ahead of us. On the other hand, we draw much satisfaction from knowing that visually impaired and blind people have more freedom when moving around a city. They can hail the taxi on their own and feel secure. So little, yet so much.
The full article was published on mindtheproduct.com, you can find it HERE.
With thanks to Joanna Heluszka, Junior Android Developer at iTaxi, Marcin Makowski, Senior iOS Developer at iTaxi, Ewa Janik, Junior Tester at iTaxi, and Sylwia Okraska, Senior Tester at iTaxi, for their contributions to this project.
Key | Value |
---|---|
Title | Improving the Accessibility of the iTaxi Mobile App: a Case Study |
Author | Małecka, Katarzyna |
Publisher | Mind the Product |
Year | 2020 |
Link | https://www.mindtheproduct.com/improving-accessibility-of-the-itaxi-mobile-app-a-case-study/ |