Accessibility Issue Aging: The Metric That Shows Whether Remediation Is Real

2026-10-19

Most accessibility dashboards lead with counts: issues opened, issues closed, issues remaining. Counts are easy to move in the wrong direction, by logging splits, deferring hard items, or closing duplicates, while the experience for disabled users barely changes.

Aging asks a harder question: how long does a barrier live once you know about it? A critical checkout barrier that lives for six months is a policy outcome, whatever the count chart says, and aging makes that visible to the people who set priorities.

Define aging so it cannot be gamed

Age should run from the date an issue was first recorded, in any system, to the date a fix was verified in production by retest. Not from triage, not from assignment, and not to the date a pull request merged. Each of those easier endpoints shaves weeks off the number without helping a single user.

Keep reopened issues honest too: a fix that fails retest continues the original clock rather than starting a new issue with a fresh age. Otherwise the oldest, hardest problems, the ones that fail fixes, look perpetually young in the report.

Report aging by severity, in percentiles

A single average age hides the distribution that matters. Report median and 90th percentile age for open and closed issues, split by severity. A healthy program might show minor issues closing in weeks at the median, while the 90th percentile for critical issues is the number leadership should see first.

Open issue aging deserves its own view: the current age of everything still unfixed, oldest first. That list, reviewed regularly, becomes the triage agenda. An open critical issue older than its limit should require an explicit decision, not silent drift.

Set aging limits as policy, not aspiration

Aging becomes useful when limits exist: for example, critical barriers fixed within 30 days, major within 90, minor within a release cycle or two. The exact numbers matter less than that they are agreed in advance, by severity, with product and engineering leadership at the table.

When an issue crosses its limit, the process should trigger something specific: escalation to a named owner, a slot in the next sprint, or a documented risk acceptance signed by someone senior enough to own it. Limits without consequences are decoration.

Pair aging with inflow to see the whole system

Aging alone can be flattered by slowing intake, running fewer audits or discouraging reports. Pair it with inflow: how many new issues are found per month, by source. Rising finds with falling aging is a healthy system. Falling finds with falling aging may mean the program stopped looking.

That pairing also protects audit and testing teams, whose good work temporarily worsens the count metrics. Aging reframes their finds properly: a newly found two year old barrier is a discovery success and a remediation clock starting, not a failure of the team that found it.

Frequently asked questions

What is accessibility issue aging?

The time from when a barrier is first recorded to when its fix is verified in production. It is usually reported by severity as median and 90th percentile days.

Why is aging better than issue counts?

Counts can improve while serious barriers sit untouched. Aging shows how long users actually live with known barriers, which is what remediation policy should control.

How should aging limits be set?

By severity, agreed with product and engineering leadership: short limits for critical barriers, longer for minor ones, with a defined escalation when a limit is crossed.

Can aging metrics be gamed?

Yes, by restarting clocks at triage or treating failed fixes as new issues. Count from first recording to verified fix, and keep the original clock on reopens.