Gird your app with Accessibility: How to Text-to-Speech
Working as a business analyst for a mobile banking application with more than 8 million users, I was mostly occupied with more ‘valuable’ features which are the most ‘gamechanger’ , ‘block buster’ or ‘smash hit’.
Between all these fancy work, we were not aware of the fact that our application does not function properly for a considerable amount of our users who are people with visual impairments. We were crazy about presenting a perfect loading animation but removing ‘show-stoppers’ for accessibility was not in our plan.
If you don’t have any relatives or friends with disabilities around you, it is easier to ignore what they need and becomes hard to realize that your app might not be as accessible as it should be.
What made us hit the wall was some comments in the store which was hard to identify among lots of positive user reviews. There were two realizations:
- A considerable amount of our audience are visually impaired and are using the app for their daily banking transactions
- Our application creates a great value but fails to provide the exact same value for all the users
After getting the fire, we planned an intervention for our 15 year old mobile application.
Since we were not accessibility experts and none of our developers has the required experience of implementing text-to-speech abilities (both of these reasons can make you give up at that moment), it should be done step by step.
Do not expect a miracle when complying all accessibility standards at your first attempt, use the power of small steps and continuous improvements with ITERATIONS.
For each iteration, our main purpose was looking at the output from the previous one, determining required implementations, doing the development and testing accordingly. So, we split all iterations into three major phases: Analyze, Develop, Test (as it is in all Software Development Methodologies).
1st Iteration (Find out what you have — and what you need)
Analyze: First of all, test your existing iOS and Android applications to understand which features and flows are the most annoying in accessibility mode. Results were not good in our side (not horrible though). Some perfectly fine features, especially the ones which are highly-customized and which we spent enormous amounts of time to make them work properly, seemed pathetic when screen-reading is active.
Lessons learned for a better “How-is-my-little-app” evaluation:
- Use screen darkening functions or dimmed displays to test in a useful way and give a completion score to each flow that you try to execute without seeing the screen.
=> If you are totally blocked and there is no way to go — This is pretty bad.
=> If you are doing it wrong and you are not aware (e.g. sending money to a someone else than the one you actually want to) — This is nightmare.
=> If you are slower than you normally are, but reached to the happy end at least. — This is acceptable, remember that disabled people are three times smarter and faster than you in that.
- Conduct a quick exploration for native functionalities of mobile systems, check for accessibility developer guides in iOS and Android. With that information, you will start creating the initial version of acceptance criteria which can be a proper guide for your developers for the first iteration. Do not be the hero through changing your app to give a detailed and informative direction for your disabled users. Just use the default functions provided by the creators of the system that you are building on which is the most sustainable way here.
- Try to maintain the state where your goal is the most functional solution. Put your Analysis-Paralysis to rest (this is just the first iteration, please leave something to fix later). If your app has lots of custom views or layers, it might be really hard (almost impossible) to create an excellent screen-reading experience. Acknowledge that and plan your time for more applicable improvements.
Develop: After getting the initial requirements, you can start developing your first packages to internal test. While doing this, developers will also find out new constraints, blockers and opportunities which were not visible in analysis phase and they will come along with the useful ideas to solve them.
Test: When new packages are ready, test them with your team and identify issues and improvement areas as an output of the first iteration and a direction for the next iteration.
- Do not forget to test your application in non-accessible mode. Since your app is being used every day by your loyal audience (our application was used by thousands of daily active users, so we needed to be really careful even when changing a sentence), you don’t have the privilege to destroy any existing experience.
2nd Iteration (Enhancements for your pre-determined requirements and tests to see your accessibility level in real life)
Analyze: Well, it is clear that you have loads of learnings coming from the first iteration. Start updating your acceptance criteria through cutting the inapplicable native functions (it does not mean it will work all the time since it is written on a development guideline) and applicable but time-consuming requirements which do not have a remarkable impact on the user journey. If an implementation will take four days to change the reading order for an input field, just use this time to improve the walkthrough process which cannot be skipped and is blocking the user.
Develop: Since user stories are updated and prior issues are identified, a new package can be prepared to present itself in front of an end-user. If you think there are still some enhancements needed which seems to be difficult and requires much time, let them stay for the user test to see how they work in real world. Maybe you exaggerated a little since you want the best for your application.
Test: If possible, find a continuous connection with a disabled user for accessibility testing. You will be unexpectedly affected when you see that you are touching their lives with your product which makes every screen in your app more important than ever.
If there is no option for this, you still have your store reviews. You can go one step further and implement a feedback area where your users can send their detailed comments to you (if you are lucky this can be the way that you find that connection). On the other hand, you can leave this task to the professionals through working with accessibility testing companies or let your quality assurance team become proficient in this area.
Here, we were pretty fortunate since we had the chance to test our app with a disabled user who was using it for all his regular banking transactions.
What did we see:
- Everything counts far more than you think. If there is a blocker in the experience (in our case a fancy coach-mark pops up when user logs in and it cannot be closed in accessible mode which prevents the user from moving forward), its impact is bigger since it means user cannot use any of the post-login features because of a non-closable message. Thankfully, the same goes for the reverse too. An accelerator which makes the flow smoother like an auto tab to next input field will be way more appreciated by text-to-speech users.
- They know what they need to do and how they can find it. In some screens that you are struggling with screen-reading mode, they will continue easier and faster which they can complete four more flows than you in the same time. (That’s why leaving some things to this step makes sense!)
- Do not try to differentiate the existing experience to be accessible. There is no need for grandiloquent words and long sentences to direct them through the flow. This is not a literature contest that you can work your magic on. Please be minimal, stick to the existing texts and do not add any words if they are not really necessary (which is mostly the case when there is an image which needed to be vocalized).
3rd Iteration (Last check before landing)
Analyze: Now you know how your app is being used in accessibility mode and which parts are failed or succeeded. Triage your feedbacks coming from the previous test, prioritize the applicable ones and start finalizing your acceptance criteria.
Keep in mind:
- Give priority to the improvements which are the most effective and necessary ones (now you are able to make that evaluation). It is always better that all your flows (sign up, login, menu, settings etc.) working adequately than having one flow acts perfect and leaving others poor. Try to manage your perfectionism, be fair and reasonable for every function in your app. You don’t want to spend much of your time thinking of a detailed introduction for your account selection field rather than adding a valuable feature.
- If there are still some screen-reading problems, at least understand their root causes and why you are not able to solve them. They can occur because of a really customized feature (e.g. a good-looking carousel) that you have developed without thinking how it is going to be read. If you are aware of that error and know why you are failing to remove it, this information will guide you when developing new features in a more accessible way. Even sometimes there might be some bugs in accessibility mode of an operating system or a mobile device that your app is working on (Believe me, we mailed to Google for some interesting pronunciations that we heard).
Develop: If you had executed your user test with all your team, you would have been one step ahead. With being aware of how an improvement will affect the life of your disabled users, everyone will work with heart and soul. Since they get the chance to see all those pain points, they will come up with handy solutions to create more value for their audience.
Test: It is time for an extensive test, which you didn’t have before since your requirements weren’t finished. Start applying your tests on your elaborate package before launching your product to the store. I hope you didn’t break anything when you were trying to be accessible, even if you did, you are capable of finding the best solution after all these iterations.
Package Released!
Remember that the important thing here is sustainability. If you add a new feature, which ruins the accessibility of itself and some other functions, all your work will be in the dumps and negative reviews will start again.
