# Accessibility Monitoring in CI: Where to Set the Axe Threshold So Alerts Mean Something

Source: https://accessignal.com/blog/2026-11-10-accessibility-monitoring-ci-axe-thresholds.html

November 10, 2026

*Every team that wires an accessibility scanner into CI learns the same lesson within a month. Fail the build on every violation and developers start ignoring the check, then someone disables it during a launch crunch and it never comes back. Never fail the build and the scanner becomes a dashboard nobody opens.*

## Automated checks catch a slice, and the slice is real

Automated testing catches roughly a quarter to a third of WCAG issues, and the exact share depends on who is counting and what they count. What it catches reliably is the mechanical layer: missing alt attributes, form controls with no accessible name, color contrast below 4.5 to 1, duplicate ids, invalid ARIA. Those are real failures, and they are the ones that show up in demand letters because a scanner on the plaintiff side found them first. The scanner is not the audit. It is the tripwire that tells you something changed, and the threshold decides whether the tripwire gets respected or ripped out.

The mistake is treating the scanner output as a verdict. Axe-core rules have impact levels for a reason: critical, serious, moderate, minor. A missing accessible name on a checkout button is critical. A duplicate id on a decorative element is minor. A CI gate that treats them the same teaches the team that the gate is noise, and teams route around noise.

## A threshold that survives contact with a launch

Start with this split. Fail the build on new critical and serious violations only, and only on pages in the critical path: homepage, product page, cart, checkout, account. Report moderate and minor violations as warnings that never block a merge, and track them on a dashboard with a weekly review. The key word is new. A legacy site with two hundred pre-existing violations cannot adopt a zero-tolerance gate on day one, because the gate would block every deploy until someone fixes two hundred issues. Baseline the existing violations, fail on anything above the baseline, and ratchet the baseline down as fixes land.

The second half is what the scanner cannot see. A scan that returns zero errors does not mean the checkout works with a keyboard, and a scan that returns zero errors on a page with an AI-generated alt attribute does not mean the alt text describes the product. Automated checks cannot judge whether an accessible name makes sense, whether focus order follows the visual order, or whether a modal traps focus. Pair the CI gate with a manual pass on every template change: keyboard-only walkthrough of the changed flow, screen reader pass on the changed component. That pairing is the difference between monitoring and theater. For the scanner side of the same problem, see [When the Scan Says Zero Errors and the Checkout Is Still Blocked](https://accessignal.com/blog/2026-11-09-scan-zero-errors-keyboard-checkout-blocked.md), and for the alert side, [Real Accessibility Monitoring: Alert vs Noise](https://accessignal.com/blog/2026-11-09-real-accessibility-monitoring-alert-vs-noise.md).

## What to do when the gate fires

A failing gate needs a runbook, not a Slack message. The runbook names the page, the rule, the element, and the fix pattern, and it names who owns it. If the same rule fires three times in a month, the fix is not a ticket, it is a component change or a lint rule that stops the pattern at authoring time. A monitoring setup that only reports is a reporting setup. The point of the threshold is that a failure means something specific and the next step is already written down.

## Frequently asked questions

### What percentage of WCAG issues can automated testing catch?

Roughly a quarter to a third, depending on the methodology. Automated checks reliably catch mechanical issues like missing alt text, unnamed controls, and contrast failures. They cannot judge meaning, focus order, or whether a fix actually works for a keyboard user.

### Should CI fail the build on any accessibility violation?

No, not on day one. Fail on new critical and serious violations on critical-path pages, baseline the pre-existing ones, and ratchet the baseline down. A gate that blocks every deploy gets disabled, and then you have no gate at all.

### Does a zero-error scan mean the page is accessible?

No. A scan can return zero errors on a checkout a keyboard cannot finish, or on AI-generated alt text that describes nothing. Automated checks are a tripwire, not an audit. Manual keyboard and screen reader passes are still required.

### How do we stop the same violation from coming back?

Fix the component or add a lint rule at authoring time. If the same rule fires three times in a month, the problem is the pattern, not the page, and a ticket per occurrence will never close it.