Everything You Need to Know About How Slack Approaches Accessibility Testing
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 in to 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 a 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 on 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! 👇
Canadian CRTC Caption Laws
Canada’s deaf and hard of hearing population have been advocating for higher captioning standards since the 1960s. The Canadian Radio-television and Telecommunications Commission (CRTC) has done much work in the last decade to give Canadians a chance to voice their opinions and…
How to Design a Sustainable Process for Accessible Web Design
Designing an accessible website is more important than ever before. In fact, 71% of people with disabilities leave a website immediately if it’s not accessible. Slow a steady wins the race, and accessible web design is more than just a one-time auditing…
How to Get Started with 3Play Media’s Audio Description
Audio description is an audio track that narrates the relevant visual information in media and assumes the viewer cannot see the onscreen content. It can be compared to a sports broadcaster narrating the visual action of a game over audio. The descriptions…