Running Scans with E2e Tests

Use Case: Running Scans with E2E Tests

Actors:

Frontend Developer
QA Engineer
CI/CD System

Context: Teams running automated end-to-end (E2E) tests want to ensure that accessibility issues are caught during functional test execution, without requiring a separate workflow.

Goal: Run accessibility scans in parallel with E2E tests so accessibility checks are embedded into the existing QA pipeline.

Preconditions:

Level CI is installed and configured in the project.
E2E testing framework (e.g., Cypress, Playwright, Selenium) is set up in the repository.
Repositories are connected to Level CI.

Scenario (Happy Path):

The developer/QA triggers the E2E test suite through CI/CD.
Level CI integrates with the test runner to scan rendered pages/components for accessibility violations.
Accessibility issues are collected and matched against the project’s A11y Quality Gate rules.
Results are reported:
1. In the CI pipeline logs.
2. As annotations in pull requests.
3. In the Level CI reporting dashboard.
If the Quality Gate fails, the CI job is marked as failed, preventing merges or deployments until issues are resolved.

Post-conditions:

Accessibility violations are flagged early in the QA cycle.
Developers receive immediate feedback within their existing E2E test workflow.
Teams enforce accessibility compliance consistently before release.

Benefits:

Shifts accessibility checks left into automated testing.
Reduces manual rework by catching issues early.
Provides a single workflow for both functional and accessibility testing.