Measuring accessibility performance over time requires tracking real audit data, not scan scores. The most reliable metrics are open versus closed issues by severity, remediation velocity, WCAG conformance rates by success criterion, and the percentage of templates or components that have been validated. These data points come from (manual) audits and organized tracking, not from automated checkers that only flag approximately 25% of issues. Performance improves when teams reduce high-severity issue counts, shorten the time between identification and validation, and maintain conformance as new content ships.
| Metric | What It Tells You |
|---|---|
| Open vs. closed issues | Current accessibility debt and remediation progress |
| Issues by severity | Risk exposure and user impact priority |
| Remediation velocity | How quickly teams fix identified issues |
| WCAG conformance by criterion | Which success criteria are passing, failing, or partial |
| Validated components | Percentage of reusable elements confirmed accessible |
| Recurrence rate | Whether old issues are returning in new releases |
Start With a Baseline Audit
You cannot measure change without a starting point. A full (manual) accessibility audit against WCAG 2.1 AA or WCAG 2.2 AA produces the baseline dataset every future metric depends on.
The audit report identifies each issue, maps it to a specific success criterion, notes the location, and assigns a severity rating. That structure is what makes measurement possible later. A scan cannot produce this baseline because it misses roughly three-quarters of real issues.
Once the baseline exists, every subsequent data point becomes comparable. An accessibility audit at the start of the project gives you the reference line that every later measurement moves against.
What Metrics Actually Reflect Progress?
Not every number is a performance indicator. Some metrics look informative but do not track real accessibility outcomes.
These are the metrics that matter:
Open critical and high-severity issues: The count that most directly reflects legal and user risk.
Time to remediation: Days between issue identification and developer fix.
Time to validation: Days between fix and auditor confirmation that the fix is correct.
Conformance rate per success criterion: Percentage of pages or screens passing each WCAG requirement.
Regression count: Number of previously closed issues that reappear in a new release.
Scan scores are not on this list. A scan score of 95 can coexist with dozens of serious issues a scan is not designed to detect.
Track Issues in a Structured System
Spreadsheets work for small projects. Larger digital assets need a platform that connects audit findings, developer fixes, and auditor validation in one place.
The Accessibility Tracker Platform was built for this. It takes audit data and turns it into trend lines, severity breakdowns, and project-level reporting. The goal is visibility: leadership can see progress, developers can see what is assigned to them, and auditors can see what is ready for validation.
Whatever system you use, the data structure matters more than the tool. Each issue needs an ID, a WCAG reference, a severity, a status, an assignee, and a history of state changes.
Measure Remediation Velocity
Remediation velocity is the rate at which identified issues move to a closed state. Teams that track this number can predict when a digital asset will reach full conformance.
Calculate it by dividing the number of closed issues in a period by the total days in that period. A rising velocity over successive months shows the team is gaining efficiency. A flat or declining velocity signals resource or prioritization problems.
Pair velocity with severity. Closing ten minor issues is not the same as closing ten critical ones. Weight the metric so that high-severity closures count more heavily toward progress.
Monitor Conformance at the Criterion Level
Rolling up accessibility into a single percentage hides the detail decision-makers need. A criterion-level view shows exactly which WCAG requirements are holding the product back.
For example, a dashboard might show 1.1.1 Non-text Content at 92% conformance, 1.4.3 Contrast at 78%, and 2.4.7 Focus Visible at 65%. That granularity tells the team where to concentrate effort. Aggregate numbers cannot.
Review this breakdown quarterly. Patterns emerge over time, and recurring weak criteria often point to a training or design-system issue that needs systemic attention.
Re-Audit on a Defined Cadence
One baseline audit is not enough. Digital assets change constantly, and accessibility status changes with them.
A reasonable cadence for most organizations is an annual full audit plus targeted audits after major releases or redesigns. Some regulated industries benefit from a more frequent schedule. The remediation process after an audit is where most measurable gains happen, so timing the next audit to follow a completed remediation cycle produces the cleanest comparison data.
Each new audit adds a data point to the long-term trend. Over a few years, you build a record that shows whether accessibility is genuinely improving or slipping.
Connect Performance to Business Decisions
Metrics only matter if they inform decisions. Accessibility data should feed into release planning, design-system updates, training priorities, and vendor selection.
A product team that sees repeated contrast issues can update its design tokens. A procurement team that sees recurring vendor issues can require an ACR before the next contract. Leadership that sees a rising open-issue count can approve additional remediation resources.
Accessible.org Labs is actively researching how AI can support this analysis, helping teams spot patterns across audit data faster and prioritize issues with better context.
Frequently Asked Questions
How often should we measure accessibility performance?
Review issue tracking data weekly during active remediation. Review criterion-level conformance monthly. Conduct a full re-audit annually or after any major release that changes a significant portion of the digital asset.
Can a scan replace an audit for performance tracking?
No. Scans detect approximately 25% of issues and cannot determine WCAG conformance. Using a scan score as a performance metric creates a false sense of progress because most real issues stay invisible to the tool.
What is a realistic timeline to see measurable improvement?
Most teams see meaningful reductions in high-severity issue counts within three to six months of a baseline audit, assuming developer capacity is assigned to remediation. Full conformance on a large digital asset typically takes twelve months or more.
Which single metric best represents overall accessibility performance?
There is no single number. If forced to pick one, open critical and high-severity issues per page or screen is the closest proxy for real-world risk and user impact.
Performance measurement works when the data comes from real audits, the tracking system preserves history, and the metrics connect to decisions leadership actually makes.
Contact Accessible.org to discuss an audit and tracking setup that fits your digital asset: Contact our team.
