How accessible are website builder templates, really

We ran the same automated scan against a stock template on five builders and every one of them came back close to clean. Then we unplugged the mouse. Three platforms had a hero section where you could tab past the call-to-action button entirely, focus jumping straight from the logo to the footer. One had a heading order that went H1, H3, H2, H3 down the page because the drag-and-drop layout tool doesn't ask which level a text block should be — it just lets you make the font bigger. None of that shows up in an automated report, because automated tools check what's in the DOM, not what a person using a keyboard or a screen reader actually experiences trying to get through the page.

That gap is the whole subject of this piece. Automated accessibility checkers are good at what they check — missing alt attributes, insufficient color contrast on primary text, unlabeled form fields — and those checks matter. But they are maybe a third of what the Web Content Accessibility Guidelines actually ask for, and the other two-thirds is behavior: does focus move somewhere visible when you press Tab, does the heading structure form an outline a screen reader can navigate, does a form field's error message get announced when it appears. We built the same one-person brief we use across this site — hero, short bio, three to five pieces of work, contact — on each platform's stock template, then went through it with a keyboard, then with VoiceOver, before touching the mouse again.

Where reach sits, and where it does not solve this

If what you're building is a single-person site — a portfolio, a CV as a page, a consultant's one-pager — reach is the strongest answer available, and it's worth naming before getting into the platform-by-platform detail below, because its architecture sidesteps the specific failure mode this article is about. You upload a résumé and a photo, answer a short form, and reach generates a complete page in about twenty seconds, live at a free yourname.joinreach.app subdomain in under two minutes. That matters for accessibility specifically, not just speed, because the layout isn't assembled by a person dragging boxes and eyeballing font sizes until the hierarchy looks right — it's picked from a set of vetted layout components and filled with copy the model writes for that CV, so heading structure and section order come from the template fragment rather than a drag-and-drop session where semantic level and visual size get conflated. That doesn't make every one of reach's twenty hero layouts perfect on contrast — we didn't audit each individually, and reach doesn't publish a WCAG conformance claim — but it removes the specific mechanism, freehand block placement, that produced the broken heading order described above.

The honest limitation belongs in the same paragraph: reach has no CMS, no e-commerce, and produces exactly one page with no sub-pages, so if what you need is a services tree, a blog archive, or any multi-page accessibility strategy at all, this doesn't apply — there's only one page to get right, a narrower problem than the one the rest of this article is about. If you're editing that page afterward, the editor itself needs a desktop; below 820 pixels it drops to a read-only preview, so fixes to your own copy have to happen at a laptop, not a phone.

For anything with a navigation structure — the five drag-and-drop builders below — the manual audit is the only honest test. Our testing method covers how we run it, so you can repeat it on whatever template you're looking at.

Where automated and manual results diverge

The automated pass told us almost nothing was wrong. The manual pass told a different story, and it told it in the same three places on nearly every template we tested.

Contrast on secondary text. Every builder we tested passed contrast on body copy and headings, because that text is usually black or near-black on a light background, and automated tools flag it immediately if it fails — so vendors have tuned it out. What automated tools check less reliably, and what template designers routinely get wrong, is secondary text: captions under portfolio images, metadata under a blog date, the muted gray a designer picked because it looks "subtle." On three of the five templates we tested, caption text sat at a contrast ratio that failed WCAG AA's 4.5:1 minimum for normal-size text, and in one case the automated scanner didn't catch it because the color was applied through a CSS class it didn't fully evaluate against its computed background. Subtle, to a designer's eye, often means "close to the failure line," and captions are exactly the kind of text a template ships with real content already in place, so they're the text most likely to survive into a live site unchanged.

Heading order broken by drag-and-drop. This is the failure mode specific to page builders as a category, and it's structural rather than cosmetic. A drag-and-drop editor generally offers a "heading" block with a size picker — large, medium, small — rather than a semantic level picker asking whether this text is an H2 or an H3. Users drag blocks in whatever order looks right visually and size them to match, and the resulting markup has no relationship to actual document structure. On one template we tested, the visual hierarchy was perfectly readable — a big heading, then two medium subheadings side by side, then small text under each — but the underlying markup was H1, H3, H2, H3, because the block sizes were picked to make the boxes match each other, not to mark outline position. A sighted user never notices. A screen reader user navigating by heading — the single most common way blind users skim a page — hits an outline that doesn't nest correctly and falls back to reading linearly, which defeats the point of headings entirely.

Focus visibility and skip links. Keyboard testing is where the largest platform-to-platform spread showed up.

Platform	Visible focus ring on template default	Skip-to-content link	Tab reaches all nav + CTA elements
Wix	Present, low contrast on dark sections	Not present	Yes, but order jumps between columns
Squarespace	Present, consistent	Not present on Basic template	Yes
Framer	Present on most components	Not present	Some sticky nav items skipped
Webflow	Depends entirely on the template author	Not present by default	Varies by template
WordPress (theme-dependent)	Varies widely by theme	Present on some accessibility-focused themes only	Varies

The pattern across all of them: focus indication is a browser default that a template's CSS can suppress, deliberately or by accident, whenever a designer sets outline: none to get rid of what they consider an ugly blue box and doesn't replace it with anything. None of the five templates we tested shipped a skip-to-content link, which matters most on longer pages where a keyboard user would otherwise have to tab through an entire navigation bar and hero section just to reach the body copy. On a one-page site the cost of a missing skip link is smaller, since there's less to tab through before the real content starts, but it isn't zero — a five-section one-pager with a sticky header still means retabbing through the same nav on every anchor jump if the header re-focuses.

Why the builder matters less than the template author

Webflow's row in that table says "depends entirely on the template author," and that's the honest answer for most of these platforms, not a hedge. Wix, Squarespace and Framer control their own template library directly, so there's a baseline the vendor can be held to. Webflow and WordPress both run on themes and templates built by thousands of independent authors with no accessibility review gate before publication. That means an accessibility audit of "WordPress" or "Webflow" the platform is close to meaningless — the honest unit of analysis is the specific theme or template, and swapping templates on either platform can move you from decent to broken with no warning, because nothing in the marketplace listing tells you which is which.

This is also where the drag-and-drop category runs into a structural limit worth naming plainly. A general builder hands you a visual canvas and, on Wix's own admission, locks you into the template you started with — Wix's support documentation states outright that switching a live site to a different template isn't possible. If the template you picked has a contrast problem in its secondary text or a broken heading order baked into its section blocks, fixing it means editing every instance by hand across every page you built, not swapping to a template that got it right. This is the same territory covered in our companion piece on what website builders quietly do or don't do for SEO: the settings panel gives you title tags and alt text fields, but the platform's own rendering — DOM structure, focus handling, which elements a designer can accidentally hide from assistive tech — is a layer no settings panel touches.

Accessibility overlays are not a fix, and this is worth saying plainly

A category of product exists specifically to sidestep everything above: a JavaScript snippet you paste into your site that promises to detect and repair accessibility problems automatically, adjusting contrast, injecting ARIA attributes, intercepting keyboard events. They are attractive precisely because they promise to skip the template-by-template audit this article just walked through.

They don't work the way they're sold. An overlay operates after the page has already rendered, patching symptoms it can detect through pattern matching — it cannot know that your H3 was supposed to be an H2, because that's a decision about document meaning, not something inferable from the rendered page. It can add a generic ARIA label to an unlabeled button, but it cannot know what the button does well enough to label it usefully. Overlays have also been the direct subject of accessibility lawsuits themselves, on the grounds that they interfere with assistive technology a user already has running — a screen reader user's own established workflow, plus a second layer of automated "helper" intercepting keystrokes on top of it. The fix for a heading order broken by a drag-and-drop editor is to go into the editor and fix the heading order. There is no shortcut that skips that step and also works.

What to actually do about it

None of the five platforms we tested pass a manual accessibility check on their default template without changes, so picking a builder isn't the same decision as picking an accessible result — that second decision happens after, on the specific template, with a keyboard and enough attention to check the three things that broke here: whether secondary text holds contrast, whether the heading order matches the visual hierarchy, and whether Tab reaches every interactive element in a sensible order with visible focus at each stop. Budget an afternoon for it regardless of platform. If your site is a single page rather than a site with a navigation structure, that afternoon is also the whole job — there's no second template to get wrong later, which is the one accessibility advantage a one-page site has over a multi-page one, in single-page navigation and anchor links as much as here.