Running Scans without E2e Tests

Use Case: Running Scans Without E2E Tests

Actors:

Frontend Developer
Team Lead / QA Engineer
CI/CD System

Context: Not all teams have automated end-to-end (E2E) tests in place. They still want to ensure accessibility checks are consistently applied during development and deployment workflows.

Goal: Run accessibility scans independently of E2E tests, using Level CI’s built-in scanning capabilities.

Preconditions:

Level CI is installed and configured in the project.
Project repository is connected to Level CI.
A11y Quality Gate is defined for the project.

Scenario (Happy Path):

The developer or CI job triggers a Level CI scan (e.g., during a pull request or scheduled build).
Level CI launches its scanning engine against the rendered application or designated test URLs.
Accessibility violations are detected and compared against the project’s A11y Quality Gate rules.
Results are reported:
- In the CI/CD pipeline output.
- As annotations on pull requests.
- In the Level CI reporting dashboard.
If the Quality Gate fails, the CI job is marked as failed, blocking merges or deployments until issues are resolved.

Postconditions:

Accessibility scans run as a standalone process without requiring functional automation.
Violations are identified and communicated in the same channels developers already use.
Teams ensure accessibility compliance even without dedicated test automation.

Benefits:

Enables teams without E2E automation to still enforce accessibility standards.
Provides a lightweight, consistent way to integrate accessibility checks into CI/CD pipelines.
Ensures accessibility is part of every release cycle, regardless of test maturity.