As a developer, you are considered the last line of defense between your application’s impact, and the end-user. Implementing and understanding best practices is a part of your job. If your code was knowingly unusable by 15% of your audience, would you or your leadership accept that? What if it meant boosting the application’s one billion a year revenue by one hundred fifty million?
I want to introduce myself and my journey into mobile accessibility. My name is Kim Arnett and I joined Deque in the summer of 2021 as the Native Mobile Team Lead. It meant a lot to me to transition my career into something that would have more meaning and a greater impact — such as ensuring your applications are accessible to everyone. My journey into iOS development came out of passion, finding what I enjoyed doing while earning my degree and interning. I truly enjoyed the Apple ecosystem, the products, the community, and enjoyed the challenges of mobile development. It took a few years into my career to even learn what accessibility was.
My first encounter was when a team lead brought in a switch control to work one day. He was building a talk on making Android apps accessible and gave me a quick intro to what mobile accessibility was about. From there – I started poking around the internet, but there wasn’t a whole lot of information out there. I learned about Deque and the work they were doing in the webspace, but as far as mobile went, it seemed like uncharted territory for the time. There were mentions of `accessiblityLabel`s, `accessibilityIdentifer`s for iOS.. some mentions of voice over, but those words meant nothing to me. As a few more years went by I eventually learned that `accessiblityLabel` was used on an element for the screen reader to speak to the end-user. I then learned that `accessibilityIdentifer` was mainly for navigating the hierarchy of a view for testing. That was about the extent of my knowledge, but I treated it like the source of truth for many years. Probably misusing it and creating more harm than good, but that leads me to my next adventure.
Eventually, I was fortunate enough to work on an application that shipped worldwide. Within the company was an accessibility team that would occasionally run audits on all our products and file bugs for production accessibility violations. I didn’t learn about them right away, but once a quarter tickets floated in our backlog around accessibility and I was intrigued. Through these bugs, I was able to find a channel where I could ask that team questions, I could learn more about how they came to the conclusion of the issue, and how I could help fix these issues going forward. It helped immensely with my understanding and helped paint a picture of a world that I had not truly been exposed to before. The “aha!” moment I had around mobile accessibility came on Global Accessibility Awareness Day (GAAD). A competition was held between team members (iOS and Android) of who could use their respective app, (keep in mind we’ve been building on this app, some of the team for years), blindfolded and achieve a certain set of goals that were identical for each person. It was a timed event, and I must admit the task itself was the main use case of our app. What I didn’t expect is how difficult it would be when relying on assistive technologies. Only a handful of developers were able to achieve all the milestones, but all of us came out of the experience with a “wow, we have to do better” attitude.
I really took that experience to heart – for every feature I built and shipped, I ran it through a screen reader to determine what the experience was like when relying on assistive technologies. When the extra time came up, I’d go back and fix other areas of the app my team owned to ensure each swipe was intentional, each element had the context necessary that anyone would be able to achieve what they were trying to do. Looking back and after getting more introspect into the accessibility world with Deque, did I have a clue what I was doing? No. No, I did not. However, I was on the right track, and anything I did made the experience better than the day before which was a win for each of our customers.
I’d like to challenge your team to try the same exercise listed above on your application. Can you get through the primary use case while relying on assistive technologies? Can you do it blindfolded or with headphones on? Can you do it with only touching a switch control? How difficult was it? Would you come back and do business with that app again? Were you even able to achieve what you were trying to do? Through an exercise like this, you’ll learn firsthand why you, a mobile developer, should care about accessibility in your application.
Thanks to Deque, our mobile team, a team of accessibility experts, and amazing tools – you don’t have to know everything about accessibility. You just have to care — we’re here to help you with the rest.