Developing for accessibility is basically keeping in mind that the end user is an actual human being that might or might not have limitations, disabilities, impairments and so on.
I first started developing for accessibility when I joined the Lynda.com team and later I dug deeper into the concept while working on the LinkedIn Learning Android app. I very quickly realised that most of us are using the wrong definition of accessibility — and yes, that was true for me too. We tend to think that accessibility only addresses the problems that visually impaired people face. Although concentrating on accessibility does help this group of people, the idea actually includes a wider range of people with other limitations:
- Visual, auditory, physical, speech, cognitive and neurological disabilities
- Age-related impairments
- Low literacy or lack of fluency in a language
- Low bandwidth connections or the use of older technologies
- New or infrequent users
- Temporary disabilities (e.g. injuries or illness…)
What I also learned from that experience is that accessibility shouldn’t be treated as a “nice to have” for a later step. Nor should it be excluded from a MVP feature set. The sooner you think about accessibility issues, the easier it gets.
So what do I need to look for in order to make my app more accessible?
Curious about accessibility? Continue reading on parkside-interactive.com.