Accessibility scans can run automatically inside a CI/CD pipeline, catching issues every time code is deployed. The setup involves adding a scan step to your build or deployment process, configuring it to evaluate pages against Web Content Accessibility Guidelines (WCAG) criteria, and defining how the pipeline responds to the results.
| Key Point | What It Means |
|---|---|
| Where Scans Fit | Scans run as a step in the build, staging, or deployment stage of the pipeline |
| What Scans Evaluate | HTML, CSS, and ARIA attributes against WCAG success criteria |
| Coverage Limitation | Automated scans flag approximately 25% of accessibility issues |
| Pipeline Response | Teams configure scans to warn, gate deployments, or log results for review |
Where Accessibility Scans Fit in a Pipeline
Most teams place accessibility scans after the build completes and before the deployment reaches production. The scan runs against a staging or preview environment where rendered pages are available for evaluation.
Scans need fully rendered HTML to work. They evaluate the DOM output of a page, checking HTML structure, CSS properties, and ARIA attributes against WCAG success criteria. Running scans against source code alone is not enough because many accessibility issues only appear after the browser renders the page.
Configuring the Scan Step
A scan step in a CI/CD pipeline typically involves a command-line scanner that runs inside the build environment. The configuration specifies which pages to scan, which WCAG conformance level to evaluate against (usually 2.1 AA or 2.2 AA), and what output format the results should take.
Page selection matters. Scanning every page on every build is often impractical. Teams commonly define a representative set of page templates: the homepage, a form page, a content page, a listing page, and any page with interactive components. This approach covers the most common patterns without slowing the pipeline.
Deciding How the Pipeline Responds to Issues
There are two common approaches to managing scan results in a pipeline. The first is a warning mode, where the scan runs and logs results without blocking the deployment. The second is a gating mode, where the pipeline stops if the scan identifies issues above a defined threshold.
Warning mode works well for teams that are adding scans to an existing codebase with known issues. It generates visibility without disrupting releases. Gating mode is appropriate once the baseline is clean and the team wants to prevent new issues from reaching production.
Some teams take a middle path: gate on critical issues (such as missing form labels or empty interactive elements) while allowing lower-severity findings to pass with a logged warning.
What CI/CD Scans Do and Do Not Cover
Scans running in a pipeline evaluate the same things any automated scanner checks: alt text presence, heading structure, form label associations, ARIA attribute validity, and similar programmatic checks. These scans flag approximately 25% of WCAG issues.
The remaining 75% of issues require human evaluation. Keyboard interaction patterns, screen reader announcement accuracy, reading order, and context-dependent labeling cannot be assessed by automated scans. CI/CD scans are a first line of detection, not a replacement for a manual audit conducted by an accessibility professional.
Interpreting and Acting on Results
Scan output in a pipeline typically includes the issue type, the WCAG criterion it maps to, and the HTML element involved. Teams should route these results into their existing issue tracking workflow rather than treating them as a separate reporting stream.
Prioritize by user impact. An empty button with no accessible name affects every keyboard and screen reader user who encounters it. A minor heading level skip on an internal page has a lower impact. Addressing high-impact issues first keeps the remediation effort focused.
CI/CD accessibility scans work best as one part of a broader evaluation strategy that includes recurring scans and periodic manual audits at defined intervals.