Most people arrive at accessibility through a shock. A complaint, a letter, a procurement questionnaire, a customer who could not check out. The instinct is to fix everything at once, and that is the one approach that reliably fails.
The order below is what we would do with our own site.
Week One: Find Out What You Are Dealing With
Do not fix anything yet. You cannot plan against a problem you have not measured, and the first fix people reach for is usually a symptom rather than a cause.
- Run a free scan. It takes minutes and finds the machine-detectable failures. Ours covers ten pages, and what it cannot see is written down honestly.
- Try your own site with the keyboard. Put the mouse away and buy something, or fill in your main form. This finds problems no scanner reports, and it takes ten minutes.
- Find out which law applies to you. The laws section covers 38 of them. Which one you are under decides your deadline and your standard.
What you are looking for
Not a list of defects. A sense of whether you have a handful of content problems or a structural one in your templates. Those need completely different plans.
Week Two: Fix the Things That Block People
Some accessibility failures are annoying. A few stop somebody completing the thing they came to do. Those are not the same, and treating them as one queue is how teams spend a month on alt text while the checkout stays unusable.
Start with the four the standard itself singles out. WCAG names four criteria that apply to everything on a page, including content you would otherwise not have to claim conformance for, on the reasoning that failing any of them breaks the page for everybody. Audio that plays by itself with no way to stop it. A keyboard trap. Moving content that cannot be paused. And anything that flashes more than three times a second.
Deal with those first, and put the flashing one at the top even though it is the rarest. It is the only criterion on the list whose failure mode is a seizure, and it is the one your week one scan will definitely not have mentioned, because the whole guideline covering seizures has no automated rule anywhere.
Then the blockers that stop people finishing, in this order.
- Anything that cannot be done with a keyboard. A menu that only opens on hover, a dialog with no way out, a form you cannot submit. See keyboard accessibility.
- Form fields with no labels. A form that cannot be understood cannot be completed, and forms are usually where your revenue is.
- Errors that are shown but never announced. The user submits, hears nothing, and assumes the site is broken.
- Text nobody can read. Contrast below the threshold on body copy, which is also the easiest thing on this list to fix.
Know which of those four your week one scan will have found, because it is only half of them. Contrast it finds, and it flags fields with no accessible name at all, though a field labelled only by placeholder text passes. Errors that are shown and never announced it does not find, because that criterion has no automated rule. And focus order, which decides whether a keyboard journey makes sense, has none either. So two of your four week two items come from the keyboard pass rather than from the report.
Fix all of it in the template rather than the page. One header component usually carries the same defect across every page you have, and there is a rule behind that as well as an efficiency argument. Conformance belongs to whole pages, and every page in a process has to conform for the process to conform, so a defect in a checkout step takes the whole checkout down with it.
Week Three: Decide How Far You Are Going
There is a real decision here, and it is yours rather than your developer's.
| Position | What it means | When it fits |
|---|---|---|
| Fix the blockers | Nobody is stopped, but you would not pass an audit | Very small sites, no legal deadline |
| Meet WCAG 2.2 AA | The level nearly every law names, verified | Most businesses, and anyone with a deadline |
| AA plus selected AAA | The standard, plus the enhanced rules worth having | Sites serving people with disabilities directly |
Level AA is what the laws name, and it is what our audits test. The difference between the levels is worth ten minutes of your time before you commit to one.
Week Four: Get It Verified
A scan tells you what a machine can see, and our own technique-by-technique count puts that at 10 of the 356 WCAG techniques and failures we graded, which is 2.8%. A scanner sees 228 of them only in part, and 118 we grade as needing a person from start to finish. That part needs a person, and some of it needs a person who uses a screen reader daily.
This is the point where an audit earns its money, because it tells you what you still do not know. Ours is a fixed price and covers all 55 A and AA rules, with what it costs set out on the pricing page. If you are choosing between providers, our guide to picking an auditor lists the questions worth asking.
What Not to Do First
- Do not install an overlay. The tracker that follows these cases counted over a thousand sites sued in 2024 with one already running. And in 2025 the FTC ordered one vendor to pay $1 million that may be used to provide refunds to consumers, and barred it from claiming its automated product makes any website WCAG-compliant without evidence. The full record is on our overlays page.
- Do not write an accessibility statement before you have fixed anything. A statement is a dated, published, checkable claim, and one claiming conformance you do not have is worse than no statement at all. Regulators do read them. UK public sector monitoring across 1,203 sites found 85% had published one and many were out of date and unreviewed for over a year.
- Do not start with a full manual audit of every page. Fix the template-level failures first, or you will pay to have the same defect reported forty times.
- Do not train the whole team on day one. Training lands when people have a specific thing to apply it to, which is our position rather than a researched one, argued at more length in training your team.
What Your Theme Marketplace Checked Before It Listed Your Theme
Most of what week one turns up came with your theme rather than from your team, so it is worth knowing what, if anything, the marketplace checked before it took the listing. The answers are completely different from one platform to the next, and only one of them is a real bar.
| Marketplace | What it checks | What that gets you |
|---|---|---|
| Shopify | A minimum average Lighthouse accessibility score of 90 across the home, collection and product pages, on desktop and mobile, plus named checkpoints on keyboard access, visible focus, 4.5:1 and 3:1 contrast, and 24 by 24 pixel targets | The only mandatory bar in this table, and still an automated score |
| WordPress | A review against the theme review team's own accessibility-ready standard | A reviewed theme, and a handbook that says in terms this does not mean Level AA |
| Drupal | Nothing. Drupal.org states that it does not currently certify contributed themes for accessibility | Read the theme yourself, or pay somebody to |
| BigCommerce | Publishes theme accessibility guidance and sets no marketplace requirement we could find | Advice the theme author may or may not have taken |
| Webflow, Framer, Wix, Squarespace, HubSpot | No published bar found on any of the five | Nothing you can lean on |
Read Shopify's row carefully before you relax, because a Lighthouse score of 90 is an automated score and automation reaches a fraction of the standard. It is a real requirement, enforced before listing, and it is not a conformance check. Read BigCommerce's the same way. Its published guidance covers keyboard access and contrast and says nothing about focus indicators, forms or target size, which tells you roughly where its themes will fail.
And then the sentence that settles all five rows at once, which WordPress publishes about its own themes and which is true of every platform on the list. WCAG measures content accessibility, so it cannot be applied to a theme at all, because conformance in the standard belongs to a web page rather than to the code that renders one. No marketplace can sell you a conformant theme. The most any of them can do is stop you starting from a hole, and that is worth having.
If the Worst Problems Are not Yours
Week one turns this up more often than people expect. The booking embed, the consent banner, the chat bubble. Somebody else's code, on your page, and you cannot edit it.
The standard has a mechanism for exactly that, called a Statement of Partial Conformance, and it lets you describe honestly what conforms and what does not rather than choosing between an overclaim and silence. It does not excuse you. It gives you somewhere truthful to stand while you push the vendor, and pushing the vendor with a precise written list of what fails is what actually moves them.
After the First Month
The work shifts from fixing to keeping. That is a different discipline, and it is covered in keeping a site accessible.