Don’t wait until the end of the design (or development!) process to think about accessibility issues. Accessibility is not just a buzzword. It’s not just a checkbox on your prepare for deployment list. It’s about making sure there are as few barriers as possible for all your users. And no, I’m not talking about capturing a few extra folks who might be sight or hearing impaired. I’m talking about the larger (and largely invisible) group of people who have various kinds of color blindness. I’m talking about making your app easy to use by people who are keeping track of kids while shopping for groceries, or students in a lecture, or people working in a poorly lit office or out in the sunshine at a soccer game.
Mobile devices are mobile and people take them everywhere. This is both a strength, because they tend to always have them available; and a weakness, because they take them into less than ideal situations and still expect to be able to use them. Accessibility features are for everyone, not just people you think of as being covered by (inadequate) ADA laws. And accessibility works best for everyone if it is part of the initial design decisions rather than being an after thought. Make it part of the design. Make it part of testing. If the team pushes back, come up with use cases for otherwise able people who would benefit. Can’t come up with an appropriate use case? Try harder.
Sometimes the pushback will come from the client. Be ready with your arguments. Implementing accessibility features up front tends to be cheaper (and more thorough and less likely to break things) than bolting it on at the end. You have to test accessibility features because, whether or not you intend them to be used, someone will eventually use them. Making sure accessibility features don’t break your app (even if your app doesn’t make full use of them) can save you losing that customer plus all the friends they tell about the problem. It’s cheaper to keep an existing user than to get new ones. Plus, it’s the right thing to do.