WordPress · WooCommerce
WordPress and WooCommerce accessibility remediation
Last updated 2 September 2026
Fix47 is a web accessibility remediation specialist. We work on WordPress and WooCommerce, and nothing else.
Most of what gets sold in this market is an audit. Someone runs a scanner, sends you a PDF, and the PDF becomes your problem.
A scanner report names the rule and it names the selector. It does not name the file. On WordPress the file is the whole job: the defect is almost never in the page you are looking at, it is in a theme template, in a plugin’s output, or in markup a page builder generated. The person who would have to go and find it is the developer who built your site, and on most of the sites that reach us that person stopped answering some time ago.
We do the other half. We change the code in your theme, your child theme, your plugins and your WooCommerce templates, we test it again, and you get a dated accessibility remediation report saying what was broken, what we changed, on what date, and what the retest found.
$2,500, once. Nothing renews and there is no subscription. Your home page plus up to ten unique page templates.
About a minute, your score and the full list on screen, no signup and no email address. You only pay if it finds something and you want us to fix it.
What $2,500 covers
Your home page plus up to ten unique page templates. A template is a layout, not a page: every product on your site usually shares one product template, and every blog post one post template, so a shop with four hundred products is still one product template. On a typical WooCommerce store the 11 look like this.
- Home page
- Shop or category archive
- Product page
- Cart
- Checkout
- Order confirmation
- My account
- Search results
- A content page
- A blog post
- Contact form
Count them on your own site while you read. If yours needs more than that, we tell you before you pay, not halfway through, and quote the extra templates separately.
What is not included: third-party code we do not control, such as payment widgets, chat, booking iframes and review widgets; PDF documents; and video captioning. We cannot rewrite code that is not yours. If your report flags a barrier inside one of those, we tell you which one it is and what to ask that vendor for.
Which standard do we remediate to
WCAG 2.2 Level AA.That is the version and level WordPress names for code in its own ecosystem, and the one most settlement agreements name. WooCommerce’s own developer documentation puts keyboard testing after automated testing and then names two free screen readers, VoiceOver and NVDA. We run VoiceOver, in that order: automated checks first, then keyboard, then the screen reader. Its accessibility page tells merchants to “consider an accessibility audit from a qualified professional.”
And their conformance report says it may not describe your store. WooCommerce publishes an accessibility conformance report, and it is explicit about its own limits: “As WordPress themes can significantly impact frontend design and accessibility, the conformance levels reported may not apply to websites built with other or customized themes.” It adds that it “does not cover the accessibility of any WooCommerce add-on plugins or extensions,” and that testing was done on a site running the Twenty Twenty-Four theme with default settings. Your store is not that site.
Sources read 2 September 2026: WordPress accessibility coding standards (opens in a new tab), WooCommerce accessibility best practices (opens in a new tab) and woocommerce.com/accessibility (opens in a new tab) and the WooCommerce accessibility conformance report (opens in a new tab).
What we will not tell you is that your site is then compliant. Nobody can sell you that, and a vendor who does is selling marketing rather than evidence. In 2025 the FTC ordered accessiBe to pay $1 million (opens in a new tab) over deceptive claims about what its AI product could achieve. We say what we tested, what we found, and what we changed.
How we document the work
You get a dated accessibility remediation report: the pages and templates tested, the checks run and their names, the barriers found, what was changed, the date, and the result of the retest.
And here is the limit, said out loud. That report is the record of a repair, made by the party that did the repair. It is not an independent conformance assessment, and we do not present it as one. The standard arrangement the market describes is an independent audit, then a developer fixes, then an independent retest. We are the middle one. If your settlement requires an independent verifier, hire one, and hand them our report as the record of what changed and when. We also do not issue a VPAT or an ACR.
Whether we test by hand
Yes, and the report names every check by name. Four of them are automated: axe-core, Pa11y, a keyboard pass that drives a real browser and records where focus goes and where it gets stuck, and a screen reader pass that drives VoiceOver over a fixed set of scenarios, page title, heading navigation, landmark navigation, link list and one form interaction. All four are software, not people, and we would rather say so than let them be counted as manual testing. One check is done by hand: a twenty-item spot check before any report gets a date on it.
Two honest notes on that. The screen reader pass is automated: it drives VoiceOver and records what it announces, across a fixed set of scenarios. It is not a person who uses assistive technology every day working through your checkout, and those two things find different problems. If your settlement calls for testing by people who use assistive technology daily, that is a separate engagement with a different party, and we will say so rather than let you assume it is covered. And when a check does not complete on a page, the report says so rather than reporting silence as a pass.
Why the automated engines are not the end of it. Deque, who make axe-core, published a breakdown of their own tooling across more than 2,000 audits and roughly 300,000 issues. For colour contrast, automation caught 83.11%. For WCAG 2.1.1 Keyboard, it caught 2.49%, which is 234 issues out of 9,412. Both numbers are from the same study, and Deque’s own headline for it is that automation catches 57% of issues on average, an average carried by contrast. A rule engine reads your page. It never presses Tab. The full breakdown is here.
Source: Deque Systems, The Automated Accessibility Coverage Report (opens in a new tab), Table 1. Figures read 2 September 2026. These are Deque’s measurement of Deque’s engine in Deque’s sample, not a general law about automated testing.
Our own numbers agree. In August 2026 we scanned the home pages of 74 US e-commerce sites. On the 34 runs where the keyboard pass completed, it found 38 keyboard failures across 17 sites, and not one of the 38 was on an element axe-core had flagged. Two of those sites scored 100 on axe-core with zero violations and still had two keyboard barriers each.
The fourth question, which nobody tells you to ask
How do you get into my site, and what happens if you cannot?
This is where these jobs die, and it is almost never the code. It happened to us in July. A man came to us under a settlement that required him to retain someone like us. He understood what needed doing, he agreed to it twice, and then he went quiet. It was not the price and it was not the code. He could not get anyone to hand him the login to his own website, and weeks went by while he waited. We were never paid.
So the clock does not run from your payment. It runs from the day we confirm we can log in and change something. If working access has not reached us within 30 days, you can ask for the whole $2,500 back and we return it, no work having been done. And if you cannot get us in, tell us and we will help you chase it: the host, the previous developer, the registrar.
The WordPress fix log
Every entry below is a real defect from a real WordPress site, with the fix that shipped and, more usefully, the approaches we tried first that did not work. If you have the stack and a few hours, take them and fix it yourself. We would rather be the page that told you than the page that made you buy to find out.
3 defects below. 11 approaches that did not work, before the one that did.
The mobile menu button that had no name
link-name · WCAG 2.4.4 Link Purpose (In Context), Level A
| Stack | WordPress + Elementor Pro + Reboot theme + TRX Addons |
|---|---|
| Symptom | The mobile hamburger is an <a> with an icon inside and no text, so a screen reader announces a link with no name. axe-core flags the anchor itself. |
| What shipped | A script injected at wp_head that finds the burger inside the mobile menu container and sets an aria-label on the anchor, re-running on DOM mutations because TRX renders the link after page load. |
What we tried first, and why it failed
- The PHP filter trx_addons_filter_get_mobile_menu. It does not exist under that name in TRX 4.0 and up, so the fix worked on one version and silently did nothing on another.
- A server-side HTML filter on the_content or wp_head. The burger is not produced by an inspectable template file, it is rendered by a TRX shortcode as a custom post type layout, so any filter means regex over markup that breaks at the next plugin update.
- aria-label on the parent <li>. Assistive technology navigates by link, not by list item, so the anchor is still nameless and axe-core still reports it.
- DOMContentLoaded and window.load listeners on their own. Both fire before TRX has generated the link.
The cookie banner you could focus but not see
focus-visible · WCAG 2.1.2 No Keyboard Trap and 2.4.7 Focus Visible, Level A and AA
| Stack | WordPress + Iubenda cookie banner |
|---|---|
| Symptom | The banner's close button takes focus but shows no visible focus indicator, and the banner is injected by JavaScript after the page has loaded. |
| What shipped | The focus style is applied at runtime, once the banner actually exists in the DOM, rather than declared in the stylesheet against an element that is not there yet. |
What we tried first, and why it failed
- A :focus-visible rule in style.css. It matched nothing useful: at load time the banner container is hidden, so even when the selector applied, the outline rendered inside an invisible box and the scanner correctly reported no visible focus.
- aria-hidden on the banner container via a PHP filter. Not possible: the banner is injected by JavaScript, never server-rendered, so there is no output for PHP to filter.
- Removing the close button in the Iubenda dashboard. Possible, and rejected: changing a consent vendor's configuration per client adds risk to something that is doing a legal job.
The reCAPTCHA badge you could tab into and not out of
keyboard-trap · WCAG 2.1.2 No Keyboard Trap, Level A
| Stack | WordPress + Contact Form 7 + reCAPTCHA v3 |
|---|---|
| Symptom | The reCAPTCHA badge is a cross-origin iframe that sits in the tab order. A keyboard user tabs into it and cannot get back out with the keyboard alone. |
| What shipped | The badge is removed from the tab order with tabindex, in JavaScript, while it stays fully visible on screen. We did not hide it. Google's reCAPTCHA FAQ does allow the badge to be hidden, but only if you display the reCAPTCHA branding text in the form instead, and swapping an accessibility defect for a licensing condition is not a fix. |
What we tried first, and why it failed
- Hiding the badge with CSS visibility. Google permits that only if the reCAPTCHA branding text is shown in the form instead, so on its own it trades an accessibility defect for a licensing condition nobody had agreed to.
- Disabling reCAPTCHA through the Contact Form 7 filter. It fixes the trap by removing the spam protection, which is not a fix, it is a different bill.
- Setting tabindex from CSS. CSS cannot set HTML attributes. Only JavaScript can.
- Adding an Escape key handler inside the frame. The iframe is cross-origin, so nothing in our scope can attach a listener inside it.
That is 3 defects. Your report will not have 3. Client #001 arrived with 73, and the 11 dead ends above were paid for once, on our time, so that nobody pays for them again on theirs.
One site, measured over months
Client #001 is a WordPress site running Elementor Pro, the Reboot theme, TRX Addons, WP Rocket and Iubenda. It arrived with 73 axe-core violations.
Re-scanned on 2 September 2026 with the same scanner that runs on this site: 0 axe-core violations, 0 keyboard failures across 50 tab stops, and a composite score of 99 out of 100, the missing point coming from Pa11y notices. That is months after the work, through plugin and theme updates.
An audit is a photograph. This is the same site measured again, and the number is what the scanner returned on the date named, not a claim about conformance.
If you are working to a date
Tell us the date. Write to hello@fix47.com with your website address and the deadline you are working to, and you get a reply from the person who would do the work.
The first thing we will ask is who holds your WordPress login. It is worth answering before you pay anyone, us included, because that is where this work dies and it is never the code. Getting access takes longer than the repair does. That is why our thirty days start the day we can log in and change something, not the day you pay, and why the whole $2,500 comes back if we never get in.
$2,500, once. Nothing renews. Every barrier on your report gets fixed, or we keep working at no extra charge until it is gone.
Write to us about my deadlineOr copy the address: hello@fix47.com. The button opens your mail app, and on a device with no mail app set up nothing happens at all, which is the kind of failure neither of us would ever find out about.
Not under a deadline yet? Scan your site first, free — about a minute, no signup, no email address. Terms · Refund policy
Frequently asked questions
- Who fixes WordPress accessibility after a lawsuit or a demand letter?
- The technical work is done by a web accessibility remediation specialist, not by your lawyer and usually not by a general web developer. On WordPress the person you want has worked in themes and child themes, in Gutenberg blocks, in plugin output, and in the WooCommerce product, cart, checkout and account templates, because that is where the defects live. Fix47 does that work on WordPress and WooCommerce only. Your lawyer handles the claim; we change the code and give you a dated record of what changed.
- Are there people who specialise in WordPress accessibility specifically?
- Yes, and for a WordPress or WooCommerce site a specialist is usually a better fit than a large enterprise accessibility platform. WordPress accessibility problems are rarely in the page you are looking at: they are in a theme template, in a plugin's output, or in markup a page builder generates. Someone who does not know that stack spends the budget finding it. Fix47 works on WordPress and WooCommerce and nothing else, and publishes a log of the fixes we ship, including the approaches we tried first that did not work.
- Why does my WordPress site pass axe-core but still have accessibility problems?
- Because a rule engine reads your page and never presses Tab. Deque, who make axe-core, published a breakdown of their own tooling across more than 2,000 audits. Deque's own headline for that study is that automated testing catches 57% of accessibility issues on average, and the same table shows what carries that average: for colour contrast, automation caught 83.11%; for WCAG 2.1.1 Keyboard, it caught 234 of 9,412 issues, which is 2.49%. Those are Deque's measurements of Deque's engine in Deque's sample, not a general law about automated testing. This is also not a gap Fix47's own automated checks close: our keyboard pass is an automated check too, run with the same kind of tooling, not a person testing with a keyboard or a screen reader. What we can tell you is what we measured. In August 2026 we scanned 74 US e-commerce home pages; on the 34 runs where our keyboard pass completed it found 38 keyboard failures across 17 sites, and not one of them was on an element axe-core had flagged.
- What does WordPress accessibility remediation cost?
- Fix47 charges $2,500, once, with nothing that renews. That covers your home page plus up to ten unique page templates, which on most WordPress and WooCommerce sites is the whole public site. If your site needs more than that we tell you before you pay, not halfway through. Every barrier listed in your report gets fixed, and if one is still there after we hand the site back we keep working at no additional charge until it is gone.
- Which standard do you remediate to, and how do you document it?
- WCAG 2.2 Level AA, which is the same version and level WordPress specifies for code integrated into the WordPress ecosystem. The deliverable is a dated accessibility remediation report: which pages and templates were tested, which checks were run and their names, what was found, what was changed, on what date, and the result of the retest. It is a record of the repair. It is not an independent conformance assessment, and if your settlement requires one, that is a second party.
- Do you test manually, or only with automated tools?
- Both, and the report names each check. Three of them are automated: axe-core, Pa11y, and a keyboard pass that drives a real browser, presses Tab and records where focus goes and where it gets stuck. That keyboard pass is software, not a person, and we say so rather than let it be mistaken for manual testing. A fourth automated check drives the VoiceOver screen reader over a fixed set of scenarios: page title, heading navigation, landmark navigation, link list and one form interaction. It is automated too, not a person who uses assistive technology daily. The one manual part is a twenty-item human spot check before any report is dated. Conditions and limits are in our Refund Policy. WooCommerce's own developer documentation puts keyboard testing after automated testing and then points at free screen readers, VoiceOver and NVDA, by name.
Related reading: accessiBe alternatives, by category · Got an ADA demand letter? What to do · Can you pass a scan and still get sued?
Fix47 is not a law firm and does not give legal advice.