There is no such thing as an ADA-compliant website builder

Start with the law, because the phrase borrows its authority from it.

In the United States, the Department of Justice published a final rule on 24 April 2024 setting a web accessibility standard — WCAG 2.1 Level AA — for the web content and mobile apps of state and local government entities. That is Title II of the ADA. An interim final rule published on 20 April 2026 moved the compliance dates out by a year, to 26 April 2027 for public entities with a total population of 50,000 or more and 26 April 2028 for smaller entities and special district governments.

Read that scope carefully, because a great deal of marketing depends on readers not doing so. The rule covers governments. For private businesses under Title III of the ADA, the Department of Justice has not issued a regulation setting a technical web standard. Anyone telling you that a specific product makes you "ADA compliant" as a private business is asserting something more definite than the regulatory record supports.

In the European Union, Directive (EU) 2019/882 — the European Accessibility Act — has applied through national measures since 28 June 2025, and the harmonised standard the sector works to is EN 301 549. The directive exempts microenterprises providing services, defined in its own text as undertakings with fewer than ten employees and annual turnover or balance-sheet total not exceeding two million euros. Whether that exemption reaches you is exactly the kind of question a lawyer answers and a website builder does not.

None of this is settled by a signup. So the useful question is a narrower one.

Headroom is the word used throughout this site for the only thing a platform genuinely controls: how much accessible ground it hands you before you start working, and how hard it is to ruin.

A platform with wide headroom gives you semantic markup you cannot easily break, a visible focus indicator that arrives switched on, a skip link you did not have to build, form fields with real labels attached, alt-text fields in every place an image can be inserted, and a theme system whose defaults clear contrast thresholds rather than needing to be dragged there. A platform with narrow headroom hands you an empty canvas, absolute positioning and a note wishing you luck.

Headroom is not a compliance score and it is not a prediction. A platform at the top of this scale can still be used to publish something nobody can operate — a hero image with no alternative text, a form with placeholder text pretending to be labels, a colour scheme dragged into the unreadable, a video with no captions. That is not the platform's doing. It is just true.

Webflow is at the top of this list for a reason that is also its risk. It does not abstract the document away from you. You choose which element a div actually is, you control the heading levels directly, and the contrast checker sits inside the colour picker where the decision is being made rather than in a report you read afterwards. Webflow's documentation describes an Audit panel that flags issues including missing alternative text, empty links and heading-structure problems, with contrast handled separately in the style panel rather than in the panel itself.

That is genuinely more than most builders give you. It also means that every structural mistake available to a hand-coded site is available to you. Webflow will not stop you from building a navigation menu out of unlabelled divs. If you want the honest summary: Webflow removes the platform's excuses and hands you all of the responsibility.

Check the panel in your own editor before you rely on this description — Webflow's help centre would not serve us the canonical article, and a tool's checklist is the sort of thing that changes without an announcement.

Wix ships an Accessibility Wizard. It scans the site and reports in two tabs: Detected issues and Manual tasks. Detected issues are split between site-level problems such as the main language setting and DOM order, and page-level problems such as missing alternative text and insufficient colour contrast. It reaches into pages generated by Wix's own Stores and Blog apps, which is more than a browser extension pointed at your home page will do. It references WCAG 2.2.

Two things are worth saying about it, and Wix says the first one itself. From the Wix help centre:

we cannot guarantee that your site will be compliant with your region's accessibility laws and regulations after using the Wizard

That is a platform being straight with you, and it belongs in any honest assessment.

The second is about the split between the two tabs. The "manual tasks" list is where the judgement lives — whether an image is decorative or meaningful, whether colour is being used to carry information on its own, whether a zoomed layout still works. A wizard can tell you an alt attribute is empty. It cannot tell you that the alt text you wrote says "image1". The wizard raises the floor considerably and it does not move the ceiling.

Squarespace does not ship a checker of any kind, and its own help documentation sends you to outside tools instead. What it does ship is a set of defaults you get without asking: a Skip to Content link, a keyboard focus outline that appears when visitors tab through links and form fields, semantic page structures, pre-labelled form fields, alt-text fields, colour-contrast options, and captions and transcripts for media.

That list matters more than it looks. A skip link and a visible focus outline, arriving by default, quietly satisfy two things most sites get wrong. Squarespace also writes one of the clearest disclaimers in this comparison:

This guide is a resource, but it's not legal advice. Squarespace doesn't give advice on specific accessibility laws or standards applicable to your site or business.

What you are trading away is discovery. With no scanner, every problem on a Squarespace site is one you have to go and find, which is why the keyboard test on this site exists.

Shopify's accessibility work is concentrated somewhere unusual — in the requirements a theme must meet to be admitted to the Theme Store. Those requirements are published and specific. Themes must be keyboard accessible including dropdown navigation; focusable elements must show a visible focus state; all images require the alt attribute; form inputs must have unique IDs with matching for labels; keyboard focus order must match DOM order; touch targets must be at least 24 by 24 CSS pixels; and body text contrast must reach 4.5:1, with 3:1 for text above 18pt and for non-text elements such as borders and icons.

Read the scope of that. It describes what a theme has to demonstrate to be listed. It is not a statement about your storefront after you have changed the colours, added four apps and pasted a review widget into the product template. Every one of those steps happens outside the requirement, and the app ecosystem in particular is where accessible Shopify themes go to die.

WordPress.com says it aims for all of its themes to be accessible while acknowledging that some add complexity which "may compromise certain aspects of accessibility", and it surfaces a subset tagged Accessibility Ready. That tag comes from the wider WordPress project, and it is worth knowing what it is: a theme-directory standard with its own requirements, based on WCAG but adapted for themes. It is not a declaration that a theme meets Level AA.

Alt text is available in the block editor wherever media appears — the Image, Gallery, Cover and Media & Text blocks all carry the field. And WordPress.com states the principle behind this entire page more plainly than we could:

We provide an accessible platform, but an accessible website is determined by the site owners and their awareness of the accessibility tips on this page.

The reason WordPress.com sits at the bottom of this list is not the platform. It is the surface area. The more plugins and blocks you add, the more independent authors' code decides what your markup looks like.

Whichever platform you choose, this list does not move:

• Alternative text that says something. A present alt attribute is not the criterion; SC 1.1.1 Non-text Content is about the text serving the same purpose as the image. Decorative images take an empty alt so assistive technology skips them.
• Headings in order, describing the page. SC 1.3.1 Info and Relationships. One h1, no levels skipped, and headings chosen for structure rather than for how big they look.
• Colour that is never the only signal. SC 1.4.1 Use of Color. If the only thing distinguishing a link from surrounding text is its hue, the link is invisible to a share of your readers.
• Contrast you measured. SC 1.4.3 asks 4.5:1 for body text at Level AA and 3:1 for large text. The enhanced criterion, SC 1.4.6 at Level AAA, asks 7:1 and 4.5:1. Low contrast text was detected on 83.9% of the top million home pages in the WebAIM Million's 2026 analysis, which makes it the most common failure on the web by a distance.
• Everything reachable by keyboard. SC 2.1.1. If you cannot tab to it, it does not exist for a large number of people.
• Labels on every field. SC 3.3.2. Placeholder text is not a label; it disappears the moment someone starts typing.
• Captions on video, and a page language. SC 3.1.1 is one attribute on one element, and the same 2026 analysis found it missing on 13.5% of home pages.

If you are procuring rather than deciding for yourself, the platform question is not the interesting one. Three things will matter more.

Ask for an accessibility conformance report and read the conformance column rather than the marketing page. Write your actual requirement into the contract with the standard and level named, so "accessible" is not left to interpretation. And budget for testing by people who use assistive technology, because no scanner, wizard or panel in this comparison can tell you whether your checkout is usable — only whether it is superficially well-formed.

Then talk to a lawyer about your obligation. That is the sentence this page has been building towards, and it is the only advice on it that is worth anything.