Measuring What Matters: A Quick Guide to Digital Accessibility Metrics

Author: Level Access

Your manager asks a simple question: Is your accessibility program working? And you’re struggling to find a clear answer.

You have dashboards, scan results, and a backlog that grows and shrinks from week to week. Still, the day-to-day data doesn’t always tell you what you really want to know—is accessibility actually getting better?

This guide is your roadmap to answering that question with confidence. We’ll cover what digital accessibility metrics actually measure, why they’re key to effective program management, and how to put a handful of them to work when you report up.

What digital accessibility metrics actually measure

Every accessibility metric starts from the same place: a baseline evaluation, often a full accessibility audit. During this evaluation, automated scanning and manual testing work together to surface issues, rate their severity, and record where each one lives. Most teams focus first on critical issues—the barriers most likely to block someone from completing a task.

Raw issue counts, though, can mislead you. The total number of issues scales with the size and complexity of your site, so comparing counts across pages or products rarely tells you much. A large site will almost always report more issues than a small one, even when it is in better shape.

Duplicate issues make raw counts shakier still. A single problem in a shared component might get flagged 10 times on one page and once on another. That’s still one issue to fix, not 11. This is why the metrics worth reporting track rates and trends—percentages, averages, and change over time—rather than static totals.

Why metrics matter: Closing the evidence gap

Consider the moment you report up. Maybe your organization received a demand letter, or a buyer requires a completed Voluntary Product Accessibility Template (VPAT®). Or maybe a new leader is helping put renewed focus on digital accessibility. Whatever the reason, you need to be able to paint a clear picture of how things are going—and that isn’t always as easy as stakeholders might assume.

We call this challenge the evidence gap. When you can’t demonstrate credible progress, it becomes hard to justify continued investment in accessibility or keep leadership on board. That’s why many programs stall after the first audit: they know their starting point, but they can’t show what happened next.

Metrics close that gap by letting you know whether you’re trending in the right direction—giving you an answer to your manager’s question, and helping you understand what to do next. A trend moving the right way is a sign to keep up your existing practices. A trend moving the wrong way can reveal what isn’t working, and where more tooling, training, or support are needed.

Five metrics that show real progress

You don’t need to track every possible metric to get a reliable read on your program’s performance. In fact, many teams struggle with the evidence gap not because data is missing, but because they have too much of it—and they aren’t sure how to stitch it together into a clear story. What matters is choosing the right set of metrics for your program, and reporting on them consistently.

The following five metrics are a strong starting point for most organizations trying to answer the question, “Is the work we’re putting into accessibility actually moving our program forward?”.

Accessibility health score over time

Your accessibility health score is a single number that summarizes the state of a representative sample of your site—or, if you want, the whole thing. The Level Access Platform re-evaluates your accessibility health on a schedule you choose (often weekly, biweekly, or monthly) and plots the score over time.

This gives you the clearest answer to, “Are we moving in the right direction?”. A score climbing from 80 to 84 over a few scans shows your changes are working. A flat or falling score is an early warning that fixes aren’t sticking, or that something is regressing.

Keep in mind that the score reflects a broad sample, so narrow fixes on a single page won’t move it much. That’s by design. The score rewards broad, high-impact work, so a stalled number doesn’t necessarily mean nothing is happening—your effort might just be aimed too narrowly.

New, newly violated, and reopened issues, scan over scan

Some reporting and analytics tools, like those in the Level Access Platform, compare your latest scan against the one before it and separate genuinely new issues from reopened ones—problems you already fixed that have surfaced again.

This insight answers a question every developer asks after a deployment: Did I actually improve things, or did I just trade one problem for another? If your critical count moved from 20 to 22, for example, knowing how many of these issues are new—and how many are reopened—tells you whether that’s because fixes aren’t holding, or teams are introducing new problems.

Reopened issues deserve special attention when you report up. In development terms, they represent regression—rework on something the team already spent time and money to fix. Managers understand that language immediately. A reduction in reopened issues shows that you’re not only fixing problems but holding onto the progress you’ve made.

Critical issue trend by severity

Total issue counts treat every problem as equal, but you know they’re not. What’s more helpful is to track issues by severity—critical, high, and low—over time, usually from a manual audit report.

The pattern matters more than any single number. If your low-severity count is dropping while critical issues stay flat, for example, that suggests effort is going toward easy wins instead of the errors that carry the most risk.

When reporting to leaders, it’s often helpful to frame progress in terms of risk reduction rather than sharing raw counts. “We cut critical issues in our checkout flow by half this quarter” carries more weight than “we closed 200 issues,” because it connects the work to real user impact, legal exposure, and / or procurement risk.

Wide-reaching duplicate issues

Some issues appear once. Others repeat across hundreds or thousands of pages because they stem from a single shared source. The Level Access Platform groups identical issues across your site—or across several sites—into one finding, ranked by how far each one reaches.

For a developer, this is where prioritization gets easier. Instead of working through a flat list of issues, you can find the one fix that clears the most instances at once. A single image issue impacting 2,000 pages is worth tackling before something that only affects one low-traffic page.

Reporting on duplicate issues can help you reframe an overwhelming issue total into a manageable story. “We have thousands of issues” becomes “a handful of root causes drive most of our issues, and here’s the order we’re addressing them in.”

Issues in reused components

Most sites are built from reused components: a button, a navigation bar, an account icon that loads on every page. When one of those components has an accessibility issue, that issue repeats everywhere the component appears.

By tracking issues at the component level, you can turn this from a source of frustration into an efficiency win. Fix the component once, and you resolve the issue across every page that uses it. Driving these counts toward zero clears repeated problems in bulk and is one of the fastest ways to move your health score or reach a conformance target.

Reaching zero component-level issues is also a key milestone in your progress story. It signals that systemic problems have been addressed.

How to put these metrics to work

Now that you understand what to track, how can you use these data points, practically, to strengthen your program? Here are a few tips.

1. Start with a baseline. You can’t measure change without a starting point, so obtain an initial evaluation before you set any targets.
2. Define your scope early. Decide what a monitor covers: the same representative sample each time for a consistent benchmark, a specific list of key pages, or an automatic crawl that captures new pages as you publish them.
3. Pick two or three metrics to start, not all five. Which ones depend on your program’s maturity and what your stakeholders are actually asking for. A team answering a demand letter might lead with duplicate issues and critical issue trends, while a team maintaining a mature site might track the health score and regression.
4. Report on a cadence. A weekly or monthly trend tells a story of progress over time; a one-time snapshot doesn’t. Reporting tools that let you choose which metrics to surface for each audience make this far easier to sustain across a portfolio, especially as your product grows and changes.

Measuring prevention

The metrics we’ve covered so far focus on the issues that already exist on your site—they’re reactive by nature. That’s the right place to start, especially early in a program when you’re working through a backlog. But as you build maturity, you’ll want to expand your focus to preventing issues before they go live. And that progress is important to track, too.

Catching issues in design, or in the continuous integration (CI) stage of development, lets you stop new and reopened issues before they ship. Monitoring production tells you what already broke; catching issues upstream keeps them from breaking at all. Ultimately, detecting issues earlier in the process turns the reactive loop into something you can get ahead of.

You can measure this the same way you measure everything else: track the volume and trend of issues caught before production, in design review or a CI check. A rising share of issues fixed before they ship—and fewer reaching your live site—shows leadership you’re getting ahead of risk rather than chasing it.

Metrics are the starting point, not the finish line

The right accessibility metrics allow you to turn a pile of scan data into a story you can defend—one that answers the question your manager keeps asking.

Remember what they are, though: tactical, day-to-day signals, not a complete picture of program maturity. Proving impact takes more than trend lines. You also need to connect these metrics to business outcomes and communicate them clearly to the people who fund the work.

And no amount of measurement fixes the underlying problem. If the same issues resurface release after release, the numbers only tell you it is happening. Breaking that cycle means catching issues earlier, in design and development, so they never reach production in the first place.

That’s where a broader reporting strategy comes in. To turn these metrics into a complete, repeatable way of proving your program’s progress, explore the Accessibility Reporting Playbook.