AccessPreflightAPI documentation
Open console
Ship with confidence

Define a release check that fails safely

A quality gate turns normalized scan evidence into your organization's deployment decision. It is independent from the accessibility result so a product can change release policy without rewriting what the scanner observed.

Gate controls

{
  "quality_gate": {
    "block_on": ["blocker", "critical", "major"],
    "block_on_new_only": true,
    "max_major_new": 0,
    "require_manual_checklist_acknowledgement": true,
    "fail_on_incomplete": true
  }
}
Setting Effect
block_on Fails when an unsuppressed failure has one of these severities
block_on_new_only Evaluates blocking findings against a compatible baseline diff
max_major_new Sets the allowed count of new major failures
require_manual_checklist_acknowledgement Prevents an automated release from implying manual work was completed
fail_on_incomplete Fails closed when required coverage was not achieved

Start in observation mode

Before blocking production:

  1. Run the gate without enforcing it for representative releases.
  2. Review false positives, reduced coverage, and required manual work.
  3. Create narrow, reasoned suppressions for accepted exceptions.
  4. Establish a compatible baseline.
  5. Enable block_on_new_only to prevent regression while existing debt is remediated.
  6. Tighten the policy over time.

This creates a predictable adoption path without treating all legacy findings as a new-release failure.

Fail closed on uncertainty

If the gate depends on a missing baseline, incomplete coverage, or unacknowledged manual review, quality_gate.status can be indeterminate. Production CI should normally hold or fail on indeterminate.

Never map not_configured or indeterminate to success merely because they are not the string failed.

Store policy in a versioned rule pack

For repeated scans, put the gate in an immutable rule-pack version. This gives every scan an explainable policy snapshot and avoids subtle differences between CI scripts.

The API remains authoritative. Client-side hidden controls and local validation are usability aids, not authorization or policy boundaries.

Search documentation