Routing Accessibility Alerts to the Person Who Can Fix Them
An alert nobody owns is a diary entry. How to route accessibility findings by surface and skill so fixes happen instead of acknowledgements.
Stores rarely suffer from too few accessibility alerts. They suffer from alerts that arrive in a shared channel, get acknowledged by whoever is awake, and die there. The finding was real, the tooling worked, and nothing changed, because the alert never reached the one person who could fix it with the authority to drop something else.
Routing is the unglamorous layer that decides whether monitoring produces fixes or archives. This guide covers routing by surface, by skill, and by severity, plus the escalation path for alerts that age unowned.
Route by surface, not by tool
Organize routing around the parts of the store: theme templates, app rendered widgets, checkout extensions, and published content. Each surface has a different fixer. Theme findings go to whoever develops the theme. App findings go to the vendor manager with a ticket template attached. Content findings go to the merchandising or content owner.
A single alerts channel forces a human to do this sorting at 9 AM with coffee, which means it happens slowly or not at all. Configure the split in the tool: findings tagged by surface, each surface with a destination. The goal is that no alert ever needs a person to decide whose problem it is. That decision is made once, in configuration, and applied forever.
Match the fix to the skill
Some findings are code: focus order, labels in markup, keyboard traps. Some are configuration: an app setting, a banner timing choice. Some are content: alt text, heading order in a page the team published, a PDF nobody should have uploaded. Sending a content problem to a developer queues it behind sprint work it will never win. Sending a code problem to a content editor produces a polite 'not sure what to do with this' and silence.
Write the routing table down and review it when the team changes. The table is small, a dozen rows, but it is the difference between a monitoring program and a monitoring performance. When a new surface appears, a new app class, a new sales channel, add its row the same week.
Severity decides the clock, not the channel
Route and urgency are separate axes. A critical finding on a low traffic surface still outranks a minor finding on the homepage, because critical means a group of shoppers cannot complete something. Give each severity a response clock: critical acknowledged same day with a fix or a disable decision, major into the next work cycle, minor into the backlog digest.
Publish the clocks where the team can see them and report against them monthly. Nothing improves routing like a simple number: median time from alert to fix, by severity. Teams that see the number route better, because the cost of a bad route stops being abstract.
Escalate aging alerts automatically
Every routing system needs a failure mode for itself. If an alert passes its clock unacknowledged, it should escalate: to the surface owner's lead, then to whoever owns the accessibility program. Escalation is not blame. It is the system admitting that the first route failed and trying a louder one.
Track escalations as routing bugs. An alert that escalated because the owner was on leave means the table needs a deputy. One that escalated because nobody understood it means the alert needs better context. Fix the table, not the person, and the escalations get rarer for structural reasons.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Setting Alert Thresholds So One Template Bug Does Not Flood the Channel, Accessibility Alerts for Payment Widgets and Third-Party Checkout Frames, and How to Test an Accessibility Alert Before You Trust It.
Frequently asked questions
What is the most common routing mistake?
Sending every alert to one shared channel and relying on someone to sort them. Sorting is a configuration decision that should be made once, by surface, with a named destination for each. Alerts that need a human triage step before they have an owner mostly die in that step.
How fast should a critical accessibility alert be handled?
Acknowledged the same day, with a fix or a deliberate disable decision for blockers on purchase paths. The exact clock matters less than having one, publishing it, and reporting against it. A severity without a clock is a label, not a priority.
What should an alert contain to be routable?
The surface it came from, the page or template, the rule or failure in plain language, a screenshot or reproduction steps, and the suggested owner. Alerts that arrive as raw scanner codes force the reader to translate before they can act, and translation time is where alerts go to age.
What happens when an alert has no clear owner?
It escalates on a clock to the accessibility program owner, and the gap gets fixed in the routing table. Unowned categories are table bugs: a new surface, a departed teammate, a renamed team. Treat each escalation as maintenance the system is asking for.