Everything You Need to Know About How Slack Approaches Accessibility Testing
Updated: May 1, 2020
As your organization starts to scale, how do you ensure accessibility is still a priority?
In the webinar, “How Slack Approaches Accessibility Testing”, three engineers at Slack, Sharanya Viswanath, Kirstyn Torio, and Kristina Rudzinskaya, discuss how they approach and scale accessibility at Slack.
This blog post will provide organizations with actionable tips on how to grow an accessibility team and approach accessibility in the development process.
Approaching Accessibility at Slack
Slack is a communication platform that brings all of your organization’s tools together in one place. It allows teams to share information, files, and more all in one workspace.
Engineers at Slack wanted to deliver the most delightful, inclusive experience to their users. They learned that the earlier accessibility was built into the development process, the more people would be able to use Slack. They focused on not just fixing bugs but improving the overall user experience.
In the early stages, team members didn’t know what it took to build an accessible product. Values alone weren’t enough to kick things off – they also need expertise.
The accessibility team was created three years ago to proactively build foundations and accessibility-specific features, however, they still had a problem – they couldn’t scale accessibility efforts because everyone should own accessibility.
A strategy called “Everyone Does Accessibility” was created to help team members answer the following questions.
- How do we increase a11y (accessibility) awareness?
- How do we fit accessibility into the existing process?
- How do we provide thorough coverage?
Tactically, the strategy helps each role involved in software development with a simplified answer to the question, “what’s in it for me?” This is specifically important for quality engineers since they are closer than anyone else to the end-users.
Quality Culture at Slack
In order to achieve accessibility, the team of engineers needed to address a few problems.
- Limited understanding of accessibility
- Fitting accessibility into the existing process
- Providing thorough coverage for all accessibility features
First, engineers at Slack went through a manual approach to the quality-testing process represented by this pyramid.
Scaling A11y Testing
Engineers at Slack develop, test, and manage quality around the development schedule. How is this done? With automated tests, of course!
They strive to adhere to the test pyramid and have modeled it for testing accessibility to rely on linters, unit tests, and UI tests. They’ve compartmentalized these checks before and after code gets shipped to production. Pre-merge checks are heavily invested in to minimize regression.
Pre-merge checks include:
- Static linters
- Unit tests
- Some functional tests
On the other hand, post-merge checks include:
- More heavy functional tests
With the pre-merge and post-merge checks, it’s important to understand how early Slack thinks about automation, and how it flows along with their process to assure quality.
Before development, there are a few steps the engineers take. First, the team meets. Then, product and engineering start thinking about a project, and members of quality and automation engineering are involved in the kickoff meetings when ideas are fully baked and approved by the internal council.
Post-kickoff, quality engineering comes up with a test plan and partners with development to identify the pieces that can be automated via unit or end-to-end tests. Then, prioritized work is tracked on Slack’s project management tool to ensure everything is done before the feature gets shipped to users.
Both development and quality engineering write and maintain tests. It’s possible that sometimes these tests may not run properly and can be flaky. A flaky test is a test that when it fails, there are no changes detected in the source code.
When a test is developed, there’s an opportunity to run it several times in a stability test job. Once the test has 100% stability, it is introduced in the automation test suite as a pre-merge, or pre-blocking test.
It’s imperative to have structures in place to fix flaky tests depending on test priority, severity, and also the stability rate.
After development, the regression automated tests that catch bugs post-merge triages the test failure to follow up with appropriate engineers in a fix forward, revert, or having the logic behind a feature flag to allow for further investigation and thorough testing.
Slack believes that they’ll be able to scale this strategy through their values and have more success stories to celebrate. Most importantly, they’ll have way more delighted users.
Watch the full webinar! 👇
6 Zoom Etiquette Reminders for Your Next Meeting
It may be a new year, but tens of millions of Americans will still be working remotely in 2021. And as we can all guess, this means more meetings on Zoom, Google Hangouts, and other video conferencing software. While your team likely…
Video Trends for 2021
With every new year comes new changes, but one thing reigns true, video is here to stay. 2020 brought about many changes, including the COVID-19 global pandemic. It forced us to shelter-in-place and socially distance from family, friends, and colleagues. Since face-to-face…
3Play Media’s Top 5 Blog Posts of 2020
The events of 2020 have caused an impact in every facet of our lives – and closed captioning and video production were no exception. Here at 3Play Media, we were on both the cause and effect side of these industrial shifts. Responding…