Accessibility
Remediating an existing site
Fixing accessibility on a live site costs more than building it in from the start, and the order fixes happen in matters as much as the fixes themselves.
Fixing accessibility issues on a site that already exists and already has real content, real traffic and a fixed budget is a materially different and more expensive undertaking than building the same standard, against WCAG, in from the start — not because the individual fixes are hard, but because each one has to be retrofitted into an existing structure rather than designed in from the beginning. The common accessibility issues a remediation project finds are rarely unique to one business; the order they get fixed in is what varies.
Why remediation costs more than building WCAG in from the start
A heading structure planned correctly during the wireframe stage of a new build costs nothing beyond normal design discipline. The same structure fixed on an existing site means reviewing every template, adjusting styles that may have relied on the old, incorrect structure, and re-testing every page type — genuinely more work for the identical end result. This asymmetry, covered from the build-planning side on what accessibility means in practice, is the central reason remediation is more expensive than prevention.
Prioritising findings, rather than attempting everything at once
A realistic remediation plan orders findings by severity and by how much traffic or how critical the affected page or workflow is — a checkout page that’s entirely unusable by keyboard is a higher priority than a minor contrast issue on a rarely visited archive page. Attempting to fix every finding simultaneously, rather than working through a prioritised list, is rarely realistic for a small business’s budget and timeline, and a staged plan is a genuine, defensible approach provided it’s actually followed through rather than abandoned after the initial audit.
What common accessibility issues can typically be fixed without a visible redesign
The majority of common findings — insufficient colour contrast, missing or poor alt text, an illogical heading structure, unlabelled form fields, missing captions — can be corrected without changing a site’s overall visual design or layout. These are largely markup, content and styling-detail fixes rather than structural rebuilds, and a supplier should be able to address most of a typical findings list without a visible change to how the site looks.
PDFs, a remediation issue of their own
A site that has accumulated years of uploaded PDFs — price lists, forms, brochures, annual reports — usually has an accessibility problem that lives entirely outside the website’s own templates. Older PDFs are frequently untagged, meaning screen readers and other assistive technology have no defined reading order and may announce the document as a single unstructured block, or skip scanned pages entirely because there is no underlying text at all, only an image of text. Remediating this generally means one of three things: retagging the existing PDFs to add proper structure and alt text for images, republishing the content as an accessible HTML page instead of a PDF, or providing an accessible alternative format on request. A remediation audit that only tests the website’s HTML and skips every linked PDF has not actually assessed the full set of accessibility issues a visitor with disabilities will encounter.
What sometimes needs a genuine rebuild
A small number of findings — a custom-built interactive component with a fundamentally inaccessible interaction pattern, such as a carousel or menu that cannot be made keyboard-operable within its existing structure — may need that specific component rebuilt from a different, more accessible pattern rather than patched. This is the minority case, not the norm, and a competent supplier should be able to distinguish clearly between what’s a straightforward fix and what genuinely needs rebuilding, rather than treating every finding as requiring a full rebuild to inflate the scope.
Ongoing maintenance after remediation
Fixing existing issues once does not keep a site accessible indefinitely — every new page, blog post or content update is an opportunity to reintroduce the same issues if whoever edits the site afterwards isn’t following the same discipline. A remediation project should include guidance or training for whoever maintains the site’s content day to day, not just a one-time fix, otherwise the same findings tend to reappear within months.
Setting realistic expectations with a supplier
Ask a prospective remediation supplier for a staged plan with cost estimates per priority tier, rather than a single lump-sum figure for “fixing accessibility” — this makes the scope and the trade-offs visible, and lets a business genuinely choose how far to go within its budget rather than accepting an all-or-nothing quote.
Why remediation should be scoped and quoted like any other project
A remediation engagement deserves the same clarity of scope and payment structure as any other website project — a defined list of findings to address, milestones, and what happens if further issues are discovered mid-project. Treat a remediation quote with the same scrutiny applied to any other quote, covered on what should be in a website quote, rather than assuming accessibility work is somehow exempt from the usual scope-and-price discipline.
Testing after remediation, not just before
A remediation project isn’t complete simply because the original findings list has been addressed — the fixes need to be tested afterwards, ideally by re-running both an automated accessibility checker and the manual checks that identified the original issues, to confirm the fix actually resolved the problem at the intended conformance level rather than introducing a new variant of it. This is a step worth explicitly including in a remediation scope rather than assuming it’s implied.
Why remediation is also a good moment to build better internal processes
A remediation project is a natural point to also put in place the ongoing discipline that prevents the same issues recurring — a content style guide covering alt text and heading practice, a pre-publish checklist for anyone adding new pages or posts. Addressing the existing findings without also addressing why they accumulated in the first place tends to produce the same list of issues again within a year or two.
Communicating remediation progress to your own stakeholders
If accessibility has become a visible concern internally — raised by a staff member, a customer, or a board — a staged remediation plan with visible milestones gives you something concrete to report on progress, rather than an open-ended “we’re working on it” with no way to demonstrate movement. This is a practical reason to insist on a staged plan even beyond the budgeting benefit already discussed.
What to do next
Get a prioritised findings list before agreeing to any remediation scope, and address the highest-severity, highest-traffic issues first if budget doesn’t allow everything at once. What that remediation work costs as an ongoing commitment, alongside other maintenance, is covered on what a website costs to keep working.
Evidence for this page
This page exists because the demand below was measured, not assumed. The figures are search-market data about the topic — they are not prices.
- Entity this page targets
- fixing accessibility issues on an existing website
- Measured Google volume
- no data
- Keyword difficulty
- no data
- Advertiser cost per click
- no data
- AI assistant volume
- no data
- Advertiser competition
- no data
- Measured on
- 31 July 2026
- Search results inspected for intent
- No
2 other phrasings resolve to this same page
accessibility remediation cost · how to fix an inaccessible website
Not part of the 2026-07-31 DataForSEO pull recorded in research/national-volume-au.json; no volume claim is made for this phrase.
Source: research/national-volume-au.json · Phrase not present in the 2026-07-31 DataForSEO pull; no volume claim made. · pulled 31 July 2026.
Provenance
Written by Australian Website Design. Published 2026-08-03, last updated 2026-08-03.
Sources
- W3C Web Accessibility Initiative — evaluation and tools (accessed 2026-08-03)