Three hundred and forty findings. That's the number sitting in the audit report your team just opened, and someone in the meeting has already said the words "we should just start over."
Take a breath before you agree with them. That instinct — burn it down, rebuild it right — is one of the most expensive decisions a team can make on incomplete information, and findings count alone is almost never enough information.
The Scenario You're Probably Living Right Now
Picture a mid-market SaaS company with a five-year-old marketing site and a customer dashboard built on top of it. Nobody thought about accessibility when it was built. A demand letter arrived, or a customer complained, or someone in legal finally asked "are we compliant?" — and now there's an audit report with 340 line items and a Slack channel full of nervous energy.
The knee-jerk reaction is to treat 340 as a proxy for "the whole site is broken." It isn't. It's a proxy for "the audit did its job thoroughly." Those are very different things, and confusing them leads teams into a rebuild that costs 10x what fixing the actual problem would have cost.
Why 340 Findings Is Rarely 340 Problems
Here's what almost nobody tells you about accessibility audit reports: a large share of the findings are usually the same handful of root-cause patterns, repeated across dozens or hundreds of pages.
A missing <label> on your contact form field isn't one bug — it's one bug that your CMS template replicates on every page that uses that form component. A brand color token that fails contrast isn't one bug — it's one token used in hundreds of instances of the same button. Fix the pattern once, at the component or template level, and the finding count can drop by dozens or hundreds in a single commit.
This is the single most important thing to understand before you make a remediate-vs-rebuild decision: findings count measures thoroughness, not architecture. A brilliant, meticulous audit on a fundamentally sound site will still surface a long list of individual instances. Don't let the length of the list make the decision for you.
The Question That Actually Matters
Instead of asking "how many findings are there," ask this: are the findings mostly attribute-level, or mostly structural?
Attribute-level and pattern-level findings look like this: missing form labels, insufficient color contrast, missing alt text on images, inconsistent or invisible focus states, a heading level skipped here and there. These are targeted, well-understood fixes. They don't require touching how the site is built — they require going into existing, semantic HTML and correcting specific attributes and styles.
Structural findings look very different: custom-built "buttons" and "links" made entirely of <div> elements with no keyboard support, no real heading hierarchy anywhere on the site, custom dropdown and modal widgets with zero accessible foundation, a component architecture that actively fights how screen readers and keyboard users expect to navigate. When these dominate the findings list, you're not looking at a punch list — you're looking at a site that was never built on an accessible foundation to begin with.
This distinction is the real diagnostic, and it's one your audit provider should be answering explicitly, not leaving you to infer from a spreadsheet.
When Remediation Wins
If your site is built on genuinely semantic HTML — real <button> and <a> elements, a sensible heading structure, native form controls — with gaps that are fixable in place, remediation is almost always faster, cheaper, and lower-risk than a rebuild.
Under the Web Content Accessibility Guidelines, most of the highest-frequency issues fall into exactly this bucket. 1.1.1 Non-text Content (missing alt text), 1.4.3 Contrast (Minimum) (insufficient color contrast), 3.3.2 Labels or Instructions (missing form labels), and 2.4.7 Focus Visible (missing focus indicators) are all attribute- and style-level fixes. None of them require re-architecting a page, let alone a site.
WebAIM's annual WebAIM Million evaluation of the top one million home pages has repeatedly found that the vast majority of sites — in recent years around 95-96% — have detectable WCAG failures, with low-contrast text and missing alternative text consistently among the most common (WebAIM: The WebAIM Million). In other words: having a long list of these findings doesn't make your site an outlier. It makes it typical. And typical, pattern-level findings are exactly the kind that remediate quickly.
The Stat: WebAIM's annual evaluation of the top 1,000,000 home pages has repeatedly found that around 95-96% have detectable WCAG failures, with low-contrast text and missing alt text among the most common issues found. If nearly every site has these problems, the presence of findings tells you almost nothing about whether you need a rebuild. (Source: WebAIM: The WebAIM Million)
When Rebuild Is the Honest Answer
Sometimes the audit comes back and the real story is architectural. If your site relies extensively on non-semantic markup — everything is a styled <div>, there's no real heading structure to correct because there was never a heading structure, and your custom UI components have no keyboard or screen-reader support baked in anywhere — remediation stops being a punch list and starts being a rebuild in disguise.
In that scenario, trying to "fix" the existing structure piece by piece can genuinely cost as much as, or more than, building it correctly from scratch — because so much of the required work is architectural rather than incremental. You're not correcting attributes on solid bones; you're replacing the bones one at a time while the building stays occupied. At some point, that stops being the economical path.
The Hybrid Path Most Teams Miss
Here's the false choice that traps most teams: "we either fix everything now, or we plan a rebuild and do nothing for a year." Neither extreme serves you well, and there's a well-worn middle path.
Remediate your highest-risk, highest-traffic flows immediately — the specific pages named in a demand letter, your primary checkout or signup path, your login flow. These are the pages most likely to trigger a complaint and most valuable to your business, so they get fixed on a compressed timeline regardless of your longer-term plans. In parallel, scope and plan a longer-term rebuild or platform migration for the rest of the site, where structural debt makes incremental fixes inefficient.
This hybrid approach matters more than it might seem, given the current legal climate. UsableNet's annual ADA Digital Accessibility Lawsuit Report has tracked several thousand federal ADA website lawsuits filed per year in the U.S. in recent years, with plaintiffs' firms increasingly sending pre-suit demand letters as well as filing suit (UsableNet). Retail and ecommerce sites are consistently reported among the most-sued industries in these annual reports (UsableNet). If you're in a high-exposure category, the pages that matter most legally and commercially shouldn't wait for a twelve-month rebuild roadmap to finish.
Remediate vs. Rebuild — Quick Decision Table
| Signal in the audit | Points toward | Why |
|---|---|---|
| Findings are mostly missing labels, alt text, contrast, focus states | Remediate | Attribute/style-level fixes on a sound structure |
| Findings are mostly repeated patterns across templates/components | Remediate | Fix once at the component level, count drops fast |
| Site uses real semantic HTML (buttons, links, headings) throughout | Remediate | Foundation is solid; gaps are correctable in place |
Custom widgets built entirely on non-semantic <div> markup |
Rebuild | No accessible foundation exists to correct |
| No real heading hierarchy anywhere on the site | Rebuild | Structural, not attribute-level |
| High-traffic conversion pages named in a complaint or demand letter | Remediate those pages now, regardless of the rest | Limits immediate legal and business risk |
| Rest of the site has deep structural debt | Plan a phased rebuild | Incremental fixes cost as much as rebuilding anyway |
Don't Let a Spreadsheet Make This Decision For You
The mistake almost every team makes is treating the audit's findings count as the whole story. It's not. What matters is what's grouped underneath that number: how many distinct root causes are actually driving it, and whether those root causes are attribute-level or architectural.
Before you commit budget and months of engineering time to either path, ask your auditor for the findings grouped by root cause and by severity type — attribute-level versus structural. That grouping, not the raw count, is what actually determines your real cost and risk on either path.
Get a Plan, Not Just a List
A findings list tells you what's wrong. It doesn't tell you what to do about it, in what order, or what it will cost. That's the gap between an audit and a strategy — and it's the gap that turns a scary 340-item report into a manageable, sequenced plan.
If you're staring down a legacy site and a long findings list right now, don't guess at the remediate-or-rebuild question on your own. Get an audit with a prioritized remediation plan, not just a findings list, so you know exactly which path — or which hybrid of both — actually fits your site, your risk, and your budget.