Should accessibility alerts go to the developer or the store owner first?

Every accessibility alert has two audiences: the person who can fix it and the person who owns the risk. Routing every alert to both trains everyone to ignore them.

The alert has two jobs, and they conflict

An accessibility alert carries a technical job and a business job. The technical job is getting the right details to the person who can ship the fix: which page, which rule, the reproduction steps. The business job is telling the owner something changed about their risk: a checkout barrier appeared, a regression slipped in with the new theme section. These are different messages, and sending the same alert to both people serves neither.

The common failure mode is routing everything to everyone. The developer gets fifty alerts and learns to mute the channel. The owner gets fifty alerts, understands none of them, and stops opening them. Within a month the monitoring might as well not exist. Routing is not an administrative detail. It is the difference between a system that works and a system that gets muted.

Route by severity, not by topic

The routing rule that holds up in practice is severity-based. Critical alerts, anything blocking checkout, account access, or payment, go to the developer immediately and to the owner as a same-day summary. High alerts go to the developer in the daily digest and to the owner in the weekly summary. Everything below that goes to the developer only, aggregated, and the owner never sees it unless it trends upward.

Severity routing has a side benefit: it forces the monitoring setup to define severity honestly. If everything is critical, the rule collapses. Teams that route by severity end up with better alert definitions, because a sloppy severity scheme immediately announces itself through misrouted alerts.

The developer gets the fix kit, the owner gets the risk line

What each audience receives should differ in content, not just in timing. The developer gets the fix kit: the failing page, the rule violated, the exact element, reproduction steps, and the last known good state so they can diff. The owner gets the risk line: what broke, who it affects, how long it has been broken, and whether it is already being fixed.

The risk line should never contain rule codes. WCAG 2.4.7 means nothing to a founder; "keyboard users cannot reach the checkout button since Tuesday" means everything. Translate once, at the routing layer, and the owner stays engaged without needing a crash course in the standard.

Someone has to own the routing table

Routing tables rot. The developer who received checkout alerts leaves the agency, the new hire never gets added, and critical alerts go to a dead inbox for three months. Name one person as the owner of the routing table and put a quarterly review on the calendar. The review takes ten minutes: confirm every recipient, confirm every severity definition, remove the people who left.

This is also the moment to check for alert fatigue directly. Ask each recipient how many alerts they opened last month. If the answer is none, the routing is wrong, the severity definitions are wrong, or the channel is wrong. Do not wait for a missed critical alert to discover it.

Escalation is the part everyone forgets

An alert that nobody acknowledges is worse than no alert, because it creates the illusion of coverage. Define escalation up front: a critical alert unacknowledged for four business hours escalates to the owner and the agency lead. A high alert unacknowledged for three days escalates to the weekly owner summary with a red flag.

Escalation needs to be automatic, not a favor someone does. Manual escalation relies on someone noticing the unacknowledged alert, which is the same attention the system is supposed to replace. Build the timer into the monitoring tool or the routing automation, and test it quarterly with a synthetic alert.

The test: would a missed alert surprise anyone

The routing is working when a missed alert is a genuine surprise. If alerts get missed routinely and nobody notices, the system has already failed socially even if it works technically. Once a quarter, ask the owner to describe the store current accessibility state in their own words. If what they describe matches the monitoring data, the routing did its job. If they are guessing, the alerts are landing in the wrong place.

Frequently asked questions

Should accessibility alerts go to the developer or the owner first?

To whoever can act on that class of alert, with the other informed. Structural template issues belong with developers, content issues with the people who publish content. Routing everything to one inbox guarantees half of it waits.

What goes wrong when all alerts go to the store owner?

Owners become a bottleneck and a filter. Technical alerts sit unread while commercial ones get actioned, and developers learn about regressions weeks later from a forwarded summary instead of at detection.

How should routing be decided?

By alert type, agreed in advance and written into the monitoring setup: component and template findings to development, page content findings to the content owner, checkout findings to both immediately.

What makes an alert actionable rather than noise?

A named component or page, the barrier in plain language, when it was first seen, and what changed nearby. Alerts with those four facts get fixed. Alerts without them get triaged, which usually means deferred.