Making Moovit Accessible for Blind Users — Part 1

Oct 17, 2017 update: There is now also part 2

Part 1 — How it all started

A few months ago Yair Bar On, co-founder of TestFairy, called me and invited me to participate in the first meeting of APPlicable, a program he started with good people from Beit Izi Shapira, Michal Waltner Levi from Campus TLV, and others. The program helps developers make their apps accessible for people with disabilities. The first meeting was with blind and visually impaired users.

I came to the meeting, and carefully observed how blind and visually impaired users interact with Moovit and other mobile apps and learned about the specific needs of these users. Back then, the accessibility capabilities of Moovit were not good enough. I was the first to admit that. But at that meeting I also promised to the entire audience that we are going to improve.

Here’s a short 1.5 min video summarizing the experience.

https://www.youtube.com/embed/H4lKp6nnsuQ

After I returned to the office we assembled a product and engineering task force (great job Orit, Nadav and Gilad !) that their mission was to greatly improve Moovit’s accessibility for blind users. We also teamed with Adi Kushnir, a 18 years old blind Moovit user who is also a mobile apps developer. Adi guided our team about VoiceOver for iOS / TalkBack for Android, pointed out what specifically needs to be made accessible and what’s less important, tested the implementation and validated that it was done right. When we felt that we were getting close to being ready, we recruited from our global community, blind users who speak more than 10 different languages and provided them with a beta version for testing.

Today, I am happy and proud to say “Mission accomplished”. Moovit v4.10 for Android and iPhone is live, and thanks to it, blind users all around the world, can be more independent and travel around their cities with confidence.

Part 2 — How to make your app accessible for blind users

If you are a developer and interested in making your app accessible to blind users, here are the key items you should look into:

A. Set correct swipe order — Think tab order in web design. When VoiceOver / TalkBack is on, moving between items on the screen is performed using left and right swipes. Making sure that the order of screen elements is set correctly is essential, starting from the top of the screen to its bottom.

B. Add accessibility labels to control (where currently missing) — Think “alt text” for images on a web page. When the focus is on a element or control (button, label), VoiceOver / TalkBack reads aloud the text that appears on it . But in many apps, developers use nicely designed buttons or universal icons (like a star icon for favorite, a trash icon for delete, etc.) which don’t include an accessibility label. In those cases the operating system sets a default value that VoiceOver/TalkBack reads to the user. The problem is that the default value is meaningless and confusing — for example “Button 543”. So it is important to ensure that every image/icon has a meaningful accessibility label blind users will know exactly what the control means and what it does.

It is also important to set accessibility label for an entire cell. Cells often include several pieces of disjoint information that when read aloud separately don’t provide the full context in a clear manner. Take a look for example at the top cell of the trip plan form of Moovit.

Without a cell specific accessibility label, VoiceOver / Talk back reads aloud each element separately. After the first swipe to the right and highlighting the origin text field, the operating systems reads “Your current location”. After the next swipe right, the operating system reads “Columbia Lighthouse For the Blind”. And after the third swipe right, it reads “Options” (assuming that the options icon was set with its own accessibility label). Overall, the three disjoints pieces of text were not clear enough, so we set an accessibility label for the entire cell that is read aloud by the operating system when the focus is on it (highlighted in green):

“From your current location to Columbia Lighthouse For the Blind, double tap to open trip options like time, transit types or route types”.

Another example is the cell that contains a route information. Instead of hearing the following info which will be based on individual cell’s elements:

“30 min, 11:19 AM, dash, 11:49 AM, 80, M, GR, 6, Leaves from…”

We set an accessibility label for the entire cell. We also omitted the specific elements inside the cell from the swipe order to ensure that swipes jump from cell to cell and skip the inner cell items (see #3 below):

“Route number 1: Bus line 80, then metro line green, then walk 6 minutes. Total time 30 minutes. From 11:19 AM to 11:49 AM. Leaves from North East 12th st & North East Crittenden St.”

C. Omit certain controls from the swipe order — certain elements or features are not essential for blind users, for instance the ability to report conditions for a station or line. By removing those elements from the swipe order we are hiding them and shortening the number of swipes users need in order to access the core features of the product.

D. Add Hints where necessary — Hints are accessibility labels on steroids. They provide additional context to screens or controls, that is read aloud only once, when entering a screen for the first time, or when pausing on a specific control for a few seconds.

For example, when user enters the Itinerary screen and swipes until the Live button (green Play button) and pauses for a few seconds, the following hint reads aloud: “Double tap to start Live Directions and receive arrival notifications”.

This is it in a nutshell. If you want more information about additional accessibility aspects, check out the excellent APPLicable guide.

Now go and test your app and fix what is not accessible yet. There are over 40M blind people in the world. Your changes are going to make great impact on third ability to be independent.