Accessibility Defect Rate: The Metric That Shows Whether Fixes Are Keeping Up

2026-10-25

Most accessibility dashboards show a backlog total, and most backlogs only move in one direction. Teams celebrate closing fifty issues in a quarter while quietly creating eighty, then wonder why the total never falls and audits keep surprising them.

Defect rate fixes the blindness. It measures flow, not stock: how fast issues arrive versus how fast they leave. A team that understands its rate can argue for prevention with numbers instead of feelings.

Define the rate so two teams agree

Pick a stable denominator, such as releases, audited templates, or new pages published, and count new confirmed issues per unit. Track closures in the same window. The ratio between the two is the number leadership needs, because it predicts the backlog months ahead.

Severity weighting matters. Ten minor labeling issues and ten checkout blocking issues are not the same rate in any useful sense. Report the rate by severity band, or the average will hide the issues that carry legal and revenue risk.

Separate found rate from created rate

Issues found in an audit of old pages are not issues the current team created. Mixing discovery of legacy debt with new defects makes good teams look careless and hides whether current practice is improving.

Tag each issue with the age of the page or component it lives in. Over time the created rate for new work should fall toward zero for critical issues, even while audits keep surfacing old debt to burn down.

Use the rate to fund prevention

When the created rate stays high, the cheapest fix is upstream: accessible components, design tokens with checked contrast, and pre release testing. The rate gives that argument a price, because every point of rate has a known remediation cost attached.

Component level data sharpens the case further. If one shared component produces a third of new critical issues, fixing it once outperforms a quarter of page by page remediation, and the rate proves it.

Report it like an engineering metric

Put defect rate next to the metrics teams already respect, in the same review, with the same trend lines. Accessibility improves fastest when it stops being a special report and becomes part of how release quality is judged generally.

Set a simple target, such as no new critical issues in new templates, and review misses without blame. The point of the rate is to find system causes, and blame is the fastest way to make people hide the data.

Frequently asked questions

How is defect rate different from a backlog count?

A backlog count shows how many issues exist. Defect rate shows how fast new ones are being created compared with how fast they close. The rate predicts where the backlog is heading, which is what planning actually needs.

What denominator should we use for defect rate?

Use something stable in your context, like per release, per new page, or per audited template, and keep it consistent. Consistency over time matters more than which denominator you choose.

Should legacy audit findings count as new defects?

Track them separately. Issues discovered in old pages are legacy debt being uncovered, not defects the current team created. Mixing them hides whether current design and development practice is improving.

What is a good accessibility defect rate target?

A practical target is zero new critical issues in new work, with the overall created rate trending down quarter by quarter. The right numeric target depends on your release volume and severity mix.