We navigate so much of the world through our mobile devices, and people who rely on assistive technologies to use their smartphones are no exception. Unfortunately, many app developers don’t have the best track record when it comes to building fully accessible apps. Maybe they lacked the know-how or the budget required cuts, but there are a lot of available apps that are difficult or impossible to use with assistive technologies such as screen readers.
At Detroit Labs, accessibility is baked into the development process on our new projects — we develop and test with screen readers and tabbing switches in mind whenever possible. But that hasn’t always been the case, so we’re circling back to retrofit many of our ongoing projects with accessibility features. That doesn’t sound easy, but it actually boils down to 1-2-3!
A group of Labbers dedicates their continuing education time to learning the Web Content Accessibility Guidelines (WCAG) 2.0 accessibility standards and the BBC Mobile Accessibility Guidelines so they can spot accessibility issues in the wild.
We gather test devices and a dozen Labbers with varying degrees of familiarity with accessibility features in a room and start tapping away at the app. We generate a pile of Post-its cataloging bugs and “nice-to-haves,” ranging from “this button isn’t accessible to the tabbing device” to “the screen reader mispronounces the name of the client’s flagship product.”
The QA engineer records the bugs and feature requests in our issue-tracking software and works with the team to set priorities. Often the issues can be resolved without a lot of extra effort — if a button is missing its screen reader label, for instance, a developer may be able to add that in the next time they’re “in the neighborhood” working on code for that feature.
What seems like a daunting task isn’t actually so scary once it’s broken down. And once you’ve made the commitment to building apps that are fully accessible from the first line of code, you never have to go through this process again!