Accessibility is cheaper when you build for it than when you bolt it on

Most accessibility budgets I have seen are spent twice. Once at the start, when a site is built without much thought given to assistive technology. Then again, eighteen months later, when a complaint, an audit or a procurement question forces the issue and a remediation project lands on someone desk.

The remediation always costs several times the build cost. That is not a sales line. It is what happens when you have to revisit decisions baked into a content model, a template hierarchy, a design system and an editor workflow that has been running for two years. Each fix touches more files than it would have at day one and each fix has to be coordinated with whoever currently owns the site.

This post is the developer view of where the money actually goes, which decisions at build time save the most retrofit cost later and how to think about the build-in versus bolt-on choice when commissioning a new site or rebuild.

The shape of the cost curve

On a new build, accessibility done correctly adds maybe a tenth to the front-end budget. You are picking semantic markup, building keyboard support into components, writing alt text into the editor flow and testing with a screen reader at the end of each milestone. None of that is extra work in any meaningful sense once the team knows what it is doing. It is just doing the work properly the first time.

On a remediation project, the cost is different. You are not adding accessibility to a clean slate. You are picking through a live site, identifying issues, deciding whether to fix at the template level, the component level or the content level and shipping changes without breaking the running site or the editorial team. The audit alone is several days of work on a medium site. The fixes are usually four to ten times the build-time effort, depending on how the original was put together.

Some categories of issue are nearly free to retrofit. Adding a focus outline to a button. Some are extremely expensive. Rebuilding a custom JavaScript component, replacing a non-semantic page template across hundreds of entries or rewriting alt text on a media library of fifteen thousand images.

Where build-time decisions save the most retrofit cost

Six categories pay back the largest multiple if you get them right at the start.

Semantic HTML in the page template

A page that uses heading levels in order, landmarks for header, main, nav and footer, lists for lists and buttons for buttons is most of the way to accessible by default. Retrofitting that means changing the templates that already render every page on the site, then checking that the change has not broken styles or scripts that depended on the wrong markup. On a large WordPress or Statamic build, that easily runs into days.

At build time it is the cost of the developer choosing the right element. Essentially free.

Focus management in interactive components

Menus, modals, accordions, tabs, custom dropdowns. Each of these has a known accessible pattern. If you build them right the first time, focus enters and exits correctly, Escape closes the modal, arrow keys navigate the menu and the user always knows where they are.

Retrofitting focus management means going into JavaScript you may not have written, untangling existing event handlers and rewriting interaction logic without breaking the visual behaviour. Custom components on legacy themes are where remediation budgets disappear fastest.

Contrast in the design system

Pick contrast-safe colour pairs at the start and lock them into your tokens. Body text and background, link and surface, button label and button fill, error text and field. All of it above 4.5 to 1, or 3 to 1 for large text. Once those tokens are in the design system you cannot easily ship a contrast failure later.

Retrofitting contrast usually means a wider brand conversation. You are no longer just changing CSS values. You are changing how the brand looks. The decision gets bumped to a stakeholder meeting and the project stalls. Better to have that conversation once, at brand and design system definition, than every audit.

Alt text discipline in the editor workflow

Make the alt text field mandatory in your CMS for any image used in content, with a clear way to mark an image as decorative. Train the people who load content to write the alt text at upload, when they still know why the image is there. The convention is one good sentence describing what the image conveys, not a transcription of the file name.

Retrofitting alt text on a populated media library is one of the slowest accessibility tasks in existence. Someone has to look at every image, decide what it is and write a description. On large sites that runs into thousands of items.

Form labelling and error handling

Every form field has a real, visible label associated with the input. Error messages reference the field by name. Validation messages are announced to screen readers. Required state is communicated to both sighted and assistive technology users.

Retrofitting forms means revisiting every form on the site, often built by different developers across different years using different plugins. On WordPress that frequently means swapping the form plugin entirely, then migrating submissions.

Keyboard-only flows for the critical journeys

Every important task on your site has to be completable with the keyboard alone. Add to cart, log in, fill in a contact form, complete checkout. If you test these journeys with the mouse unplugged at the end of each build milestone, you find issues while the code is fresh and the developer who wrote the component is still on the project.

Retrofitting keyboard support a year later, on components built by someone who has since left the agency, is one of the hardest accessibility tasks. The fix often requires knowledge of why the component was built the way it was, which is rarely written down.

The hidden retrofit cost in content models

A category most teams miss until they hit it is the content model itself. If your blog template requires every post to have a hero image and the editor cannot mark it as decorative, you are forcing alt text decisions that cannot easily be made well. If your case study template renders a quote without semantic blockquote markup, every case study now has the wrong structure for assistive tech.

Fixing content model decisions later means migrating content, often without a clean automated path. A CMS that bakes accessibility into its blueprints at the start saves all of that work. Statamic and WordPress can both be configured this way. The work is at the start, in field design, not in the templates that follow.

The bolt-on temptation

The reason teams reach for bolt-on solutions is straightforward. The remediation cost looks large. The overlay licence fee looks small. The maths appears to work.

It does not work, because the overlay does not satisfy WCAG, screen reader users disable it on sight and the underlying issues are still present whether the widget is loaded or not. I have written about this in detail in why accessibility overlay plugins do not make you compliant. The short version is that the bolt-on cost is wasted, not saved.

The honest version of the bolt-on is a proper remediation project. It is real work but it is real fixes, against the criteria a court or an auditor will actually use. The cost is real, the outcome is real and it does not have to be paid again next year.

How to commission a build that ages well

If you are scoping a new site or a rebuild, the relevant lines in the brief are short. State WCAG 2.2 AA as the target. Ask how the agency or freelancer plans to test against it at each milestone. Require an accessibility statement on the final site. Require alt text fields to be mandatory in the CMS. Require keyboard-only testing as part of QA. These are reasonable, cheap and lead to a site that holds up.

If the response is a vendor offering to install an overlay, that tells you what kind of build you would have got. The UK legal picture is covered in WordPress accessibility and the UK legal position if you want the legal floor in detail before the conversation.

How I work on this

On new WordPress builds I treat WCAG 2.2 AA as the baseline target and bake it into the theme, the block library and the editor configuration. On rebuilds I scope a short accessibility audit in week one and let the findings shape the new content model so we do not rebuild the same problems. On remediation work I prioritise the structural fixes that unlock the most criteria in one pass and leave the easy cosmetic ones for last because they tend to take care of themselves once the structure is right.

If you are starting a WordPress project and want it built with accessibility in the foundation rather than retrofitted later, see WordPress development services or get in touch and tell me what you have.