How to Prioritize Accessibility Fixes by Revenue Impact

The day after a company runs its first accessibility audit is usually the day accessibility dies there. Not because the audit found nothing, but because it found two hundred things. The report lands as a wall of issues, each tagged with a severity level and a WCAG criterion, the team stares at it, fixes a few easy ones, and the file quietly joins the graveyard of well-intentioned PDFs. The problem isn’t motivation. It’s that the report is sorted wrong.

Audit tools sort by severity, and severity in these tools means how badly the issue violates the standard, considered in isolation. That’s a reasonable thing for a tool to measure and a useless thing to sort a backlog by, because it omits the variable a business actually runs on: where the issue sits. A “critical” contrast failure in your site’s footer legalese and a “moderate” label problem on your checkout’s card-number field get similar-looking flags, and they could not matter less similarly. Nobody’s purchase depends on reading the footer. Every purchase depends on the card field.

So here’s the reframe I’d propose: sort by position on the path to money. Every site has such a path. For an online store it runs from landing page to product page to cart to checkout to confirmation. For a SaaS product it’s landing, pricing, signup, first login. For a lead-gen site it’s landing, service page, contact form. Take your analytics, identify that spine of five or six pages, and split your audit findings into two piles: issues on the spine and issues off it. Fix the spine pile first, essentially regardless of severity labels. A blocking bug on a page nobody must visit is an embarrassment. A minor bug on the page where money changes hands is a leak, and leaks compound with traffic.

Within the spine, one more distinction does most of the remaining work: does the issue block or merely burden? A blocker makes the step impossible for some group. The submit button a keyboard can’t reach, the form field a screen reader announces as an unlabeled edit box, the error message that only manifests as a red border, the modal that traps assistive technology behind an overlay. For the affected user the funnel doesn’t leak, it’s severed, and every one of those users converts at exactly zero. A burden makes the step harder but survivable: low contrast, vague link text, a missing heading structure. Burdens cost you some fraction of affected users; blockers cost you all of them. Blockers on the spine are your first page of the new backlog, and there’s a bright side hiding in this: that page is short. Companies that can’t imagine resourcing two hundred fixes can resource nine, and the nine carry most of the money.

Notice what this framing quietly does to the economics. The forms and buttons on your revenue path are a tiny fraction of your site’s surface, so the cost of fixing them is small and bounded, while carrying all of the transactional traffic, so the return is concentrated. Accessibility work sorted by severity feels like an endless tax. Sorted by position, the first tranche looks like what it is, conversion-rate work for a customer segment you’re currently turning away at the door. And that segment is larger than intuition suggests. Disability in the broad sense, vision, motor, cognitive, hearing, permanent and temporary, touches a substantial share of any customer base, and their money is denominated in the same currency as everyone else’s. You don’t need a precise number to act on this; you need only notice that the number is not small and the fix list is.

There’s an honest objection to answer. Doesn’t this mean the off-spine issues, the ones affecting real people on less-traveled pages, never get fixed? In the world where you sort by revenue, they get fixed later. But compare that to the actual alternative, which is the world where the report dies whole and nothing gets fixed ever. Prioritization isn’t the enemy of completeness; paralysis is. Teams that ship the first nine fixes and watch the checkout complete for a screen reader user tend to keep going, partly because the second tranche now looks tractable and partly because someone on the team has, by then, actually experienced the site through assistive technology, and that experience does more for the roadmap than any severity label. Momentum is a strategy.

This ordering is baked into how I think about GazeSite’s reports. A finding’s placement matters as much as its category: an issue flagged on a checkout form should read as urgent in a way the same issue in a footer doesn’t, because the site owner’s scarce resource is attention, and attention pointed at the wrong fix is spent all the same. The compliance frame asks how far you are from zero issues, and the answer is always “far,” which is why the frame demoralizes. The revenue frame asks a different question: of the people trying to give you money right now, who can’t, and what’s the shortest list of changes that lets them? Answer that question first. The rest of the report will still be there next sprint, and for the first time, so will your momentum.