Stacks Accessibility Testing Strategy

July 24, 2024 ยท View on GitHub

Date: 2022-12-21

Related PR: #1217

Issue

We currently rely on manual testing, third-party audits, and user reports to identify and fix accessibility issues. The only semi-automated accessibility testing we do is via Mabl, which is initiated manually and tests instead of individual components. Furthermore, while we've generally aspired to WCAG 2.2 AA compliance, we haven't codified the accessibility success criteria for our components.

A defined success criteria and automated accessibility testing will reduce the effort needed to build and maintain accessibile components.

Decision

Introduce the following success criteria for the accessibility Stacks components:

Introduce the following automated accessibility testing for Stacks:

  • All components should include accessibility tests using the chai-a11y-axe plugin in unit test files.

Contexts to consider

Components can be rendered in different combinations of light/dark and high contrast modes. We should test components in all of these contexts to ensure they meet the success criteria.

A note on viewport widths

Though accessibility issues can arise at any viewport width, accessibility issues tend arise primarily from invalid markup and color contrast issues. Because of this, we should focus on testing components at the default viewport width and use discression when adding tests for different viewport widths.

Additional Guidelines

  • All tests and linters runs in a GH workflow for every commit and pull requests on develop branch.

  • Tests will be gradually added to existing components as developers need to change them. New components should always be accompanied by tests.

Additional info