Late Stage Accessibility Fixes Cost More

Opening answer

Fixing accessibility after launch usually costs more than fixing the same issue during build. During build, one change to a template can fix every page that uses it. After launch, the same issue must be found across live pages, fixed in code, retested, and released again, often with a second check of the pages it touches. The work is not new work, it is the same fix, repeated, plus the checks that surround a live release. This article explains why that repeat work appears, walks through a cost example with stated assumptions, and gives a cheaper order of work.

Why a late fix costs more than an early fix

During build, a fix lives in one place. A missing label on a form template, a heading order error in a shared layout, or a contrast error in a theme colour can be changed once and carried to every page that uses that template. The team that wrote the code is still on the task, the test pages are still open, and the change has not yet been copied into content, menus, or linked pages.

After launch, the same issue has spread, and content editors may have copied the faulty pattern into new pages. A template change must then be checked against live content, live forms, and live links, each changed page needs a retest, and the release itself needs a check. Each step adds hours that an early fix would not have needed.

A late fix also tends to arrive with an audit first. An audit tells a team what is wrong and where it sits, but the audit is a separate cost from the fix. Accessible.org lists most audits at $1,250 to $2,750, with remediation listed at $750 to $4,500 for most clients, on October 31, 2026.

A worked cost example with stated assumptions

This example is arithmetic from stated assumptions, using one verified rate for both paths so the timing effect is easy to see.

Assumptions:

• The site has 12 pages built from one header template, one footer template, and one form template.
• The issue is one repeated fault: missing labels on the shared form template.
• The early path fixes the template once, in 2 hours, plus 1 hour of retesting, for 3 hours in total.
• The late path finds the issue on live pages, fixes the template, retests the form on 12 pages, releases the change, and checks the release, for 12 hours in total.
• The rate for both paths is $195 per hour, the technical support rate listed on the Accessible.org pricing page on October 31, 2026.

Cost arithmetic:

• Early path: 3 hours times $195 equals $585.
• Late path: 12 hours times $195 equals $2,340.
• Difference: $2,340 minus $585 equals $1,755.
• At the same rate, each added hour adds $195, so a late path of 20 hours would cost $3,900.

Change any assumption and the result changes. The point of the example is the shape of the cost, not the dollar total: late work repeats the fix across a live site, and repeat work is paid by the hour.

What drives the price up after launch

• Template spread. A fault in a shared template appears on every page that uses it, so the fix list grows with the page count.
• Retesting. Live pages need a check after the fix, not only a check of the template file.
• Release steps. A live change needs a release, a check of the release, and a plan for reverting it if it breaks a form or a menu.
• Manual checks. An automated scan cannot settle every check. Reading order, caption needs, and whether a label makes sense in context still need a human review, as Axeazy states on its pricing page.
• Audit before fix. A team that waits until after launch often pays for an audit first, then pays again for the fixes the audit lists.

Fixing during build: a cheaper order of work

Fix the template before the content. Start with the header, footer, navigation, and form templates, because a fix there reaches every page that uses them. Add labels, heading order, link names, button names, and alt text as each part is built, rather than as a separate pass at the end. Test with a keyboard as pages are built, and check contrast when a colour is chosen, not after a full site is styled.

Keep a dated record of each scan and each fix, showing what was found, what was changed in code, and what still needs a human review. That record is cheapest to build while the work is happening.

Axeazy: code level fixes and a dated record

Axeazy scans with axe-core and fixes 14 categories at code level. For a site with a GitHub repo, fixes arrive as a real pull request with a visible diff for owner review and merging. For WordPress, a free plugin applies three fixes at render time: a skip navigation link, a page language attribute, and an alt text fallback, with no account needed. For Shopify, readers get a scan plus a guided plain-English checklist to follow in the theme editor. Other sites get computed fix values plus a guided checklist.

Colour contrast is detected, and a WCAG-correct colour is calculated for contrast issues, applied only after owner approval. Every scan and fix is dated, and paid plans give PDF reports and weekly monitoring. Paid plans are listed on the capabilities page at Starter $29 a month, Pro $79 a month, and Agency $199 a month, with paid prices shown at checkout on the pricing page and annual billing saving 20 to 25 percent. Read the scope on Axeazy's capabilities page and the plan terms on Axeazy's pricing page. Axeazy also publishes how its risk score is calculated on Axeazy's methodology page.

How to choose

First, count templates, not only pages. A 12 page site on one template is a smaller fix job than a 12 page site on six templates. Second, ask what lands in code: a fix that changes HTML, labels, or heading order is different from a change that only appears in a visitor browser. Third, ask what retesting is included, and what record you will hold in six months. A dated list of fixes and a PDF report will matter more then than a score today.

For a fuller price and fit comparison, see the earlier article on this blog: Axeazy vs accessiBe: Price, Fixes and Fit.

Common mistakes

• Paying for an audit with no budget left for the fixes it lists.
• Fixing live pages one by one instead of fixing the shared template first.
• Treating a scan score as finished work. A score is a ranking of found patterns, not a legal assessment, as Axeazy states on its methodology page.
• Waiting for a redesign to fix a template fault that could be fixed in one file now.
• Buying a visitor menu and assuming the source code has changed, when the HTML, labels, and heading order are still as they were.

FAQ

Why does the same fix cost more after launch?

Because the fix must be repeated across live pages and then retested and released. During build, one template change can reach every page that uses it. After launch, the team must find each live instance, fix it, retest each page, and check the release.

Is an audit the same as a fix?

No. An audit finds and lists issues, with a report a team can act on. A fix changes the code, the labels, the headings, or the colours that caused the issue. Budget for both, and ask any vendor which part of the price covers finding issues and which part covers changing code.

What is the cheapest first step?

Start with a free check of your own site before paying for anything. A free 60 second scan shows the scale of the work on your pages, not on a demo site. Use that result to count templates, list the repeated faults, and decide whether a code fix route fits your team.

What should I do if I receive a demand letter?

This is general information, not legal advice. If you have received a demand letter or been sued, talk to a qualified attorney. A scan can show what is wrong and what has already been fixed, so you walk into that conversation with real data about your own site.

Last checked and sources

Last checked: October 31, 2026.

Sources: Accessible.org pricing, FTC order requiring accessiBe to pay $1 million, WCAG 2.2.

Start with the free check, then decide on fixes while the template is still easy to change: Run Axeazy's free scan.

Related reading

• Accessibility Consulting Cost: What to Expect