What belongs in an accessibility alert severity scale, and what does not?
Severity for accessibility alerts should be based on user impact and legal exposure, not on the technical impressiveness of the finding. A keyboard trap on the checkout page outranks everything. A missing alt attribute on a decorative blog image ranks near the bottom. Most teams have this backwards because they borrowed a security severity model that was built for a different job.
The security model does not fit
Security severity asks: how bad is the exploit, and how exposed is the asset? That question assumes an adversary. Accessibility has no adversary, only users who cannot complete tasks. When teams copy the P1-to-P4 ladder from their security playbook, they end up ranking findings by technical cleverness. A complicated ARIA bug on an internal admin page becomes a P2 because it looks serious in the scanner output, while a missing label on the payment form sits at P3 because the fix looks trivial.
The ranking should follow the user's path, not the scanner's confidence. The most severe accessibility finding is the one that blocks the task the business cares about most. On a store, that is checkout, account creation, and the search that gets shoppers to products. A barrier on those flows is severe no matter how simple the fix. A barrier on a page nobody visits is minor no matter how exotic it looks. This feels obvious stated plainly, but almost nobody's alert config reflects it, because the config was written by someone who never watched a screen reader user try to buy something.
A severity scale that actually works
Start with three questions for every finding. First, does it block a critical task? Second, does it affect a page with legal exposure, meaning a page a plaintiff's expert would test first? Third, is it a regression, meaning the site used to be fine and something broke it? A finding that answers yes to the first two is your highest severity. A finding that answers yes to the third deserves a bump, because regressions mean the release process failed, not just the page.
The practical scale most teams land on has four levels, but the definitions are what matter. Critical: blocks checkout, account, or core navigation for assistive technology users, and it pages the on-call. High: fails WCAG on a high-traffic or high-exposure page but does not fully block the task, and it lands in the sprint. Medium: real failures on secondary pages, batched weekly. Low: best-practice improvements and decorative issues, reviewed monthly. Notice what is missing: no level is defined by the scanner's severity string, because scanner severity strings are written for scanner vendors.
Write the definitions down and make everyone use them. The failure mode of every severity scale is not the scale itself, it is the drift: the developer who marks their own finding low to avoid sprint pressure, the manager who escalates everything to high to look diligent. A written definition with examples from your own site is the only thing that stops the drift. Include two examples per level from real findings on your own storefront, so there is no argument about what high means.
What should never page anyone
Almost nothing in accessibility should page anyone at night. This is the hardest sell in the whole severity conversation, because the team that built the alerting pipeline wants every finding to feel urgent, and urgency feels like importance. But accessibility findings are not incidents. A contrast failure discovered at 2am is the same contrast failure at 9am. Paging someone does not make the fix happen faster; it makes the team resent the alerting system, which is how alerting systems get muted.
The only legitimate page is a deployment-caused regression on a critical flow during a release window, and even that should go to the release owner, not the whole on-call rotation. Everything else can wait for morning. Teams that accept this end up with faster remediation, not slower, because the alerting system keeps its credibility. The team that gets paged for alt text stops reading alerts. The team that gets a clean, prioritized queue every morning fixes things.
One more thing that does not belong in the severity scale: the client-facing summary. Severity is an internal operations tool. When you report to the client, translate it into plain language: what is broken, who it affects, and when it will be fixed. Sending a client a P2 with a CVSS-style score invites exactly the wrong conversation. Keep the scale inside the team, and let the client see the work, not the machinery.
Frequently asked questions
What belongs in an accessibility alert severity scale?
Impact on the shopper and the task affected: whether a barrier blocks a purchase, slows a key task, or is cosmetic. A good scale ties each level to a response time and an owner, so severity is a decision, not just a label.
What does not belong in a severity scale?
Scanner rule names and raw counts. A page with thirty minor findings is usually less urgent than one finding that blocks checkout. Scales built on counts alone send teams to fix the easy pile instead of the important one.
How many severity levels should a scale have?
Three or four is enough for a store team: blocker, major, minor, and sometimes informational. More levels than that create arguments about classification instead of faster fixes.