Issue Age: The Accessibility Metric Nobody Reports

2026-10-26

A typical accessibility report says 140 open issues, 30 closed this quarter. Both numbers can improve while users see no change at all, if the closed issues were trivial and the serious ones have been open since the last redesign.

Age is the missing dimension. Once a team starts reporting how old its open barriers are, the conversation changes from how busy everyone is to which specific users are still locked out, and for how many months running.

What to measure, exactly

Track three numbers: average age of open issues, the age of the oldest open issue, and the count of issues older than your agreed threshold, often 90 or 180 days. Break them down by severity, because an old cosmetic labeling issue and an old checkout blocker are not the same debt.

Age should start when the issue was confirmed, not when it was fixed in a later release note. Honest start dates are what make the metric uncomfortable, and the discomfort is the point.

Why backlogs hide their worst problems

Queues reward easy wins. Teams closing many small issues can hold a steady count while difficult issues, the ones needing design changes or vendor work, sink to the bottom and age quietly. From the top, the program looks active. From a wheelchair user's seat, nothing has moved.

Age reporting breaks that illusion without blaming anyone. It separates activity from progress and gives long blocked issues a fact that advocates for them in every review: this barrier has existed for 400 days.

Setting thresholds teams respect

Pick an age limit per severity and treat crossing it like an escalation, not a statistic. Critical barriers might get 30 days, serious ones 90, minor ones a year. When an issue crosses its line, it appears on a named leader's report automatically.

Thresholds fail when everything is overdue. Set them from your real fix capacity, review them yearly, and let the first year's goal be honesty: knowing the true ages, before promising to halve them.

Pairing age with the other metrics

Age works alongside defect rate, audit coverage, and time to fix. Together they show whether a program finds problems early, fixes the important ones first, and clears its history or just its inbox.

Report age in the same pack as counts, in plain language a non specialist executive can grasp: the oldest barrier on our checkout has been open 11 months and affects keyboard users at payment. That sentence has moved more budgets than any chart.

Frequently asked questions

How is issue age different from time to fix?

Time to fix is measured after an issue closes, so it only describes issues the team already handled. Issue age measures the ones still open, which is where neglected barriers live. A program can show fast fix times and terrible ages at the same time.

What is a reasonable age threshold for accessibility issues?

It depends on severity and capacity. Many teams use about 30 days for critical barriers, 90 for serious ones, and 180 or more for minor issues. The threshold matters less than escalating visibly when an issue crosses it.

Should old issues just be closed if they are minor?

Only if they are genuinely no longer valid: the page was removed, the component replaced, or retesting shows the barrier is gone. Closing old issues to improve the age metric without retesting is how audits later find barriers everyone assumed were history.

Who should see the issue age report?

The same leaders who see other quality metrics: product, engineering, and design leadership. Age becomes actionable when the people who control roadmaps see specific old barriers next to the features competing with them.