Our Accessibility Audit is Neverending — And Maybe Yours Should Be, Too
by Tiffany Hale, Product Designer @ Resilia. For the design team at Resilia, accessibility started as an audit and grew into much more.
Spend any time with the design leads at your company, and you’ll hear them wax poetic about accessibility. Typically, that word evokes the stilted cadence of screen readers narrating or the decimal ratios of color contrast checkers. For end users, however, accessibility means so much more — access to vital tools and resources lie behind the whims of product and development teams across the web.
At Resilia, it was important that our growth be met with mindful reflection. As I joined the design team, we kicked off an accessibility audit. We aligned on acceptance criteria, kicked off, and…quickly realized accessibility is much more than an audit. It’s an iterative process that also broadcasts the values of your organization.
From Audit to Airtable
To begin, we started with an audit. Birdsong, our design system, is maturing as is our organization, and it was a great time for us to reflect. Were our component standards accessible? Did we live up to WCAG standards? Did we live up to our own standards of inclusivity?
To prepare, I leveraged the dynamic reference-ability of Airtable. Already a techie favorite, Airtable was a perfect platform to operationalize our acceptance criteria. While one table prioritized each of the WCAG standards according to , the other housed a template for each component. For any issues identified, I outlined the exact WCAG standard to follow, added the priority, and put it into a grouped task list for us to complete.
We did a lot of ramp up for the audit…and it was kind of underwhelming. In building out our design system, founding designer and Director of Design Brett Grau aimed for AA compliance with our design components and she succeeded! Our audit generated fewer than 10 minor updates to the applicable components in the system. Which was excellent! But…now what? When you get the green light to focus on accessibility, how do you capitalize on momentum?
After determining that accessibility in our design system was built in, my product designer and systems thinking self made my next question natural: is it built into our processes, too? If our system supports accessibility by default, do we also support everyone in becoming a champion of accessibility? And so we hit our first point of iteration.
We had work to do! This iterative perspective turned a glowing audit into an opportunity to teach accessibility with our stakeholders. First, we worked creating and updating a Guru Card on accessibility. Guru is already our team’s knowledge management platform. We wanted to be sure to bring accessibility into the fold of existing processes so it naturally becomes a part of our everyday processes.
If You See Something, Say Something
At the bottom of the educational card, we cross-linked to a template in Shortcut. Our team uses Shortcut to manage workflows and collaborate across teams. In the tool, you can create templates for new ticket types. When I joined as a new team member months ago, it it was helpful that I never started from scratch when creating new components or reporting tech debt. When it comes to accessibility, the team wanted to make it just as simple!
Initially, I created an accessibility ticket template for designers, which was limited in its usefulness. Sure, it’s great if we have a template to self-report issues; however, we can’t be everywhere at once. Of our entire organization, few people could confidently fill in which “WCAG guideline” was at stake. More than that, accessibility is an effort that every member of an organization can champion.
With smaller teams, it’s important to create processes that allow everyone to support an initiative. Rebecca, another product designer at Resilia, highlighted that this approach not only helped everyone get involved — it also created an opportunity for ongoing education. If we’re asking that accessibility is everyone’s job, like all orgs should, we should set everyone up for success. In this case, this meant keeping the required data in the template to a minimum. We ask two mandatory questions:
- Where in the application did you experience the issue?
- How do I replicate the issue?
By keeping the questions simple, we give our colleagues a simple outline to describe issues to us. Furthermore, a shorter form increases the likelihood that other team members will use it. As we know, in any user experience, it’s best not to exhaust your user before they complete their task.
It Was Never a Phase — It’s a Lifestyle
With the audit results in, and our stakeholders’ eyes open, we were poised for success right? Wrong! Although our approach to accessibility was comprehensive, it was also fully reactive. In auditing existing components and reporting existing problems, by definition Resilia would have delivered inaccessible products to its users. And this didn’t align with our commitment to accessibility as a practice.
So how do we address the root cause?
I leaned on the insight of my fellow design team members in this discussion. We’d all tried different strategies for managing quality assurance and hunting bugs. But it became clear that unless we addressed accessibility as part of the build process, we’d always be a step behind. This realization harmonized wonderfully with a dual-prong proof of concept within our larger team…
Our design team was already invested in Zeroheight as a design system tool, and our exploratory team research focused on understanding how to maximize its usefulness within Resilia R&D. Simultaneously, our engineering partners were evaluating Storybook, a component library tool, as a way to share common components.
The synchronicity worked wonders for advancing accessibility! As I sat in on engineering calls, I learned about the robust features of Storybook. Likewise, I continually shared Zeroheight and even included a live component for an end-to-end demonstration of the potential use for both the systems.
In this collaboration, it became clear that our R&D partners were not only interested in accessibility, but also adamant about including it in their processes too! Jared, one of the newer engineers, highlighted an amazing feature that automated some syntax-based accessibility checks. This awesome value add was bidirectional. Priceless input from our development team made it clear our system needed to include more than an accessibility section. When appropriate, components also include specialized accessibility notes and links to WCAG guides. This way, even a quick reference to Birdsong always includes accessibility as a native consideration — not an afterthought.
In many ways, accessibility is a final frontier of the internet. Not in its existence — ever since the Gutenberg press, the need for accessibility has been present. The final frontier is creating accessibility as a fundamental assumption in our product development process.
When our audit grew beyond a simple evaluation, the shift represented a strategy decision, too. Resilia’s commitment to providing accessible experiences reflects our organization’s larger commitment to powering the people who change the world. When we design for accessibility from inception, it guarantees compliance. However, more importantly than that, it guarantees equitable access to the innovations we work hard to provide every day.
