Building accessible products for everyone
What is it like to use the web without a mouse? Imagine navigating your inbox with a screen reader, like many legally blind do. These and other questions about impairments are a daily part of how we understand user needs in Pivotal’s Washington D.C. offices.
By law, most US federal agencies — civilian, defense, or intelligence — must build software that meets 508 compliance standards. These stipulate that software must be useable for those who access the web through assistive technologies such as screen readers, voice-to-speech controls, and screen magnifiers, or who have specific vision or mobility needs. A full 100% of our current clients in Washington D.C. are government institutions, so 508 compliance has significantly influenced our teams and their expertise.
Here are five principles you can take away now for projects with 508 or similar accessibility requirements:
1) Start with the basics
We’ve found it best for the entire team to get a crash course on basic principles and best practices upfront. Check out 7 things every designer should know about accessibility, and Invision’s blog post on web accessibility, for starters. 18F’s accessibility guide and Vox’s product accessibility guide are good additional resources.
2) Understand what “done” looks like
Most government institutions have existing processes to ensure that 508 standards are met before an application goes into production, though they are often vague and confusing. Does someone test the app? To what standards (WCAG, AA, AAA)? Are they able to be part of the process of identifying what success looks like? Can they delegate someone who is? Often, 508 compliance is a waterfall process that tests compliance at the end of a large cycle; in understanding how this currently works, we often find committed volunteers who are eager to make it more iterative.
3) Identify targets upfront
Which browsers, assistive technologies, and devices are you using for acceptance? JAWS, VoiceOver, and NVDA are the most popular screen readers, and their behavior can vary significantly depending on their version and the version of the browser they are used with. Agreeing on which browsers, assistive technologies, and versions you are using for acceptance upfront saves time and energy squashing strange behavior later. It is also worth noting that it’s virtually impossible to understand which screen readers your users use, as they leave no trace in browser analytics. You’ll likely need to make an educated guess.
4) Bake 508 into practices early
The longer you wait to bake in 508 criteria into your user stories and design process, the more rework you’ll do. If you embrace 508 as a constraint upfront and modify processes to ensure that a user leveraging an assistive technology is treated as a first-class citizen, you will save a lot of frustration for your team and client (we’ve learned this the hard way). This likely entails user stories that include accessibility criteria, and accessibility tests in your test suite (tools such as Pa11y can help with this).
If possible, have the agreed upon assistive technologies installed on everyone’s machines for faster feedback loops. Otherwise, developers must deploy before testing, which adds time.
5) Bring in an expert
We find that a 508 subject expert is needed full-time during discovery and the first few weeks of writing user stories, with that commitment decreasing quickly as the team ramps up. We’ve evolved to point where we bake the acceptance criteria for an unsighted user (screen reader), a low vision user (zoomtext), and low-mobility user (voice-to-navigate technology) directly into our user stories. While this adds scope at first and can be a steep learning curve, it saves a ton of rework later on.
At Pivotal we are constantly teaching, learning, and adapting our processes to meet new constraints. This is especially true for 508 compliance, which has broadened our empathy and understanding of digital user access needs, and stretched us to adapt a traditionally waterfall process into a lean, agile, user-centered, and iterative lifecycle. We look forward to continuing to share out our best practices as we learn; Pivots in our DC office have given talks on the basics of 508, created starting guides, and we are constantly sharing resources on our Slack #accessibility channel.
If you have any resources you turn to for building accessible products, best practices, or great examples of an accessible product, please tell us in a response to this post.
Special thanks to Laurel Gray and Adam Bray who helped with this post.
✹
This article is part of Built to Adapt, a publication by Pivotal that shares stories and insights on how software is changing the way businesses are built.
Equal Opportunity Product Development was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
