Free, any Squarespace template

Squarespace Accessibility Checker

Scan a page of your Squarespace site and see which accessibility issues come from your template, your blocks, your galleries, your forms or your custom code, and where in Squarespace to fix each one.

Templates and site styles
Text and heading styles
Image and gallery blocks
Buttons and navigation
Form blocks
Code blocks and injections

Each page is rendered in a real browser and tested with axe-core against the machine-testable WCAG 2.2 Level A and AA success criteria. Automated testing does not replace a manual accessibility review.

The same checker, for Squarespace sites

This page runs the free TagPipes Website Accessibility Checker: one page address, loaded in a real browser, tested with axe-core against the machine-testable WCAG 2.2 Level A and AA success criteria, reported in plain language. What is different here is the explanation around it, written for Squarespace sites.

Where accessibility issues come from on a Squarespace site

A Squarespace page is a template, its site styles, and the blocks placed in each section. The scan sees the published page; knowing the layers tells you what to change.

1. The template and site styles

Header, navigation, footer, fonts and the color palette are set once and apply everywhere. A palette with light gray body text or low-contrast buttons, and a header with icon-only social and cart links, put the same findings on every page.

2. Text blocks and heading styles

Each text block carries a style: Heading 1 to Heading 4, or Paragraph. Choosing a heading style for its size rather than its place in the outline produces skipped levels and pages with several h1 tags or none.

3. Image, gallery and video blocks

Each image block and each gallery item has an alt text field. Image captions and file names are not alt text. Slideshow galleries and video backgrounds need controls that keyboard users can reach.

4. Code blocks, code injection and extensions

Embedded widgets, custom CSS that hides focus outlines, and third-party scripts injected in settings bring markup the editor never sees. Commerce pages and member areas add their own components too.

What the scan finds on a Squarespace page

The page is loaded in a real browser exactly as a visitor gets it, injected code and all, and tested with axe-core against the machine-testable WCAG 2.2 A and AA criteria.

What this scan finds

Image and gallery items with no alt text
Heading styles used out of order, pages with no h1, and empty headings
Icon-only links and buttons with no accessible name: social, cart, search, menu
Body text, captions and button colors that do not contrast enough with their background
Form block fields without labels, and submit buttons without names
Missing landmarks and content outside them
Slideshows, lightboxes and scrolling galleries that keyboard users cannot reach
Focus outlines removed by custom CSS with nothing in their place

What needs a person

Whether the alt text describes the image well, or should be empty
Whether the mobile menu, lightboxes and galleries work with a keyboard from start to finish
Whether video backgrounds and animations can be paused
Whether a form's error messages explain what to fix
Whether checkout, scheduling and member areas can be completed with a screen reader
Content inside embedded PDFs and third-party widgets

Automated testing does not replace a manual accessibility review.

Where to fix common findings in Squarespace

Most findings are a setting on a block or in site styles, not code.

1. Alt text on images

Edit the image block and fill in the alt text field in its settings. Gallery images have an alt text field per item in the gallery's settings. Describe what the image shows; leave it empty on purpose for decorative images. Captions and file names do not count.

2. Heading styles in order

Edit the text block and pick the style for the outline: one Heading 1 per page, Heading 2 for sections, Heading 3 beneath. Adjust the look of each heading level in site styles so the level and the size no longer fight.

3. Names on icon links

Social links take their name from the social account settings; make sure each has a recognizable service name. Icon-only buttons in custom blocks need visible or visually hidden text. Make link text say where it goes.

4. Colors and contrast

Open site styles and adjust the palette and the section themes until the report's measured ratio meets 4.5:1 for normal text and 3:1 for large text. Check buttons, captions and the footer separately; they often use lighter theme colors.

5. Form blocks

Keep every field's label switched on in the form block settings; placeholder text is not a label. Name the submit button for what it does, and give the confirmation and error messages real text.

6. Custom code

If the report shows focus outlines removed or elements hidden from assistive technology, look at custom CSS and code injection first. Remove or replace the rule, then scan again to confirm.

Which Squarespace pages to check

Check the home page, a page with a form, a page built around a gallery, a blog post, and if you sell online, a product page and the cart. Findings in the header, navigation and footer repeat on every page, so fixing them once fixes them everywhere. Findings in blocks are page by page.

The scan tests the published page as a visitor receives it. A site that is still password protected or set to private will fail to scan; scan the live site or a public page.

Frequently asked questions

TagPipes monitors, configures and reports. It does not determine legal compliance and does not provide legal advice. Output is informational and reflects observed state at the time of observation. Rawsoft's expertise is technology, not law; please confirm any regulatory interpretation with your own counsel.

One checker, the same real-browser scan, explained for the question you came with. Every report opens at the same place.

Check a Squarespace page now.

Free, no signup, usually ready in a couple of minutes.

Check My Squarespace Site