# When should a failed accessibility check block a store release? | Accessignal

Source: https://accessignal.com/blog/2026-10-04-accessibility-alert-block-release.html

[Home](../index.md) / Alert management


Published October 4, 2026

Not every red check deserves to stop a deploy. The block list is short: checkout blockers, new critical issues on the purchase path, and anything a demand letter already cited.

## Alerts are cheap; blocked releases are expensive

An accessibility alert that fires on every deploy and never blocks anything trains the team to ignore it. An alert that blocks every deploy over minor issues trains the team to disable it. The useful middle is a short, explicit block list: the failures that stop a release, everything else logged and queued. The list has to be written down, agreed on, and short enough to remember.

## Blocker one: anything that breaks the purchase path

If a shopper using a keyboard or screen reader cannot complete a purchase, the release does not ship. This covers keyboard traps in checkout, unlabeled required fields on payment forms, focus that disappears into modals during checkout, and error messages a screen reader never announces. These are not polish issues. They are the exact barriers that end up quoted in demand letters, and they directly cost revenue from shoppers who cannot check out.

The purchase path for this rule means cart, checkout, and the product page actions that lead there. A broken keyboard flow on a blog article does not block a release. A broken keyboard flow on the add-to-cart button does.

## Blocker two: new critical issues introduced by this release

A release that introduces a fresh critical issue should not ship with it, even outside the purchase path. The key word is new. The check compares the release candidate against the current live baseline, and only regressions count. A store with fifty pre-existing issues should not have its deploys frozen forever; it should be prevented from adding a fifty-first.

This is why the alert needs a baseline, not just a scan. Without a baseline, every release flags the same legacy issues and the team learns the alert is meaningless. With a baseline, the alert means something specific: you broke something that used to work. That is block-worthy.

## Blocker three: anything a demand letter already cited

If the store has an active or recent demand letter, every barrier the letter named becomes a release blocker until it is fixed and verified. This is not about accessibility theory. It is about the legal record. Shipping a release that reintroduces or leaves unaddressed a cited barrier, after the store acknowledged the letter, is the kind of fact pattern that turns a nuisance claim into an expensive one.

Keep the cited-barrier list as a standing checklist attached to the client's record. The release gate checks against it automatically. When the matter closes, the list retires with it.

## What does not block: everything else

Everything outside the block list gets logged, prioritized, and scheduled, but the release ships. Minor contrast issues, redundant links, imperfect heading structure, decorative image alt text debates: real issues, worth fixing, not worth stopping revenue over. The alert for these should say plainly that the release proceeded and the issue is queued, so nobody confuses "not blocking" with "not tracked."

This distinction is what keeps the gate credible. A gate that blocks twice a year over real barriers gets respected. A gate that blocks weekly over trivia gets bypassed, and then it blocks nothing.

## Make the override explicit and rare

There will be a Friday afternoon when a blocker fires and the release cannot wait. Allow an override, but make it cost something: a named owner, a written reason, and a fix deadline, all logged where the client can see them. Overrides that require a paragraph of justification stay rare. Overrides that require one click become the default.

Review override history monthly. If the same blocker gets overridden three times, either the check is wrong or the fix is being avoided. Both are worth a conversation, and the data tells you which one.

## Write the policy before the first block

The worst time to define the block list is during the first incident. Write it now: the three blocker categories, the baseline comparison rule, the override process, and who gets paged. Put it in the runbook next to the deploy checklist. When the alert fires at 4pm on a launch day, nobody should be debating philosophy. They should be reading the policy.

## Frequently asked questions

### When should an accessibility finding block a release?

When it introduces a new critical barrier on a purchase path or removes an existing accessible route. A release gate should be narrow and specific, so it stops real harm without becoming a general brake on shipping.

### What findings should not block a release?

Pre existing issues that the release does not worsen, and minor findings with a scheduled fix. Blocking everything trains teams to argue with the gate instead of fixing the critical few it exists to catch.

### Who decides when an alert is release blocking?

The criteria should be written in advance and applied by whoever owns release quality, with accessibility input. Decisions made case by case under deadline pressure drift toward shipping, every time.

### How should a blocked release be recorded?

With the finding, the criterion it met, the fix required, and the retest result that cleared it. That record protects the team that held the line and improves the criteria for the next hard call.