Automated Accessibility Testing at Slack

At Slack, customer love is our first priority and accessibility is a core tenet of customer trust. We have our own Slack Accessibility Standards that product teams follow to guarantee their features are compliant with Web Content Accessibility Guidelines (WCAG). Our dedicated accessibility team supports developers in following these guidelines throughout the development process. We…

Natalie Stormann
15 min readintermediate
--
View Original

Overview

The article discusses the implementation of automated accessibility testing at Slack, highlighting the integration of the Axe accessibility testing tool into their existing testing frameworks. It emphasizes the importance of accessibility in product development and details the challenges and solutions encountered during the integration process.

What You'll Learn

1

How to integrate automated accessibility testing into existing testing frameworks

2

Why using Axe with Playwright is beneficial for accessibility checks

3

How to effectively triage accessibility issues discovered through automation

Prerequisites & Requirements

  • Understanding of accessibility standards like WCAG
  • Familiarity with Playwright and Axe testing tools(optional)

Key Questions Answered

What challenges did Slack face when integrating Axe into their testing framework?
Slack encountered complexities related to their customized Jest setup, which made embedding Axe checks directly into React Testing Library difficult. They pivoted to using Playwright, which offered better support for accessibility testing through the @axe-core/playwright package.
How does Slack report accessibility violations from automated tests?
Initially, Slack stored accessibility violation reports in a simple text file. After feedback, they enhanced the reporting by integrating Playwright’s screenshot functionality and using the Playwright HTML Reporter to create more coherent reports with detailed violation information.
When should accessibility checks be placed in end-to-end tests?
Accessibility checks should be placed strategically after significant interactions, such as button clicks or user sign-ins, ensuring that the page or view is fully rendered before the checks are executed to avoid duplication of analysis.

Technologies & Tools

Some links below are affiliate links. We may earn a commission if you make a purchase.

Testing Tool
Axe
Used for automated accessibility testing to identify violations against WCAG standards.
Testing Framework
Playwright
Utilized for end-to-end testing and integrating accessibility checks.

Key Actionable Insights

1
Integrate automated accessibility checks into your CI/CD pipeline to ensure consistent compliance with accessibility standards.
By running these checks regularly, teams can catch accessibility issues early in the development process, reducing the burden of manual testing and improving overall product quality.
2
Utilize the @axe-core/playwright package to enhance your end-to-end testing framework with accessibility checks.
This integration allows for more comprehensive testing and ensures that accessibility considerations are part of the development workflow, ultimately leading to a better user experience.

Common Pitfalls

1
Failing to run accessibility checks after the entire page has fully rendered can lead to missed violations.
This happens because automated checks may only evaluate individual elements, missing broader accessibility issues that require the full context of the page.

Related Concepts

Accessibility Standards
Automated Testing Frameworks
End-to-end Testing Strategies