Accessibility Remediation Services for WordPress Sites

You have the list. It might be an audit you paid for, a scanner export, or a law firm’s letter with a page of WCAG references attached. Now somebody has to open the theme, the plugins and the content and actually change them, without breaking the site, without creating new problems, and with a record of what was done. That is remediation: the stage where you actually fix website accessibility issues, and the stage where many projects stall. Our accessibility remediation services are built around WordPress sites, because that is where we spend our working days: child themes, block markup, form plugins, WooCommerce templates and page builders.

What accessibility remediation means on a real WordPress site

Remediation is the repair work that turns findings into changes. On a typical small business site the fixes fall into a few kinds of work:

• Markup and template changes: adding a skip link, correcting the heading order in a header template, giving icon buttons an accessible name, adding landmarks.
• CSS changes: restoring a visible focus outline the theme removed, fixing text and button colors that fail contrast, making layouts reflow at narrow widths instead of cutting content off.
• JavaScript behavior: making a dropdown menu open with Enter and close with Escape, returning focus to the trigger when a popup closes, announcing that an item was added to the cart.
• Plugin settings and replacements: switching on accessible markup options in a form plugin, or swapping a slider plugin that cannot be fixed for a simpler block.
• Content edits: rewriting “click here” links, writing alt text for informative images, turning bold paragraphs into real headings, adding captions to videos.

None of that is exotic. What makes it harder than it looks is doing it on a live business site where the theme gets updates, three plugins touch the same form, and the marketing team keeps publishing.

Starting point: an audit report, ours or someone else’s

We do not start fixing from guesswork. Remediation starts from a findings list, and that list can come from three places:

• Our own audit. If we ran the WCAG audit for your templates and forms, the findings already name the files and settings involved, so we can start immediately.
• Another firm’s audit. We are happy to work from someone else’s report. We spend the first part of the engagement confirming each finding on your current site, because sites change between the audit date and the fix date, and noting any item we cannot reproduce.
• A demand letter or complaint. These often list a handful of issues found by a scan. We treat them as a starting point, not a full list, and usually recommend a proper audit alongside the fixes. If you are in this situation, the page on website fixes after an ADA demand letter covers how the technical work runs next to the legal side. Your attorney handles the letter itself; we are not lawyers.

If all you have is a scanner export, we can still help, but expect us to suggest at least a short manual review first. Fixing only what a scanner sees tends to leave the barriers that hurt people most.

Where the fix lives: theme, plugin, custom code or content

The same visible problem can have very different causes, and the right fix depends on where the code comes from. Before touching anything we trace each issue to its source, because a fix in the wrong place gets wiped out by the next update.

Source of the issue	How we usually fix it	Survives updates?
Parent theme you bought or downloaded	Child theme template override or child theme CSS and scripts	Yes, if the parent’s markup does not change much
Custom theme built for you	Edit the theme files directly, under version control	Yes
Plugin output (forms, sliders, menus)	Plugin settings first, then hooks and filters, then a replacement plugin	Settings and hooks yes; direct edits to plugin files never
Page builder widgets	Widget settings, builder custom attributes, small CSS, or swapping the widget	Usually yes; check after builder updates
Content in the editor	Edit the pages and posts, then show editors how to avoid repeating it	Yes, until someone repeats the pattern
Third-party embed (iframe or external script)	Vendor settings, vendor support request, wrapper fixes where possible, or replacement	Depends on the vendor

We never edit plugin core files or a parent theme directly. It feels quicker on the day, and it silently reverts on the next update, which is exactly how sites that were once fixed drift back into failing.

Some fixes belong at the WordPress level rather than on one page: a theme’s navigation walker that outputs the menu without the right states, a global button style, the comment form. The broader WordPress picture of themes, block editor and menus is covered on our WordPress accessibility services page; remediation is where those general patterns get applied to your specific findings.

Third-party widgets we cannot change directly

Almost every audit includes some items in code you do not own: a hosted payment field, a booking calendar embedded from a scheduling service, a live chat bubble, a review carousel from a review platform, a map. We cannot edit another company’s iframe. What we can do:

1. Check the vendor’s own settings. Many vendors have an accessibility or “classic” mode, a choice of themes with better contrast, or an option to load a plain link instead of a widget.
2. Fix what surrounds it. Give the iframe a meaningful title, make sure focus can enter and leave it, stop our own sticky header from covering it, and add a text alternative nearby, such as a phone number or email for booking.
3. Write the vendor request for you. A short, specific report of the failures with the WCAG criteria, which you send through your account. Vendors respond better to precise reports than to “your widget isn’t accessible.”
4. Recommend a replacement when the widget blocks a core task and the vendor has no plan to fix it. Chat tools are a common case; the post on accessible live chat widgets covers what to look for.

Each third-party item is marked in the change log as “vendor dependency” with what we did and what is still outstanding, so nobody mistakes it for a closed issue.

One specific kind of third-party script deserves a mention: accessibility overlays. If the site has a toolbar or widget that claims to fix accessibility automatically, we usually remove it as part of remediation once the real fixes are in, because it can interfere with screen readers and keyboard use. The separate page on replacing an accessibility overlay with real fixes explains how to take one out safely.

Order of work: batching fixes so the site keeps running

Fixes are grouped into batches, and each batch goes through the same cycle: change on staging, test, deploy, test again on production. The order we usually follow:

1. Global template fixes first. Header, navigation, footer, focus styles, skip link, base colors. One change here clears an issue on every page.
2. Revenue and contact journeys next. Contact and quote forms, booking, checkout, donation, account login. These are where a barrier means a lost customer or a complaint.
3. Repeating components. Cards, accordions, tabs, sliders, testimonial blocks, anything reused across many pages.
4. Content clean-up. Headings, link text, image alt text and captions across the existing pages, usually split between us and your editors.
5. Documents and media. PDFs to be converted or fixed, videos needing captions, downloadable forms.

Blockers can jump the queue regardless of where they live. If keyboard users cannot reach the “Submit” button on your intake form, that gets fixed before anyone worries about heading levels on the blog.

Retesting each fix before it is marked done

A fix is not finished when the code is changed. It is finished when the original problem is gone and nothing new has appeared. For every issue we close, we:

• Repeat the reproduction steps from the findings list, on the production site, after caching is cleared.
• Check the fix with the method that exposed it: keyboard for focus issues, a screen reader for naming and announcements, zoom for reflow, a contrast tool for colors.
• Check the neighbors. A changed button style can affect every button; a menu script change can break the mobile toggle.
• Run a scan on the affected templates to catch anything obvious the change introduced.

At the end of the project there is a retest of the full original sample, not just the individual fixes. That final pass is what lets us give you an honest status: which findings are resolved, which remain, and which depend on someone else. For screen reader and keyboard retests on complex components we use the same approach as our hands-on keyboard and screen reader testing.

The change log and records you keep

Documentation matters for two reasons. Your next developer needs to know what was changed and why, so they do not undo it. And if anyone asks what the business has done about accessibility, a dated record of work is far more useful than a statement that it was “taken care of.” You receive:

• A change log with one row per fix: the original finding, the WCAG criterion, what was changed, where (file, plugin setting, page), the date, and the retest result.
• A status sheet listing every original finding as resolved, partly resolved, vendor dependency, or deferred by your decision, with a reason for anything not resolved.
• Code in your hands. Child theme or custom plugin changes delivered as files you own, ideally in a Git repository, with comments explaining accessibility-related code.
• Editor notes. A short guide for whoever publishes content: how to add alt text, use real headings, write link text and avoid color-only cues. For alt text specifically, our existing guide on adding alt text to images in WordPress covers the mechanics.

We write these records in careful language. They describe work toward conformance with WCAG 2.2 AA on the pages tested. They do not say the site is ADA compliant, and we will not write that for you.

Access and decisions we need from you

Fix work needs more access than an audit, and some fixes need decisions only you can make.

• Administrator access to WordPress, plus SFTP or hosting panel access if theme files need changing.
• A staging copy, or permission to create one. Fixing a live checkout directly is not something we do.
• Access to vendor accounts for embedded tools, or a contact who can change settings and send support requests.
• Decisions on design changes. Fixing contrast can mean darkening a brand color or changing button text color. We give options that pass; you choose.
• Decisions on removals. An autoplaying hero video or a slider with no controls may be cheaper to remove than to fix. We recommend; you decide.
• Editor time if you want your team to handle content fixes, which is often the sensible split on sites with many pages.

Fixing it in-house versus bringing in help

Not every site needs outside accessibility remediation services for every item. A lot of the work is within reach of a capable in-house team. Content fixes, alt text, link wording and heading structure are editorial work and are often better done by the people who know the content. Simple theme settings and contrast changes are fine for anyone comfortable in the Customizer or the Site Editor.

It gets harder with custom JavaScript components, menu behavior, form plugin markup, WooCommerce templates and anything that requires knowing how a screen reader interprets ARIA. Bad ARIA is worse than none, and a well-meant attribute can make a working control unusable. If your developer is strong on WordPress but new to accessibility, a mixed approach works well: we fix the complex components and review their work on the simpler ones. The general order of work for a WordPress owner doing it themselves is laid out in our WordPress accessibility walkthrough for site owners.

Agencies who want the fixes done under their own name should look at our white label accessibility remediation page instead.

Remediation mistakes that create new barriers

• Adding ARIA everywhere. Labels on elements that already have names, roles that contradict the element, aria-hidden on things people need. Each one can make a screen reader worse.
• Hiding the focus outline because it “looks ugly”. Keep it, style it to fit the brand, but never remove it.
• Fixing the symptom page by page. If thirty pages fail contrast because of one button style, fix the style once, not thirty buttons by hand.
• Editing files that updates overwrite. Parent theme and plugin edits always come back to haunt you.
• Skipping the retest. Unverified fixes are guesses.
• Chasing a scanner score. Making a tool go quiet is not the goal; making the page usable is. Sometimes those differ.

Questions to ask before hiring accessibility remediation services

1. Will you work from my existing audit, and how do you handle findings you cannot reproduce?
2. Will you put fixes in a child theme or custom plugin, so that a parent theme update cannot wipe them out?
3. Do you work on staging first?
4. How do you retest a fix, and with which screen readers?
5. What will the change log contain, and do I own the code afterwards?
6. What do you do about third-party widgets you cannot edit?
7. How do you describe the end result? Anyone who promises full ADA compliance or protection from lawsuits is promising something no developer can deliver.

Keeping the fixes in place after the project

The most common way a remediated site fails again is quiet: a plugin update changes form markup, a new landing page is built with a widget nobody tested, an editor pastes a table as an image. Six months later, the change log and the site no longer match. Our ongoing accessibility monitoring is designed to catch that drift each month, and the post on keeping WordPress accessible after updates gives a lighter routine if you want to handle it in-house.

Remediation also holds up far longer when it sits inside ordinary site care: updates tested on staging, backups before changes, and someone responsible. That is what our monthly WordPress maintenance plans are for. To see how fixing fits with auditing, monitoring and the rest of the work, start from the overview of our website accessibility services.