Rebuilding Legacy Sites for Compliance

Legacy doesn’t mean ugly. It means brittle.

A legacy site usually has:

Server-side rendering mixed with JavaScript added later.
Inline styles baked into templates.
Navigation built from tables or divs without landmarks.
Forms assembled by copy-paste.
PDFs generated by office software and uploaded raw.

Accessibility issues cluster around structure, not color.

Contrast is easy to fix. Semantics aren’t.

why retrofitting fails more often than rebuilds

Teams try to patch.

Add aria-labels.
Add tabindex.
Add skip links.
Add an overlay.

It works until it doesn’t.

Retrofitting fails when the DOM order doesn’t match the visual order. Screen readers read garbage. Keyboard users fall into traps. Fixing that without touching layout becomes impossible.

At that point, rebuilding is cheaper than endless patches.

courts don’t require perfection, but they track patterns

ADA website cases don’t hinge on one missing alt tag. They hinge on repeat failures.

Investigators from the U.S. Department of Justice test flows, not pages. They try to pay a bill, submit a form, request a record.

Legacy sites break there.

Rebuilding focuses on flows. That’s why it holds up better under scrutiny.

rebuilding is about information architecture first

Accessibility problems often start with navigation.

Legacy sites grow sideways. New departments get sub-sites. Old links stay live. Menus balloon.

Screen reader users hear 80 links before content. Keyboard users tab forever.

Rebuilding starts by cutting.

Fewer menu items.
Clear page types.
Consistent headings.

This is content work, not code. It’s also where politics enter. Departments resist losing visibility. Courts don’t care.

templates decide accessibility outcomes

Legacy sites often have dozens of templates. Slightly different. Maintained by habit.

Each template multiplies risk.

Rebuilding consolidates templates. Five to eight page types cover most government sites. That reduces testing scope and fixes repeating issues once.

Template consolidation is boring. It saves money and time later.

cms constraints shape accessibility

Many legacy sites run on old CMS versions or custom systems.

Upgrading the CMS is often necessary. That’s not an accessibility requirement. It’s a practical one.

Older CMSs don’t support semantic blocks, proper heading structures, or accessible media embeds. Editors fight the system. Mistakes multiply.

Rebuilding without addressing CMS limits creates future failures.

pdfs are the hidden sinkhole

Legacy sites love PDFs.

Agendas.
Minutes.
Forms.
Reports.

Most are inaccessible. Tagged wrong. Scanned images. No headings.

Rebuilding forces a decision.

Convert to HTML.
Remediate PDFs.
Replace workflows.

PDF remediation is slow and expensive. HTML is faster but politically harder. Boards want official-looking packets.

Trade-off accepted or deferred. Logs should show the choice.

forms are where lawsuits start

Most complaints trace back to forms.

Tax payments.
Permit applications.
Service requests.

Legacy forms use placeholder text instead of labels. Error messages aren’t announced. Required fields aren’t marked programmatically.

Rebuilding forms means rethinking validation, not styling.

This is where accessibility meets backend logic. It takes coordination. It also takes time.

a real example from a city utilities site

In 2020, a mid-sized city rebuilt its utilities billing site after repeated complaints.

The old site had a keyboard trap in the payment modal. It had been patched three times. Each patch broke something else.

The rebuild replaced the vendor widget with a server-rendered flow. Fewer features. No fancy animations.

Complaints stopped. The UI looked simpler. Finance staff complained. Legal didn’t.

That trade-off held.

javascript frameworks aren’t the villain

Legacy sites often mix jQuery-era scripts with modern components.

The problem isn’t JavaScript. It’s uncoordinated state.

Screen readers depend on predictable updates. Legacy code updates the DOM in ways assistive tech doesn’t catch.

Rebuilding creates a single interaction model. That matters more than framework choice.

accessibility overlays don’t rebuild anything

Overlays add code on top of broken structures.

They don’t fix heading order. They don’t fix focus management. They don’t fix form logic.

Using an overlay during a rebuild can slow work by masking issues during testing. Some teams turn them off entirely during remediation.

That decision belongs in documentation.

wcag as a reference, not a checklist

Rebuilds usually reference WCAG 2.1 Level AA, published by the World Wide Web Consortium.

WCAG is not law. Courts still use it as a measuring stick.

Teams that treat WCAG as a checklist rebuild twice. Teams that treat it as a behavior guide rebuild once.

Understanding intent beats memorizing success criteria.

content editors shape long-term compliance

Legacy sites often ignore editors.

Editors upload content that breaks accessibility without realizing it. Headings skipped. Tables misused. Images unlabeled.

Rebuilding without editor training creates a temporary win.

Training doesn’t need workshops. It needs constraints. CMS defaults that prevent bad markup. Clear rules. Short documentation.

migration is where accessibility dies quietly

Content migrations break things.

Alt text lost.
Headings flattened.
Links stripped.

Rebuilds need migration scripts that preserve accessibility data. That’s extra work. It’s rarely budgeted.

Skipping it means rebuilding problems into the new site.

testing during rebuilds needs to be staged

Testing only at the end fails.

Accessibility testing belongs at:

Design review.
Template completion.
Pre-migration.
Post-migration.

Legacy rebuilds fail when teams wait for a final audit. Fixes cost more then.

Staged testing slows development. It reduces rework. That’s the trade.

mobile versions expose old assumptions

Many legacy sites added mobile later.

Separate mobile templates.
Conditional logic.
Hidden content.

Rebuilding usually collapses this mess. One responsive layout. One DOM order.

Mobile accessibility improves as a side effect. That’s not accidental.

performance and accessibility collide sometimes

Legacy rebuilds often improve performance.

Sometimes they don’t.

Adding ARIA live regions, focus management, and semantic markup can add overhead. On low-end devices, that shows.

Teams need to choose. Slightly slower pages that work, or fast pages that don’t. Courts don’t reward speed.

multilingual content complicates rebuilds

Legacy sites often bolt on translation.

Language attributes missing.
Translated PDFs inaccessible.
Navigation inconsistent.

Rebuilding multilingual support correctly takes planning. Skipping it creates unequal access. That shows up fast in complaints.

timelines are longer than leaders expect

A real rebuild takes months.

Discovery.
Architecture.
Templates.
Migration.
Testing.

Leadership often expects weeks. That gap creates pressure to cut corners.

Cutting corners shows later. Usually in the first complaint after launch.

budgets force uncomfortable decisions

Accessibility rebuilds cost money.

Developers.
Auditors.
Content work.
PDF remediation.

Small agencies struggle. That’s real.

Courts don’t excuse lack of funds. They consider effort and planning. Documented rebuild plans matter.

partial rebuilds are common and risky

Some teams rebuild only public-facing pages.

Internal portals stay broken.

Users don’t separate them. Neither do investigators.

Partial rebuilds need clear boundaries and documented plans. Otherwise they look like avoidance.

accessibility statements must reflect rebuild reality

Legacy sites often promise “ongoing improvements.”

After a rebuild, statements need to match what exists.

Overpromising creates exposure. Understating effort creates confusion.

Plain language works better.

logging rebuild decisions protects teams later

Every rebuild decision has a reason.

Deferred PDFs.
Vendor constraints.
Phased rollouts.

Documenting those choices matters. Not defensively. Factually.

Logs show why something wasn’t fixed yet. Courts read that.

the uncomfortable truth about rebuilds

Rebuilding legacy sites for accessibility often strips features.

Animations go.
Custom widgets go.
Visual complexity drops.

Some stakeholders hate that.

Users who rely on assistive tech don’t miss it.

That tension doesn’t resolve. Teams choose.

what success actually looks like

Success isn’t zero errors.

Success is predictable behavior.
Clear structure.
Fixes that stick.
Editors who stop breaking things.

Complaints may still happen. Logs show response. Sites improve.

That’s the reality courts recognize.

the limitation nobody advertises

Rebuilds don’t end liability.

They reset the baseline.

Accessibility is maintenance. Legacy sites prove what happens when maintenance stops.

Rebuilds buy time and clarity. They don’t buy immunity.

End.