Brink approached Table XI with big dreams of building accessible software to empower voters. Founded by former “Hillary for America” campaign strategists, the Brink team wanted to guide all voters through the voting process — especially those with disabilities.
They knew from their presidential campaign experience that people with disabilities faced unique challenges to participating in the democratic process: traveling to their polling place, getting an accessible ballot, even being denied their vote. Brink also knew that many of their challenges, like registering to vote and finding the polling place, were universal.
By solving challenges for people with disabilities, Brink could solve challenges for everyone. Starting with a three-day Inception — our version of a project kickoff meeting — and moving into user research, the Brink team and Table XI were able to define the most important features, test a workable solution and launch a minimum viable product in less than four months. The resulting app makes democracy a little more accessible, and provides a new framework for app accessibility.
Valerie Frank, cofounder of Brink
The Brink team reviews potential features for the app in the product discovery phase.
Brink’s research had found that voters with disabilities had many different needs — and that sometimes accessibility solutions were in direct opposition with one another. People with Autism, for example, may prefer detailed written information, while people with Dyslexia prefer icons and visual cues. User research allowed us to find the features that made the app easier to use for the greatest number of people.
Some rough concepts from the initial ideation sessions.
By the 2018 midterm election, we launched iOS and Android apps that made voting information accessible to more Americans, generating great excitement in the disability community.
We also created a multi-year product roadmap — a series of plans to reach specific goals and milestones. With the Brink team, we’re planning to release several more major iterations before the 2020 presidential election. By helping Brink use research to realize big dreams, we were able to give voters more power immediately, and make a roadmap to make voting even more accessible and informed going forward.
Valerie Frank, cofounder of Brink
Brink understood how to make voting accessible for everyone, but to deliver on that promise, we had to determine how to translate those ideas into an app that was accessible for everyone. The good news is that there are a lot of resources out there on usability and accessibility standards … which is also the bad news, especially because many of them are full of wonky government or policy jargon. We needed to sort through all the available information just to learn what we didn’t know.
Our design team devotes enormous thought to making products that work seamlessly. We just needed to give them new information on how to help a wider audience.
Colors are a great example — normally designers pick a color to communicate a mood or a brand. If you’re colorblind, however, there’s a whole range of colors that are going to look the same to you. Designing for accessibility means thinking through which colors fall into the same range, causing a button to look the same as its background, for example.
Color contrast, iconography, text — all of these things have to work much harder when you can’t rely on all senses. Users who have a hard time reading often rely on icons to literally represent their meaning. Users who are visually impaired often use screen readers to “read” the software, meaning that all our text had to flow in a logical order, without relying on images to do the work.
Screens from the Brink app show how we used high contrast colors and icons to help with accessibility.
Fortunately, there are a lot of software accessibility tools out there to help. None of them, however, will magically make your app accessible. Instead, they help to identify the non-accessible features in the app, so you can improve it.
Brink also gave us an opportunity to work with other software accessibility tools to make sure our app worked with them. People who are visually impaired rely on screen readers to help them make sense of the internet. Some of them read the text out-loud, others send it to a device that presents the text in Braille. So all of our images and buttons and everything else must have text that tells the screen reader what they’re purpose is (normally referred to as “alt text”). Descriptions like “button” won’t help, but “click here to learn more about this candidate” will.
Part of making mobile apps accessible is making them available. That means including as much of the mobile market as you can. Supporting both iOS and Android can be an issue, however, because both platforms have their own accessibility guidelines, tooling and requirements.
We knew from the start that we were going to build the Brink app in React. We’ve gone all-in on learning React Native, precisely because it’s so perfect for building cross-platform apps. One codebase will produce native iOS and Android apps. It’s still not a two-for-one deal — you have to do plenty of tweaking to get each app to feel perfectly native — but it’s better than writing two sets of code.
React Native also has a great set of instructions on how to make applications accessible, and it’s already working on solutions to take care of some of the discrepancies between iOS and Android. We were able to rely on those guides while we created the Brink app, and now we’ll be able to rely on our experiences to build accessible cross-platform apps going forward.
More informational screens from the Brink app.
We test everything we build, but when trying to reach a user base with experiences we can’t always understand, it takes an elevated focus.
Finding users to test with is always a challenge. Fortunately, there are a lot of people who were interested in seeing this project be successful. The Brink team helped connect us with several organizations supporting people with disabilities, all of whom offered to test the application on their own time.
We started by putting the application through its paces using all the available accessibility testing guidelines and software we could find — plus our own tests with screen readers and other accessibility tools. Once we had it in the best state we could get it on our own, we invited in our testers. Their feedback opened our eyes to all the little ways technology can make life easier — or harder. With their help, we were able to take the application further, making it more useful for more people.
It’s already become so much easier to make accessible software, but it’s still not easy. There are a lot of hurdles, any of which can serve as an excuse for not doing something that a lot of people would benefit from.
We hope to help take down some of those barriers, and we also hope all of the tools mentioned here will keep pushing to get better.
We want accessible software to be the rule, not the exception. And the more we work it into our process and make it easier for everyone, the quicker that will happen.
If you have questions about how to make your software accessible contact us today!