Patch It or Rebuild It? How to Tell When a Government Website Is Past Accessibility Remediation

The audit comes back with several hundred findings. Somebody in the meeting asks the question everyone is thinking: would it be cheaper to just start over?

Sometimes it would. Often it would not. And the worst outcome is making that call on instinct — rebuilding a site that needed a month of template fixes, or pouring a year of patches into a platform that will never conform.

The decision is more mechanical than it looks. Here is how to make it.

Why does the count of findings not tell you much?

Because findings are not independent.

An audit of a site built on a content management system reports issues page by page. But most of those pages share a handful of templates, a header, a footer, a navigation menu, and a component library. A missing skip link, a keyboard trap in the main menu, or an unlabelled search field in the header will appear on every page of the site — hundreds of findings, one fix.

So the first job after an audit is to regroup the findings by where they originate: the template or theme, a shared component, the content itself, or third-party embeds. A report of eight hundred issues frequently turns out to be twenty template defects, a few dozen component defects, and a long tail of content problems such as images without alt text and PDFs without tags. That is a remediation project, not a rebuild.

How to run a website accessibility audit covers how to record findings so this grouping is possible.

When is remediation the right answer?

Remediation usually wins when most of these are true:

• The platform is current and supported. The CMS, theme framework and major plugins still receive updates, and the vendor treats accessibility defects as bugs.
• You control the templates. Your team, or a contractor, can edit the theme code. Fixes made there flow to every page.
• The problems are structural but local. Heading order, form labels, focus styles, colour contrast, landmark regions, link text — the WCAG criteria that are fixed in markup and CSS.
• Content is the long tail. The rest is alt text, captions and documents, which you would have to fix under a rebuild too. A new site does not remediate your PDFs.
• The site otherwise does its job. Residents can find what they need, and nobody is lobbying to replace it for other reasons.

When is it time to rebuild?

The signals for a rebuild are about the foundation, not the volume:

• The platform is end of life or unsupported. You would be investing in code nobody will maintain, on software that will not receive security patches.
• You cannot change the markup. Some hosted platforms lock the templates. If the vendor will not fix a keyboard trap in their navigation, you cannot fix it either.
• Core interaction is built wrong throughout. Custom widgets built from generic elements with click handlers and no keyboard support, used everywhere — menus, tabs, accordions, date pickers, modals. Retrofitting correct roles, states and keyboard behaviour into a whole bespoke component set can cost more than replacing it with components built properly.
• Layout is fundamentally non-responsive. WCAG 1.4.10 Reflow requires content to work at a width equivalent to 320 CSS pixels without horizontal scrolling. A fixed-width layout from another decade cannot usually be coaxed into this.
• A redesign is coming anyway. If the organisation will replace the site within a short horizon for unrelated reasons, spending heavily to patch the old one is rarely wise. Fix the highest-impact barriers now, and write accessibility into the new build’s contract.

Remember that WCAG conformance is assessed on full pages and on complete processes — if any step of an online application fails, the process does not conform. A rebuild decision should be driven by whether you can get your critical processes through end to end on the current platform.

Isn’t an overlay a third option?

No.

Overlay products — a script that adds an accessibility toolbar, or claims to fix a site automatically with AI — are marketed as a way to avoid the choice. They do not change the underlying markup that assistive technology relies on, and they frequently interfere with the assistive technology users already have configured.

In 2025 the Federal Trade Commission finalised an order requiring one overlay vendor, accessiBe, to pay $1 million over allegations that it misrepresented its tool’s ability to make websites WCAG-compliant. The order bars the company from making such claims without evidence to support them. That is a regulator’s view of the “automatic compliance” promise, and it is worth knowing before a sales call.

What about the multilingual version of the site?

It has to be in the decision, because it often decides it.

If your site publishes content in Spanish, Vietnamese, Chinese, Arabic or other languages, the translated pages are subject to the same accessibility obligation as the English ones. On older platforms, translated content is often bolted on — a separate microsite, a set of uploaded PDFs, or a translation widget. Each of these has its own accessibility failures: missing language declarations under WCAG 3.1.1, untranslated alt text and form labels, and widget controls a keyboard user cannot reach. Screen readers and machine translation goes through why that combination breaks.

A platform that cannot hold properly structured, correctly language-tagged translated pages is a strong argument for rebuilding. A modern CMS with real multilingual support is an argument for remediating.

How to make the call

Regroup the audit by origin. Template, component, content, third-party.

Estimate the template and component fixes separately. This is the number that competes with a rebuild. Content fixes are needed either way.

Test your critical processes end to end. Paying a bill, applying for a permit, registering for a programme. If they can be made to conform on the current platform, remediation is viable.

Check the platform’s future. Supported, editable, multilingual-capable? If not, the case for rebuilding is strong regardless of findings.

Budget for documents in both scenarios. The PDF estate does not migrate itself into accessibility. Triaging a legacy PDF backlog helps you size it.

Put accessibility in the contract either way. Whether you remediate or rebuild, require conformance to WCAG 2.1 AA, testing evidence, and fixes at the vendor’s expense. Writing accessibility into an RFP or SOW has language you can adapt. For which compliance date applies to you, see the deadlines post.

Where Taika fits

We assess sites, regroup the findings by where they originate so the patch-or-rebuild decision is clear, and remediate the content layer — documents, alt text, captions and multilingual pages — that has to be fixed in either scenario. We meet and exceed ISO 17100, 9001 and 27001 standards. We will tell you if we think a rebuild is the better spend.

Weighing remediation against a rebuild? Send us the site URL, your CMS and whether you can edit its templates, any recent audit report, the languages you publish in, and roughly how many PDFs are linked from the site — then request a quote. Our ADA website accessibility page explains how we scope Title II website work.