Squarespace gives you a polished site fast, and a lot of accessibility comes for free in the process. The templates produce clean, semantic HTML, the navigation is keyboard-reachable, and headings start out in a sensible order. But Squarespace accessibility is not automatic: the moment you pick brand colours, drop in images, restructure sections or paste in a third-party widget, you can quietly break the same standards the template handed you.
This guide is specific to what you actually control in the Squarespace editor. We'll cover where templates help and where they hurt, then walk through the four issues that show up on almost every Squarespace site — alt text, heading order, colour contrast and link text — and what they mean for European Accessibility Act (EAA) readiness. When you're ready to see your own site's issues, run a free scan at the AccessScan scanner.
Where Squarespace templates help
On Squarespace 7.1, the underlying markup is genuinely decent. Section headings render as real heading elements rather than styled text, navigation is built as a proper list that you can tab through, and the mobile menu can be opened and closed with a keyboard. Skip-to-content behaviour and visible focus states exist on most current templates, which quietly satisfies several WCAG 2.2 criteria under the Operable principle before you touch anything.
Forms built with the native Form block also tend to associate visible labels with their fields, which is the single most common thing custom-coded sites get wrong. The catch: a template that's accessible out of the box only protects the parts you don't override.
Where Squarespace templates hurt
The trouble starts with the choices the editor invites you to make. These are the recurring offenders:
- Brand colours that fail contrast. Squarespace colour themes let you set light-grey text on white or pale buttons that look elegant and fail WCAG outright.
- Image-only buttons and banners. Text baked into a background image or a banner graphic is invisible to screen readers and disappears if images don't load.
- Reordered sections breaking heading flow. Drag a section above another and you can end up with an H3 before an H2, or two H1s on one page.
- Auto-playing background video and slideshows. Motion that can't be paused trips up the Operable principle and bothers users with vestibular conditions.
- Third-party embeds and Code blocks. Booking widgets, chat bubbles and embedded forms are outside Squarespace's control and are frequently the least accessible thing on the page.
None of these are platform bugs. They're configuration choices — which is good news, because you can fix nearly all of them from the editor.
Alt text: the fix everyone skips
By default Squarespace uses the image filename as alt text. Upload IMG_4821.jpg and a screen reader announces 'I M G 4 8 2 1' — useless. Before you even upload, rename files to something meaningful, then override the alt text per image where the editor allows it (image blocks expose a description/caption field; gallery and background images vary by section type).
Write what the image communicates in context, not what it literally contains. A photo on a bakery's about page is 'Baker shaping sourdough loaves at a floured workbench', not 'image1'. Purely decorative images — textures, dividers, abstract shapes — should have empty alt text so assistive tech skips them entirely. If an image carries information or is a link, it must have descriptive alt text. For the full decision tree, see our guide on how to write alt text.
Headings and contrast: two checks worth doing today
Heading order
Each page should have exactly one H1 (usually the page title or main banner heading), then H2s for major sections, then H3s nested under them — no skipped levels and no jumping back up. In Squarespace this breaks most often when you set heading styles by how they look ('this should be big') rather than by structure. Use the text block's Heading 1/2/3 options to reflect the real hierarchy, and restyle with the site's font settings instead of bumping a subsection up to H1 to make it larger.
Colour contrast
WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt, or 14pt bold) and for UI components and meaningful graphics (criteria 1.4.3 and 1.4.11). Check your Squarespace colour themes against this — pale link text, ghost buttons, and grey placeholder labels are the usual failures. Also check hover and focus states, not just the resting colour. Our colour contrast requirements guide explains how to test combinations.
Link text and embeds
Screen reader users often navigate by pulling up a list of every link on a page. A page full of 'Read more', 'Click here' and 'Learn more' is meaningless out of context. Make link text describe its destination — 'Read our refund policy' rather than 'Read more'. This is a pure editor change with no downside for sighted users either.
Embeds deserve special scrutiny. A booking tool, newsletter pop-up or chat widget pasted via a Code block runs its own markup that Squarespace doesn't audit. Before you trust it, tab through it with your keyboard: can you reach every control, see where focus is, and close any pop-up without a mouse? Keyboard operability is a hard requirement under EN 301 549, and embeds are where it most often fails.
EAA readiness for Squarespace owners
The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025. If you sell goods or services to consumers in the EU, it likely covers your site, and the standard is WCAG 2.2 Level A and AA referenced through the European standard EN 301 549. Microenterprises that provide services (fewer than 10 staff and under €2,000,000 annual turnover) are largely exempt for those services — but a small online shop selling physical products can still be in scope, so don't assume size alone gets you off the hook. Penalties vary by member state and can reach tens of thousands of euros. Our European Accessibility Act guide helps you check where you stand.
A realistic path for a Squarespace owner: fix contrast in your colour themes, audit every image's alt text, correct heading order page by page, rewrite vague link text, keyboard-test your embeds, and publish an accessibility statement. The first five are editor-level work you can do this week. To find which pages and elements need attention first, run a free automated scan at the AccessScan scanner, then work through the results and generate your accessibility statement when you're ready.