“There’s no such thing as an average, there’s only an empty middle,” Todd Rose writes in The End of Average. Designing a system for an individual user, rather than a mythical average user, can impact everything from cockpit design to personalized medicine, education to product design. Frontend development, then, should not be about reflexively building a product for a single, average user, but intentionally building for many different users.
According to the World Health Organization, about 15 percent of the world’s population lives with some form of disability. Assistive technologies, such as voice controls for navigation, screen readers and braille readers, and closed captions, are critical to broadening access to the internet. Yet a 2019 WebAIM study of the top 1 million home pages on the web found that as few as 1 percent met the most commonly used and trusted web accessibility standards to address visual, hearing, and mobility needs, the Web Content Accessibility Guidelines (WCAG).
“Aside from the fact that [building for accessibility] is the right thing to do, it is also really important in business use cases,” says frontend engineer Trish Ang. In 2017, the year Ang joined Slack, the messaging platform was serving more enterprise companies, rapidly signing up clients across sectors. These clients included government agencies, many of which are legally required to uphold accessibility standards for their employees and require any software they adopt to do the same.
One of the earliest frontend components Ang worked on at Slack was a select-out. A select-out has two parts: an input box, and a list that filters results as the user types into the input box. Think of Google Autocomplete, filtering and displaying frequently searched terms as you type in a query. The select-out Ang was building was a new, one-off version that would pop up when a person selected “More message actions” on any message in their Slack channel. To communicate internally, employees at Slack use an advanced version of their own product, meaning every component in development gets stomped on by more than a thousand users before a wider launch. Like all other components the team built, this select-out would be dogfooded by the larger Slack team before wider release.
For her first attempt at building the select-out, Ang broke it into two components: a text input and a menu to show the results. With the aid of visual cues—consistent typography and containing both within a white box—the components looked like they belonged together, and seemed to work as intended. But when Ang released her select-out, named internallt, accessibility product manager George Zamfir, who oversees accessibility as a Slack product, contacted her, both to congratulate her on the release and to inform her that the list was not at all usable with a screen reader.
Anywhere from 0.27 to 7.5 percent of Americans have limited to no vision, depending on the study. Vision itself is a spectrum, ranging from 20/20 vision to mild loss of acuity (often correctable with glasses) to total blindness. According to a 2019 study from Nucleus Research, as many as 70 percent of websites are inaccessible to people with limited to no vision. To use the internet, many rely on screen readers.
Screen readers are like play-by-play commentators of the web: Paired with a rotor, a user interface element that aids in quick page navigation, screen readers help individuals build mental models of web pages without the visual cues of typography and design. Engineers at Slack have a device laboratory where they can test their components on any combination of browser, device, and screen reader. During the development process, Ang uses VoiceOver on Mac and NVDA on PC.
In Ang’s first version of the select-out, the relationship between the input box and the automatically filtering list was solely visual; the screen reader revealed the disconnect between the two components in the code. “Screen readers can only really read what they’re currently focused on,” Ang explains. “If I was focusing on the input and I started typing into it, then [the screen reader] knows whatever I’ve typed into it, but it doesn’t know anything about the list below it. Then, if I hit [the] tab [key], and it focuses on the list below it, it now knows the contents of that list, but it doesn’t know anything about what the input was.”
To build and update features with screen readers in mind, Ang and other frontend developers would have to link components beyond visual cues. They’d also have to find the right density of information to pass through the screen reader to the end user. Too much information, and the speed at which a user can navigate is compromised; too little, and they might not be able to navigate with accuracy.
The fix consisted of ensuring proper native HTML markup and ARIA labeling. ARIA, or Accessible Rich Internet Applications, is an API that assistive devices and technologies (including screen readers) use when parsing a web page’s Document Object Model, or DOM, to improve the information they communicate to the user. Where native HTML is insufficient, ARIA labels help add semantic clarity to elements and bridge accessibility gaps.
For version two, Ang structured the select-out in an entirely different way. Bundled within a single select component with proper ARIA labels, the text input and menu looked precisely as they had before, but they now worked in concert in the code itself—and for the screen reader. “The screen reader only focuses on one thing,” Ang explains. In this case, the text input. Though the reader never actually shifts focus to the menu, menu interactions report back to the text input. “Then the input has the proper labeling for the screen reader,” Ang says.
The failure of the first version of the select-out was a lesson in sustainable development: Having to rebuild a component after feedback from an accessibility specialist, rather than building it right the first time, eats up a developer’s time. And Ang wasn’t the only developer to experience this. Working with tight launch schedules, she says, “that model was stressful, really painful, and not sustainable.”
Accessibility had to be the intentional default for all products, rather than an afterthought. This meant making dramatic changes to the development process, requiring accessibility to be specced, designed, built, and tested in much the same way as any other product feature.
The team was already investigating a move to React when they decided to build a standard set of components that would be accessible out of the box. This component library and design system was called Slack Kit, and it would be built by frontend developers and designers on a volunteer basis with accessibility specifications mapped from the get-go.
Ang began work on three select components that had to suit a wide variety of use cases: a basic select, which opens a simple drop-down menu of options; a search-select, in which a user types an input and a list filters matching options; and a multi-select, which enables a user to make multiple selections from a list that then automatically populates in an input as tokens.
Ang worked with her team’s (and, at the time, Slack’s only) accessibility engineer, Todd Kloots, to audit how developers would use each of these components throughout Slack’s products. Next, they wrote a product spec of the underlying ARIA structure they’d need for each of the three selects.
To Ang’s surprise, each ARIA mapping was distinct. “Because the basic select is just a button that opens a list, it requires different labeling to let people know that [something is] open. It requires the focus to shift from the button to the list, whereas the search-select and the multi-select actually require the focus to remain on the input, because that way the screen reader knows [it’s linked to] the ARIA active option on the list.”
The project took six months to complete. While the first engineer took a month to implement a fully accessible select component into their use case, the next engineer implemented it in days. “It’s a really big up-front investment, but it saves a ton of time for every future engineer who wants to use it,” Ang says.
Because of the universality of the Slack Kit components, maintenance is an involved process. “When we do something good, it works everywhere,” Ang says. “The double-edged sword is [that] if somebody breaks a select with something they introduce,” it’s broken everywhere.
At the time, Kloots was supporting 74 frontend developers at the company, and he was underwater. Not only did he have a constant flow of usability tickets to address, but he also needed to ensure new features served a consistent user experience regardless of individual needs. “It was clearly not sustainable for him,” Ang says.
Slack’s engineers didn’t simply need to change their processes—they also had to change their team structure. In 2018, the company held the first wave of training for frontend developers, in hopes of reducing the number of simple queries in Kloots’s queue. They then hired an additional accessibility engineer, Divya Kamath, to help with the heavy lifting.
In 2019, Slack Kit, no longer a volunteer project, was officially staffed as a formal team, which both of Slack’s accessibility engineers then joined. Today, Slack Kit engineers are available to support building and troubleshooting special use cases. When a developer wants to edit a component, or when they receive a ticket from Ultra, a partner that helps Slack audit accessibility features, the Slack Kit team goes through “a couple of unique implementations to make sure that the new edition doesn’t break functionality, and that it still keeps accessibility working for everybody else,” Ang says.
The Slack Kit team is also working toward a second round of training, a workshop to teach engineers debugging techniques for ARIA patterns. In the meantime, the team runs weekly office hours to triage accessibility issues. On a recent occasion, an engineer brought a date-range picker that he was building on top of an existing accessible calendar component, which, until then, had only allowed users to make a single date selection. Finding the right amount of information to pass on to the user was tricky: What about unavailable dates, or calendar navigation patterns, or confirmation of the user’s selection? “Even our accessibility engineer hadn’t worked with this [ARIA] pattern before,” Ang says. The collaborative environment helped them work out the nuances, and the engineer was able to build an even better calendar experience.
The internet has the potential to be a great equalizer, serving varied users for unlimited purposes. But it can only achieve that potential if websites and apps are built to be accessible by default. To build for accessibility is to build products that benefit everyone. “Consideration up front has made everybody’s lives a million times better,” Ang says. “Everyone is responsible for accessibility.”