Squarespace accessibility checker

Check the live page. Trace the barrier to content, a block or custom code.

ClearSite tests the page visitors receive, recognises Squarespace signals in the rendered markup, and gives you a practical route back to the likely source.

Check a Squarespace page freeNo extension or Squarespace account required for the first scan.

Built around rendered Squarespace output

A polished template can still contain a page-level barrier.

ClearSite runs axe-core against the live DOM, records the affected element and groups findings by severity. Squarespace detection uses public page signals such as static.squarespace and sqsp; it does not claim to identify the exact editor control automatically.

Page content

Image descriptions, heading order and link wording can come from editable page content even when the template is sound.

Built-in blocks

Forms, galleries, social links and navigation controls need useful names, keyboard behaviour and focus in the rendered page.

Site-wide styles

Colour and focus problems that repeat across pages often point to shared style choices rather than separate content edits.

Custom code

CSS, code blocks and third-party embeds can add or hide barriers after the page is assembled. Test the visitor-facing result.

Controlled social-link fixture

One icon-only link. One missing accessible name.

We ran axe-core 4.11 against a small footer-style social link. With only a decorative icon inside, the fixture returned one serious link-name finding. Giving the link a concise accessible name removed the finding on re-test.

Before · finding

Social link has no name

<a href="/instagram">
  <svg aria-hidden="true">…</svg>
</a>

The rendered link is keyboard-focusable but exposes no purpose to a screen reader. The affected element tells the owner which footer or social block to inspect.

After · re-test clear

Link exposes its destination

<a href="/instagram" aria-label="Follow us on Instagram">
  <svg aria-hidden="true">…</svg>
</a>

Use visible link text when it suits the design. An accessible name is a bounded repair for a genuinely icon-only control, not a reason to add ARIA everywhere.

This is a controlled fixture, not customer data or a compliance claim. Read the axe-core link-name rule explanation and Squarespace's current accessibility resources and product position.

Scan representative page types

Test a homepage, service or product page, form and any important booking or buying journey. One URL cannot represent every block combination.

Use repetition to locate the source

One-page findings often sit in content. Repeated findings point towards a shared block, navigation, footer, style rule or embed.

Re-test after publishing

Preview the change, publish it safely, then scan the same live URL again. An editor save is not proof that the visitor-facing barrier has gone.

From finding to Squarespace fix path

Let where the issue repeats guide where you look.

01
Only one page
Start with that page's editable blocks and media fields. Check image descriptions, headings, links and form settings.
02
Every use of one block
Compare the rendered block across pages. Its configuration, injected markup or shared styling is the likelier source.
03
Across the whole site
Inspect navigation, footer content and site-wide styles before patching individual pages. Re-test representative templates.
04
Only after an embed loads
Isolate the third-party or custom-code output, confirm the affected element, then repair, configure or replace that component.

What a Squarespace scan cannot prove

Automated testing cannot decide whether image descriptions are useful, whether a page reads coherently, or whether a complete task works with a keyboard and assistive technology. A clean page result is not a site-wide legal compliance determination.

Use the scan as a repeatable diagnostic. Repair machine-detectable barriers in content, blocks, styles and custom code, then add manual keyboard, screen-reader and task-based review for important journeys.

This boundary follows W3C WAI guidance on accessibility evaluation tools. Read the broader website accessibility scanner workflow or compare the WordPress source-fix path.

Start with a Squarespace page that matters.

Scan it free, trace repeated issues to their shared source, and verify the rendered result.

Run the Squarespace accessibility check