We just wrapped up a big project that substantially improves the accessibility of HEY. When we first started making HEY back in 2018, we had big aspirations around accessibility. We wanted it to set the gold standard for accessibility in all of our products.
But then reality hit: we were trying to build a totally new, technically complex product, with a tiny team, in 2 years. We had to make tons of uncomfortable cuts and tradeoffs to achieve that ambitious goal. Accessibility was absolutely a priority, but it had to fight for our attention along with the thousands of other things we were trying to do.
So, although we were able to make great strides in accessibility work along the way, by the time we launched, we still hadn't achieved everything we wanted—and had some major defects left to address.
We set out to correct that after launch. But the Basecamp/HEY team was stretched thin at the time, working through bug reports and critical updates. As our accessibility lead, I was clear on the issues and how to design solutions, but we needed someone to lead the technical side of this work. When both David and Kasper separately proposed the idea of bringing on a contractor, it was undoubtedly the way forward.
Kasper, a member of the Rails core team, had recently spotted a few accessibility-flavored pull requests opened by Sean Doyle at thoughtbot, like one designed to improve some aria-label defaults in Rails. We reached out, and lucky for us, thoughtbot was thrilled to get on board! Not only are they a Rails dev shop, but they were familiar with using Basecamp and our style of running projects.
When we kicked things off last August, it wasn't clear how long this work would take. We structured the contract in six-week intervals to match our project cycles at Basecamp. Working directly with a small handful of blind and visually impaired customers who use screen reader software was a fundamental part of this project: it's been a true collaboration, with ideas and questions shared back and forth all along the way. A special thanks to Scott Ballard-Ridley and Louis Lucero for all of their insights and feedback.
Below is a high-level overview of everything we accomplished over the five-month project. In part 2, I'll dive more into depth on specifics and the design decisions that went into these improvements.
- Unified and improved keyboard support across our box pages (Imbox, The Feed, etc.) to provide a consistent experience for interacting with message lists, performing bulk actions, and persistence of row selection when navigating into and back from messages.
- Unified our popup-menu elements for consistent focus-trapped keyboard navigation, along with system test helpers to exercise their behavior in an automated way.
- ARIA-compliant combobox and listbox elements, with keyboard navigation, focus management, and announcements of current selection and result counts while filtering.
- We reviewed and improved keyboard navigation across The Screener, message views, and all other pages.
- Introduced an announcement controller to support accessible client-side announcements via aria-live, such as when recipients are added to or removed from the message composer.
- Added a new helper that provides a consistent method for adding screen reader text alongside visual text.
- A system to improve how screen reader software handles the announcement of characters like "•", "→", and the "<" ">" (angle brackets) surrounding email addresses. In some cases, it was necessary to replace the pictograms with more descriptive labels. In others, better to hide them entirely from accessible tech.
- Added a method for non-visual Flash messages, for example, to communicate when there are new messages to screen, something we were already conveying visually.
- Added aria-label formulations to better describe links, buttons, articles, and other elements non-visually. In some cases, this provides essential clarity on what activating the element will do. In others, it allows these elements to be navigable via screen-reader-specific quick nav features, which previously would have been impossible due to their generic names.
- We incorporated axe-core into our existing system tests suite to automatically check for accessibility violations on all code changes, and fixed a bunch of non-compliant code along the way.
It was an absolute delight to work with Sean and thoughtbot over the five-month project. They've left us with not only a more accessible product but an abundance of examples to draw from and components to reuse as we build future HEY features. Our next step is a third-party audit to validate that HEY is as accessible as we think it is, and ramping up our user research to include people with a broad representation of disabilities. HEY isn't perfect (yet!), but we've set a new baseline for every product we produce in the future.