Accessible Design at Asana
It’s not hard to get designers to care about Accessibility. We’re motivated by making things easier for people to use, and we strive to ensure we’re solving the right problems for the people who will be using it. So, designers caring about Accessibility in the abstract is a given – we want what we’re designing to work for everyone.
The challenge with putting this into practice is that:
Most design processes are sighted-user-centric and assume that people are using a laptop and mouse or mobile device.
Accounting for accessibility considerations often requires making decisions about the underlying technical semantics.
In other words, we have to build new mental models of who we’re designing for and learn a whole new set of vocabulary to be able to articulate how something should work for assistive technology users. A big jump, to say the least, between wanting to do something and knowing how to do it.
At Asana, we’ve been working on closing this gap between caring about Accessibility in the abstract and designing for assistive technology users in practice. This work is ongoing, but in celebration of Global Accessibility Awareness Day last week, I’m excited to share four of my top learnings in incorporating accessibility into our design process.
1. UXR with assistive tech users
No surprise that actually watching someone use our product with a screen reader, voice navigation, or screen magnification software was the quickest way to understand how we can make something better. As a sighted laptop user, I could simulate that experience, but there is no substitute for watching and talking with an actual expert user.
User research with people who use assistive technologies day-to-day was the number one way that designers at Asana (and everyone, really) began to build a better understanding of what it looked like to build an accessible product. Leveraging Fable’s Engage platform, Abi Kelly, our accessibility user research lead, facilitated weekly research sessions to help us celebrate our progress and clearly highlight remaining work to be done.
2. One-on-one support
Accessibility training goes a long way in familiarizing concepts and introducing vocabulary, but as anyone who does accessibility work knows, there are very few straightforward answers. The work lies mostly in looking at specific scenarios, getting clear on what you’re trying to communicate, and then applying the best accessibility patterns you can find.
For that reason, though we built and love our accessibility design toolkit of annotation components, Figma plugins, and example specs, where I see the most learning and growth is when I can sit with designers one-on-one and come up with a solution together. Often the answer is complicated but the solution boils down to some simple annotations in their design spec.
3. Partnering with engineering
Demystifying WCAG requirements and their underlying aria-patterns is no easy feat – both require pretty technical reading. In the case of WCAG criteria, we designers have to dig in and read. Line by line. In the case of aria-patterns, digging in is also required, but you’ll go a lot faster and farther if you are able to pair with an engineering partner who is more familiar with the UI patterns being described and the code snippets referenced. Designers are experts in articulating an experience and engineers are experts in implementation, so the best case scenario is that you act as a team and craft the accessible spec together.
4. Meeting designers where they are
Designers have a lot of competing priorities and stakeholders, and at the end of the day if accessibility isn’t a requirement, it’s difficult for them to make time for it. To ensure it always remained top of mind, we made accessible specs a part of our design review process. This checkpoint to stop and make sure the experience proposed will work for people who use assistive technologies has been helpful.
As we have scaled accessibility across the company, it has been a privilege to witness my colleagues advocate tirelessly for the best quality experiences for assistive technology users. From the very top ranks of leadership to individual ICs, Asana has prioritized Accessibility. This has made our product work for everyone, so that everyone can do their best work.
I’m proud of the way our design team has built their skills in thinking about all users. It is no small feat to get to where we are today where designers are proactively asking in design critique: “how do we make sure this is clear for screen readers?” Friends in the Accessibility community know, this is progress!
Ultimately, our assistive users are the ones to evaluate how accessible our product is, and we promise to keep going in our journey.
About the author: Ainsley Wagoner is the Accessibility Design Lead at Asana. She spends her days working with designers and engineers to create accessible experiences for assistive technology users. Previously she worked at Adobe and Code for America.
