Building a WCAG Metrics Dashboard People Actually Read

2026-10-25

Every organization of a certain size has an accessibility dashboard, and most are graveyards: dozens of charts, updated monthly, read by no one, driving nothing. The problem is rarely the tooling. It is that the dashboard was built to demonstrate activity rather than to run a program.

A dashboard people actually read is brutally selective. It answers three questions at a glance: are we getting better, where is the risk concentrated, and what needs a decision this week. Everything else belongs in a drill down, not on the front page.

Choose decision metrics, not vanity metrics

Total pages scanned and total issues found measure effort, not outcomes. Replace them with trends that carry a decision: critical issues opened in new releases, median days to close by severity, and the share of top user journeys with a current audit.

Each metric needs an owner and a threshold. When median closure time for critical issues crosses thirty days, something specific should happen. A number without a consequence attached is just trivia with a chart.

Show conformance by template, not by page average

Averages hide the template that generates hundreds of broken pages. Reporting by template or component shows leadership the leverage: fix one template and the conformance of a whole section moves. That framing turns accessibility from janitorial work into engineering.

It also assigns responsibility cleanly. Template owners can see their own trend and compare it with peers, which creates the healthy pressure that a single global percentage never does.

Keep the audit data honest

Automated scan scores flatter every site, because automated tools catch only part of WCAG. Label clearly what portion of the dashboard is automated and what comes from manual testing, or the dashboard will report success while real barriers persist.

Date every figure. A conformance number without an audit date quietly becomes fiction as the site changes. Stale metrics presented as current are worse than no metrics, because they close questions that are still open.

Design the weekly habit

Put the dashboard where the team already looks, in the same review as release and quality metrics, and keep the front page to one screen. A dashboard that needs a special meeting to be seen will not be seen for long.

Review exceptions, not everything. If the only agenda is what crossed a threshold and what changed since last week, the meeting stays short and the dashboard stays alive.

Frequently asked questions

How many metrics should an accessibility dashboard show?

Few enough to fit one screen and be reviewed weekly, usually four to six front page metrics. Each should have an owner and a threshold that triggers action. Detail belongs in drill downs, not on the front page.

Why report conformance by template instead of overall?

Because one broken template can generate hundreds of failing pages, and the fix is at the template level. Template reporting shows where the leverage is and gives each owner a clear, comparable trend.

Can automated scan scores be the main dashboard metric?

No. Automated tools detect only a portion of WCAG issues, so their scores overstate conformance. Use them as one input, labeled clearly, alongside manual audit results for key user journeys.

How often should dashboard data be refreshed?

Automated figures can refresh continuously, but manual audit figures should carry their audit date and be updated on the audit cycle. Presenting stale manual results as current is a common way dashboards lose credibility.