The Workshop

Accessibility & Digital Conformance

Is My Shopify or WordPress Site ADA Compliant? A Free, Honest Self-Check (2026)

Short, honest answer: no website can be declared "ADA compliant" by a tool, a scan, or a badge — and anyone selling you that certainty should make you nervous. But you can find out where your site actually…

Run free diagnostic View paid tool · $149

Short, honest answer: no website can be declared "ADA compliant" by a tool, a scan, or a badge — and anyone selling you that certainty should make you nervous. But you can find out where your site actually stands, fix the real barriers, and build a record that holds up. This guide shows you how to do that yourself, for free, in your browser — whatever platform you're on.

Not legal advice. This is general educational information and does not create an attorney–client relationship. If you've already received a demand letter or lawsuit, talk to a qualified attorney before doing anything else.

First, the honest framing most articles skip

There is no single federal regulation that pins one technical standard on private businesses under ADA Title III. In practice, courts and the plaintiff's bar widely treat WCAG 2.1 Level AA as the working target. And small businesses are not immune — per Seyfarth's tracker (adatitleiii.com, March 2026), plaintiffs filed 3,117 federal website-accessibility lawsuits in 2025, a 27% increase from 2024.

So "am I compliant?" is the wrong question, because no honest answer to it exists in a yes/no form. The better questions are: "What are the real barriers on my key pages? Have I fixed them? Can I show what I did?" Those you can answer.

Step 1 — Capture your page correctly (this trips up most platforms)

Before any check, you need the right HTML — and on modern platforms this is easy to get wrong.

  • "View Page Source" shows the raw HTML your server sent before JavaScript runs. On Shopify, Squarespace, Wix, Webflow, and React/Vue-based WordPress themes, the real buttons, images, and form fields are often added after load by JavaScript. View-Source will miss them, and any check will look misleadingly clean.
  • Use the rendered HTML instead. Open the page → DevTools (F12 or right-click → Inspect) → Elements tab → right-click the top <html> element → Copy → Copy outerHTML. That's what users actually experience. (Safari: enable the Develop menu in Settings → Advanced first.)

Do this for each type of page: home, a collection/category, a product or service page, the cart, and checkout or your main contact form.

Step 2 — The machine-detectable checks (a scanner finds these)

These are the issues automated tools can reliably flag. Each maps to a real WCAG criterion:

  • Page language set — <html lang="en"> (WCAG 3.1.1)
  • A non-empty <title> (2.4.2)
  • Images have an accessible name — meaningful alt, or alt="" for purely decorative ones (1.1.1)
  • Buttons and links have an accessible name — icon-only controls (cart, hamburger, search) need an aria-label (4.1.2)
  • Link text is meaningful — not "click here" / "read more" out of context (2.4.4)
  • Form fields have a real <label> — a placeholder does not count (3.3.2 / 1.3.1)
  • Headings are sane — there's an <h1> and levels aren't skipped (1.3.1)
  • A <main> landmark and a skip link exist (1.3.1 / 2.4.1)
  • No non-button clickables — onclick on a <div> isn't keyboard-operable (2.1.1)
  • No duplicate ids and *no broken aria- references (4.1.2**)

You can check many of these by reading your rendered HTML, or with a free scanner. But here's the catch that this whole article hinges on.

Step 3 — The manual tests a scanner can NEVER judge

Deque's automated coverage report found that automation identified 57.38% of total issues in its audit sample, while still covering only 16 of 50 WCAG 2.1 Level AA success criteria. A "passing scan" that skips the human-judged criteria means almost nothing. Budget 30–45 minutes for an honest first pass on your key journey (home → product/service → cart → checkout, plus search and any contact/login form).

  1. Keyboard operability (2.1.1). Put the mouse aside. Using only Tab, Shift+Tab, Enter, Space, and arrows, try to reach and operate everything — menus, dropdowns, size swatches, the cart, checkout. Can you finish a purchase? Do you ever get trapped (focus stuck)? Pass only if everything is reachable and nothing traps you.
  2. Visible focus (2.4.7). As you Tab, is there always a clear outline showing where you are? A very common theme failure is outline:none with no replacement — it makes the site unusable for keyboard users.
  3. Alt-text quality (1.1.1). Automation sees whether alt exists, never whether it's any good. Is it meaningful ("Red wool winter coat, front view"), not a filename ("IMG_2381.jpg")? Are decorative images alt=""?
  4. Color contrast (1.4.3). Body text should meet 4.5:1; large text 3:1. The easy misses: text over images, prices/badges, button labels, placeholder text. Use your DevTools contrast readout or WebAIM's checker.
  5. Reflow / zoom (1.4.10). Set zoom to 400% or resize to ~320px wide. Does content reflow to a single column with no horizontal scrolling and nothing clipped?
  6. Form error identification (3.3.1). Submit checkout/contact with a deliberate mistake. Are errors shown in text (not colour alone), telling the user how to fix each one?
  7. Captions/transcripts (1.2.2). Videos with speech need synced captions; audio-only needs a transcript. (Mark N/A if you have no media.)

Free help, no expertise required: your OS screen reader — VoiceOver on Mac (Cmd+F5), Narrator on Windows (Ctrl+Win+Enter). You don't need to be an expert; you need to try the journeys the way a disabled user would and record what you find honestly.

Platform-specific gotchas worth knowing

  • Shopify: the worst repeat offenders are icon-only buttons (cart/menu/search) with no accessible name, size/variant swatches built as un-keyboardable <div>s, missing lang in the theme layout, and missing visible focus styles. App embeds can re-introduce issues after you've fixed them — re-check after installing apps.
  • WordPress / WooCommerce: check that your theme doesn't strip focus outlines, that plugin-generated forms label their fields, and that page builders (Elementor, Divi) aren't emitting heading levels purely for visual size. Plugins and theme updates can regress accessibility — re-scan after each.
  • Squarespace / Wix / Webflow: heavily JavaScript-rendered, so always use the rendered-HTML method above; watch contrast on image overlays and the keyboard operability of custom interactions.

Whatever the platform, the principle is identical: fix the source, not a cosmetic overlay. Overlay widgets that promise instant compliance don't change your markup — and the FTC's April 2025 final order required accessiBe to pay $1 million and barred it from claiming an automated product makes sites WCAG-compliant.

Step 4 — Turn your findings into something useful

A list of problems isn't the goal. The goal is: real fixes, plus a record you can stand behind. Do these three things and you've moved from "no idea" to "documented good-faith position":

  1. Prioritise and fix the real barriers top-down (critical → serious → moderate).
  2. Log each fix with a date and the WCAG criterion — this dated record is the most credible evidence of effort you can produce.
  3. Publish an honest accessibility statement — "partially conformant + here's our plan + here's our contact." Never "100% compliant"; over-claiming is its own risk.

Want this done in an afternoon instead of a weekend?

If you'd rather not assemble all of this by hand, the ADA Web-Accessibility Defense Kit ($149, one-time) does exactly this workflow in your browser — nothing uploaded. Paste a page's HTML, run the seven guided manual tests, log your fixes, and it generates a prioritised developer report (element → problem → fix → WCAG reference), an honest accessibility statement, a VPAT-style conformance summary, and a dated Defense File for your attorney. It works for Shopify, WordPress/WooCommerce, Squarespace, Wix, Webflow, and custom sites alike, and it's backed by a 30-day money-back guarantee.

You can also run the free in-browser checker first to see your highest-risk barriers at no cost.

Honest caveats, stated plainly: the Kit is a self-assessment tool, not legal advice, not an audit, and not a guarantee of compliance. It shows you what to fix and documents that you did — the step it can't replace is a qualified human review. And if you've already received a letter, that attorney comes first.

The bottom line

You can't buy a yes/no "ADA compliant" verdict, and you shouldn't trust anyone who sells one. What you can do — today, for free, in your browser — is capture your real pages, run both the machine checks and the manual tests, fix the genuine barriers, and keep a dated record. That documented, honest effort, confirmed by a professional, is the credible position. Start there.

Sources: FTC final order requiring accessiBe to pay $1M (April 2025); Seyfarth / adatitleiii.com 2025 federal filing data (March 2026); DOJ ADA web-accessibility guidance; Deque automated-coverage report; WCAG 2.1 success criteria. Educational only, not legal advice.