What belongs on an accessibility alert dashboard?
An accessibility alert dashboard should answer exactly three questions: what broke, how bad is it, and who owns it. Everything else, trend charts, composite scores, raw rule dumps, is noise that slows the response. A dashboard that fits on one screen and gets someone to act in two minutes beats a comprehensive one that nobody opens.
Start with the three questions
Every alert on the dashboard must answer three things at a glance. First, what broke, in plain language: not "WCAG 4.1.2 violation on element div#x" but "the checkout's payment button has no accessible name." Second, how bad is it: a severity that maps to user impact, not to the rule's technical category. Third, who owns it: a named person or team, not a department. If any alert on the dashboard cannot answer all three, the dashboard is a list of worries, not a tool.
This sounds obvious and is rarely done. Most dashboards show what the scanner found, which is scanner-centric, not response-centric. Design from the responder's point of view: they arrive at 9 AM to twelve new alerts and need to know which one ruins someone's checkout today. Build backward from that moment.
One severity scale, not five
Dashboards die by severity inflation. Critical, high, medium, low, informational, each scanner with its own scale, and within a month everything is "critical" and nothing is. Pick one scale with three levels and define each in user terms. Blocking: a user cannot complete a core task. Degraded: a user can complete the task but with real friction. Minor: an issue that affects few users or has an easy workaround. Three levels, no more, and a short written definition for each that the whole team can repeat.
Audit the scale quarterly. If ninety percent of alerts land in one level, the scale is lying. Severity creep is a sign the team stopped trusting the dashboard, and the fix is recalibration, not more levels.
Group by cause, not by rule
A theme update that breaks color contrast will generate forty alerts, one per element. Listing all forty teaches nothing and buries the one action that fixes them all: revert or fix the theme change. Group alerts by probable cause, and show the cause as the unit of work. The dashboard should read "one theme change broke contrast on 40 elements" with the list expandable, not forty identical-looking rows.
Cause grouping is also how you stop alert fatigue. Responders drown in rows and starve for patterns. The pattern is the fix. Any dashboard that cannot show you the pattern is making each incident look bigger and each fix look smaller than they are.
Make ownership visible, not implied
Every alert needs a named owner, and the dashboard should show that name. "The dev team" is not an owner. "Priya" is. Ownership should be assigned by area: checkout alerts go to the checkout owner, theme alerts to the theme owner, content alerts to the content owner. When ownership is visible on the dashboard, alerts get claimed faster, because nobody wants their name sitting next to an aging red row.
Rotate a single on-call for the unowned. Some alerts will not fit any area. Instead of letting them rot, give the week's on-call person the job of triaging them within a day. Unowned alerts are how dashboards accumulate the stale rows that make everyone stop trusting the whole thing.
What to leave off the dashboard
Keep the dashboard ruthless about exclusion. Trend graphs belong in the monthly review, not on the response screen. Composite accessibility scores belong in executive summaries, not where responders work; a score of 94 tells nobody what to fix. Raw rule lists belong in the scanner's export, linked but not displayed. The dashboard is for action, and every pixel that does not lead to action is friction.
The same goes for resolved alerts. Archive them, do not display them. A dashboard showing six months of green checkmarks is a trophy case, not a tool. The only history a responder needs is "did this break before," which belongs one click away on the alert detail, not on the main screen.
Keep a quiet log for the patterns
Everything you excluded from the dashboard still has value, just not at response time. Keep a quiet log: every alert, its cause, its fix, its time to resolution. Once a month, read the log for patterns. If the same app breaks the same rule every month, the fix is not another alert, it is a policy: spot-check that app before every update. The log turns incidents into prevention, which is the only way alert volume ever goes down.
This is also where you measure honestly. Time from alert to acknowledged, time from acknowledged to fixed, recurrence rate. Three metrics, reviewed monthly. If they are not improving, the problem is not the dashboard, it is the process around it, and no redesign will fix that.
Review the dashboard itself quarterly
Dashboards rot. Severities drift, ownership goes stale when people change roles, new alert types appear that fit none of the groups. Once a quarter, spend an hour with the actual responders and ask three questions: what do you ignore, what do you wish it showed, what takes too long to find. Then change it. A dashboard is a living tool, and the quarterly review is its maintenance.
The goal is not a perfect dashboard. It is a dashboard the team trusts enough to open every morning. Trust comes from accuracy, brevity, and the visible evidence that alerts on it get fixed. Design for that, and the rest follows.
Frequently asked questions
What belongs on an accessibility alert dashboard?
The things someone must act on: new barriers by severity, the pages and components affected, regressions since the last release, and ageing unresolved items. Raw scan counts without severity or ownership are decoration, not a dashboard.
Who should the dashboard be designed for?
For the people who fix things and the people who fund fixing them, which usually means two views: a working view for practitioners and a summary view showing trend and risk for owners. One view serving both usually serves neither.
How often should dashboard data refresh?
Often enough that a regression is visible before the next release ships, which for most stores means scans tied to deploys and at least weekly. A monthly dashboard reports history. A deploy linked one prevents it.
What is the most misleading dashboard metric?
A single accessibility score. Scores hide which barriers exist and whether the worst ones moved. A dashboard should lead with the severe open items and their age, and let the score be the last number on the page.