Paying down our accessibility debt
In April 2020, Quip put together a dedicated team to tackle the accessibility challenges that had slowly accumulated throughout our development as a product.
Getting the team staffed was an exciting win, but it was just the beginning of a daunting amount of work. There were frustrated users who had lost trust in us, a dizzying spreadsheet of violations from our latest accessibility audit, and a technical challenge so big we didn’t even know where to start: screen reader users couldn’t navigate our rich, multiplayer web-based document and spreadsheet editors, and we didn’t really know why.
Oh, and did I mention we were all relatively or entirely new to accessibility work?
Just 2 years later, it feels astonishing to look back on the progress we’ve made. Some highlights include:
- Making Quip documents read out properly for screen reader users, even while editing, and even with the wide array of rich components we support in a document—user mentions! Embedded spreadsheets! Checkboxes!
- Revamping many parts of the Quip interface to make it much more efficient to navigate with a keyboard
- Improving keyboard navigation, and enabling intuitive navigation and reading for screen reader users for Quip’s spreadsheets
- Making all of Quip much more responsive to zoom and small viewports
- Enabling users to use dark mode, increased contrast, the OpenDyslexic font, alt text, and (soon) disabled animations and underlined links
- Creating a single, regularly-updated documentation page.
In the following weeks, we’ll share some technical deep dives about how we exactly accomplished some of these wins. But in this first post, I (as the PM on the team) want to focus on how we set ourselves up to do the work.
In the early, overwhelming days of the team, it quickly became clear that the “accessibility 101” tips were not geared towards a rich web application with dynamic, user-generated content. We needed to communicate to all our stakeholders—leadership, customers, and our teammates alike—that making Quip accessible would require a major, highly technical renovation, not just a new coat of paint. To prepare ourselves to do this work in a way that felt resilient and cumulative long-term, we invested in three approaches.
Defending against regressions
Bailing out a boat while it’s still leaking is terrible for both sustained progress and morale, so setting up lightweight processes to stave off major regressions was critical for not burning out.
Before the team was even formed, Quip PM and internal advocate Rachel Keeler had instituted the practice of requiring accessibility reviews for all outgoing features. We continued and expanded the process, with the goal of holding the accessibility floor (as in, not making things worse) and gathering information about common accessibility issues teams were running into that we could then address at the component level. At Quip, these reviews are live sessions hosted by the Accessibility PM, and attended by the engineer, PM, and/or designer responsible for the feature 2 weeks or more before release. Holding these sessions live may seem like a major time sink, but I believe they saved time overall: it meant that I (as the reviewer) didn’t have to spend time beforehand learning the feature, and that the feature team got more exposure to how keyboard navigation and screen readers worked and gradually improved their own comfort with testing.
We also implemented an overeager alert system: anytime code is pushed with a change including an accessibility-related keyword (for example, anything containing aria-), an engineer on our team is automatically assigned to review it in Slack. 90% of the time, these alerts are dismissed after a quick review reveals nothing alarming; however, they are critical for allowing us to catch mistaken usage of ARIA attributes or subtle regressions as soon as possible in the development workflow.
Where we could, we also set up automated checks that warn other developers against common bad practices, and pointed them at documentation about how to fix it. Combined with the keyword-based alert system, this optimizes out repeated conversations about things like hardcoding hex colors or creating interactive elements which aren’t tab-navigable; developers get feedback either within seconds (linters hooked into their preferred text editor/IDE) or when they try to commit or merge a branch (pre-commit checks/CI).
Making a11y allies
No matter how talented our engineers are, there’s just no way to make something as complex as Quip accessible without the ongoing support and buy-in of the rest of the organization. We decided to take on implementing Dark Mode and Increased Contrast support as one of our team’s first major projects, not because it was the most pressing issue but because we knew it would help build goodwill with the many engineers and designers at Quip who were clamoring for it. Taking on this project also helped cement the idea that accessibility wins are often wins for everyone and not just a niche compliance thing, piquing a lot of interest throughout the organization.
We also kept our ears to the ground to find out what other teams were working on, and tried to find opportunities to sync up our work while the hood was already popped (to use a car repair metaphor). This worked out really well for us when another team embarked on a redesign of the Folders navigation view, and we convinced them to make a pile of changes that took the keyboard and screen reader accessibility of that view to a much better place.
Finally, we also started a rotation program where engineers from other parts of the org could join our team and focus on burning down accessibility issues (and learning about accessibility!) for a few months. Accessibility should be everyone’s responsibility, but the reality is that learning how to do it well takes time, mentorship, and hands-on experience. This allowed us to build up a bench of people who were familiar with the basics scattered throughout the company, and led to some great wins like accessibility documentation for third party Live App developers (thanks, Xinchen Huang!)
Admitting our limitations
The previous strategies allowed us to create space to focus on the biggest problem impacting the most users, but that’s only part of the battle. We quickly realized that as newcomers to accessibility, we needed more expertise, too. WCAG and WAI-ARIA help with the basics, but we were up against complex interaction models and niche ARIA attributes. We needed guidance from people who had a deep understanding of the possibility space and could quickly steer us away from dead ends.
After a brief search online, we started working with James Scholes and Sina Bahram of Prime Access Consulting. James and Sina are both deeply experienced accessibility engineers, and also lifelong screen reader users themselves. We originally hoped that partnering with them could help us diagnose potential solutions for our contenteditable woes, but we got much more than we would have even known to bargain for.
Week after week, they challenged us to unpack our design and product intent, and then worked with us to find the best possible solution that worked within our limitations. They pointed out problems underlying the problems we were worried about. They helped us navigate the surprising potholes between ARIA attributes in the spec and ARIA attributes that are actually supported by browsers/screen readers. We dissected the Quip interface using precise words instead of relying on visual shorthand, which taught us so much about perceiving interfaces linearly and semantically instead of visually. Together, we built sandbox experiments, had long and challenging debates, and figured out bewildering bugs. Along the way, working with James and Sina rewired our team members’ brains and assumptions.
“Nothing about us without us” is a central slogan within the disability rights movement. Working closely with James and Sina on Quip’s accessibility taught me that in addition to an important political demand, this is also just plain good advice. Intuition is earned, and difficult to earn quickly—partnering closely with people who live and breathe the experiences you’re trying to design not only saves time, but leads to a richer outcome overall.
Credits
The hard work discussed in this post was done by all the members of Quip’s amazing accessibility team, past and present: Joyce Zhu, Leslie Carr, Chris de la Iglesia, Ben Cronin, Tommy Vo, Grace Kim, Natalie Liu, Drew Hamlin, Brewster McCann, and many others across Quip who helped out in big and small ways.