What AI coding tools can (and can't) fix on your Shopify or WooCommerce store
If you run a Shopify or WooCommerce store and you write code at all, there's a good chance you write less of it than you used to. The product card tweak, the custom checkout field, the Liquid section that fixes the mobile menu, the WooCommerce template override that hides a confusing option at checkout: most of these now start in Cursor, Copilot, or Claude Code, and end up in your theme after a quick review.
This is genuinely good. The custom bits of a store are exactly where accessibility regressions used to creep in, because they were the bits nobody had the time to test. AI coding tools have started catching some of those regressions on the way in.
But there's a real question underneath, and it's the one this post is about. With the European Accessibility Act now in active enforcement, and with a steady drip of "is your Shopify store EAA-ready?" articles in the trade press, founders running small commerce teams need a clearer map of where AI coding tools actually help, where they don't, and which parts of their store's accessibility are theirs to own in the first place.
The ownership map
A typical Shopify or WooCommerce store is not one codebase. It's four layers stacked on top of each other, and each layer has a different owner. Before you can ask "can AI fix this?", you need to know whose code we're talking about.
The platform layer. Shopify core. WordPress core. The admin, the checkout flow on most Shopify plans, the underlying request lifecycle. You don't see this code. You can't edit it. If there's an accessibility bug here, your job is to report it, not fix it.
The vendor theme. Dawn, Sense, Refresh on Shopify. Storefront, Astra, OceanWP on WordPress. Themes ship with most of your storefront's accessibility behaviour built in: heading structure, focus styles, the announcement bar, the cookie banner colours. You can fork a theme and edit it, but if you don't fork it, the theme author owns the fixes.
Plugins and apps. The filter widget, the product reviews block, the upsell popup, the chat bubble. Each of these is a separate vendor's code dropped into your page. You can usually configure them, sometimes style them, rarely fix them. Their accessibility is mostly the plugin author's problem.
Your custom code. Theme overrides, custom sections, custom checkout fields, custom Liquid snippets, custom WooCommerce templates, and every piece of content you write: product titles, descriptions, alt text, button copy, form labels. This is fully yours. This is where AI coding tools live, and this is the layer the EAA inspector will look at if your store ends up in their inbox.
The first useful thing to do is mentally separate these four layers. Most "is my store accessible?" anxiety dissolves once you realise that maybe 20% of what's on the page is actually under your direct control, and that 20% is where your time goes.
What AI coding tools can fix in the parts you own
The custom layer is where Cursor, Copilot, and Claude Code earn their keep. Once you tell them you care about accessibility, they reliably handle a meaningful subset of the work.
Form labels and structure. A custom checkout field with a missing label, a contact form with placeholder-only inputs, a quantity selector built with bare <input> tags. AI tools rewrite these into properly labelled HTML without much prompting.
ARIA on custom widgets. A custom "filter by size" widget made of <div>s, a mega-menu that needed keyboard support, a slide-out cart with no role on the container. AI tools know the standard ARIA patterns and apply them correctly most of the time.
Contrast in custom CSS. When you ask Claude Code or Cursor to make a button readable, it will check the contrast ratio and pick colours that pass. It's not perfect, but it's a lot better than picking from a colour palette by eye.
Alt text scaffolding on product images. AI tools will add alt attributes to every <img> in your custom sections by default now, and will suggest descriptive text based on surrounding context.
Focus management in custom JavaScript. When you build a modal, a tab interface, or a multi-step form, AI tools will add the focus moves you'd otherwise forget: focusing the first input when a dialog opens, returning focus to the trigger when it closes.
This is what the accessibility tooling world calls the automatable layer: the roughly 30–40% of WCAG that has a clean computational definition. AI coding tools have got reasonably good at it, especially when they're pointed at it explicitly.
What AI coding tools cannot fix on their own
The other 60–70% of accessibility is judgement, context, and discipline across time. AI coding tools help, but they don't close the gap on their own.
Whether your alt text is correct. A scanner sees that an <img> has an alt attribute. AI can suggest text from context. Neither can decide that the relevant detail in your product photo is that the dress has pockets, or that the headphones come in matte black versus glossy black, or that the model is wearing the medium size. That judgement belongs to whoever knows the product, which is you.
Consistent identification across pages. Your "Add to cart" button on the product page should not be called "Buy now" on the quick view modal and "Add" in the mini-cart. WCAG 3.2.4 (Consistent Identification) only exists across pages and components. AI tools edit one file at a time and have no memory of what they called the same component three weeks ago.
Focus order through a multi-step checkout. A scanner can confirm every field is reachable. AI can confirm tab order in a single template. Neither can confirm that the experienced sequence through a four-step checkout, with conditional shipping options and a discount-code field that appears mid-flow, actually makes sense.
Error messages that help. "Invalid input" passes the scanner. "Postcode should be 5 digits, you entered 4" actually helps. AI tools default to the generic version unless you push them, and the push only sticks for that one form.
The evidence trail itself. If a regulator, a procurement officer, or a B2B customer's accessibility lead asks "what about WCAG 2.4.7? What about 1.4.11? What about 3.3.3?", "we use Cursor and it follows accessibility rules" is not the answer. The answer they want is a list: criterion, status, evidence, date.
These limits are not a criticism of AI coding tools. They're the shape of accessibility itself. WCAG was written to be human-judged, and the parts that require human judgement still require human judgement. AI helps with the typing, not with the thinking.
Where AI fits, and where the layer above fits
For a Shopify or WooCommerce founder, the practical picture looks like this.
In your IDE, with an AI coding tool, you can confidently handle the mechanical parts of accessibility for everything in your custom layer: form structure, ARIA, contrast, focus management, basic alt text. This is real work and worth doing. It raises the floor on every PR you ship.
Above that, you need two things AI coding tools don't give you. You need a map of which WCAG criteria apply and which ones you've actually checked, because "we follow accessibility rules" isn't the same as "we evaluated all 50 applicable criteria for our checkout flow." And you need a record of who fixed what and when, because a fix that gets undone by next week's theme update is not a fix that helps you under the EAA.
This is the layer Jeikin sits in. It runs through the same AI coding tool you already use, via the Model Context Protocol. When you ask Claude Code or Cursor to review or fix something accessibility-related, Jeikin steps in to enforce WCAG rules on whatever the AI writes, regardless of whether the output is Liquid, PHP, React, or plain HTML. It tracks each finding against the specific success criterion it violates, and it keeps the evidence trail current as you ship.
It's honest about what it doesn't do. It doesn't crawl a deployed Shopify URL with a logged-in session today, so we can't replace the runtime scan against your production checkout. It doesn't ship as a Shopify App Store entry or a WordPress plugin yet, so the integration is through your AI tool, not your platform admin. And it doesn't fix vendor code for you: if the Dawn theme ships a contrast bug, Jeikin will tell you which criterion it violates and where, so you can escalate to Shopify, fork the theme with a documented reason, or swap themes with evidence. You're not powerless on the parts you don't own. You just need a record.
The defensible position
The goal for a small commerce team is not "fix everything." It is knowing which parts of your store you own, which parts your platform and vendors own, which of your parts AI coding tools can reasonably handle, and which need evidence rather than fixes.
That separation is what turns a vague worry about the EAA into a workable plan. The parts you own get the AI-tools-plus-discipline treatment. The parts you don't own get a documented position, ready to attach to a procurement form or hand to a vendor as a feature request. And the layer above it all is a list of WCAG criteria with a status next to each one, so the question "are we accessible?" has an answer that isn't a shrug.
If you've already wired Cursor, Copilot, or Claude Code into your workflow for the custom bits of your store, you have most of what you need. The remaining piece is the one that turns "we use accessibility tools" into "here is what we evaluated, here is what passed, and here is what we did about the rest." That piece is what we built Jeikin for, and it works the same way against a Liquid file as it does against a React component.
Your store is four layers. Your code is one of them. AI coding tools handle a sizeable slice of that layer well. The rest, including the proof that you handled it, is the work above.