Squarespace Accessibility After the European Accessibility Act

The European Accessibility Act has applied since 28 June 2025. If you sell to consumers in the EU online, there's a decent chance it applies to you, and the standard it points to is the same one US courts have been using in ADA cases for a decade: WCAG 2.1 AA.

Squarespace gives you a reasonable starting point and leaves you with a list. This is the list.

Who the EAA actually covers

The Act covers products and services sold to consumers in the EU, and "e-commerce services" is one of the named categories. That means an online shop, a booking system with payment, and arguably any site where a consumer concludes a contract online. It does not cover a brochure site with a contact form, though the line is blurry when the form starts a purchase.

Microenterprises providing services are exempt: fewer than ten staff and under EUR 2 million in turnover or balance sheet. Most of our clients are under that threshold. Many of their customers aren't, and larger companies increasingly ask their suppliers about accessibility.

Switzerland is not in the EU. The EAA doesn't apply to a Swiss business as Swiss law, but it applies to services offered to EU consumers, so a Swiss shop shipping to Germany is in scope the same way it's in scope for GDPR. Swiss domestic law (BehiG) obliges federal bodies and doesn't currently oblige private companies.

In the US, there's no federal web accessibility statute for private business, but ADA Title III lawsuits over inaccessible websites run in the thousands a year, and WCAG 2.1 AA is the standard courts and settlements reference. The Department of Justice's 2024 rule for state and local government sites also points at 2.1 AA.

So the standard is the same everywhere: WCAG 2.1 AA. Meet it and you've covered the EAA, the ADA and most procurement questionnaires.

What Squarespace 7.1 does for you

Credit where due.

The HTML is semantic. Headings are real headings, navigation is a nav, the main content is a main, buttons are buttons. There's a skip-to-content link. Forms have associated labels when you fill in the label fields. Images have an alt text field. Colour and contrast are entirely under your control. Text scales with browser zoom. The mobile menu is keyboard-operable. Video blocks support captions if you upload them.

That puts a stock site somewhere around "mostly passes an automated check". Which is not the same as compliant, because automated checks catch about a third of WCAG criteria.

What a stock site gets wrong

These are the things we find on nearly every Squarespace site we audit, in rough order of frequency.

Contrast. Light grey text on white, white text on a photo, the brand's pale accent colour used for links. WCAG needs 4.5:1 for normal text and 3:1 for large text and UI components. Designers break this constantly because low contrast looks refined. Fix: check every text colour against every background with a contrast tool, and add a semi-transparent overlay behind text on images.

Missing alt text. The field exists; nobody fills it. Decorative images should have empty alt (Squarespace leaves it empty by default, which is right for decorative and wrong for everything else). Informative images need a description of what they show. Logos need the company name.

Heading order. Fluid Engine lets you put an H4 above an H2 because it looked right. Screen reader users navigate by heading level, and a page that goes H1, H4, H2, H3 is a maze. Fix: one H1 per page, then descend in order, and use paragraph styles rather than heading styles when you just want bigger text.

Focus visibility. Squarespace has focus styles, and many custom CSS files remove them with outline: none because the designer didn't like the blue ring. Keyboard users then can't see where they are. Fix: never remove outlines; restyle them to match the brand.

Fluid Engine tab order. On Fluid Engine pages, the visual order of blocks and the DOM order can diverge, especially after moving things around on mobile. A keyboard user tabs through in DOM order, which may jump around the page. Fix: check tab order on every page and re-add blocks in reading order if it's wrong. This one is tedious.

Link text. "Click here", "Read more", "Learn more" five times on a page. A screen reader listing links reads "Learn more, Learn more, Learn more". Fix: link text that says where it goes.

Autoplay and motion. Background videos, animated hero text, Squarespace's site-wide fade animations. WCAG wants a way to pause moving content and respects the user's reduced-motion setting. Fix: no autoplay video without a pause control, and a CSS rule that turns off animations under prefers-reduced-motion. (Turning off the fade animations also fixes your Core Web Vitals; we've written about that.)

Forms. Placeholder text used as the only label. Required fields marked only by colour. Error messages that don't say which field. Fix: use the label field, mark required fields in the label text, and test with keyboard only.

Colour as the only signal. Red text for an error, green for success, and nothing else. Fix: add an icon or a word.

Third-party embeds. Booking widgets, chat, maps, Instagram feeds. Each is its own accessibility problem and Squarespace can't fix them. Fix: choose vendors who publish an accessibility statement, and give the embed a title.

PDFs. Menus, price lists, brochures as PDFs. Nearly all inaccessible. Fix: put the content on the page as HTML, and if the PDF must exist, tag it properly.

What accessibility overlays do and don't do

Overlay widgets that promise compliance with one line of code do not deliver it. They add a toolbar for contrast and font size, which is useful, and they attempt to patch the page with automated fixes, which is unreliable. Several of the biggest overlay vendors have been named in ADA lawsuits alongside the sites that used them, and the accessibility community has published an open letter against them.

We built our own lightweight widget for clients who want the toolbar features: text size, contrast, reduced motion, dyslexia-friendly spacing. It's useful for visitors and makes no compliance claims, because it can't. The compliance work is the list above.

Our process on a build or an audit

  1. Automated scan of every page with axe and Lighthouse. Catches contrast, missing alt, missing labels, ARIA misuse. Half a day for a 20-page site.

  2. Manual keyboard pass: tab through every page, operate every menu, form and modal without a mouse. Check focus is visible and the order makes sense.

  3. Screen reader pass on the top ten pages with VoiceOver or NVDA. Listen to the heading list and the link list; that's where most problems show up.

  4. Fixes in Custom CSS and in content. Contrast changes get signed off with the client because they change the look.

  5. Reduced-motion rule, focus styles, and a lang attribute check (a German site with lang="en" reads German in an English voice).

  6. An accessibility statement page: what standard you aim for, known issues, how to report a problem. The EAA requires it for services in scope; it's good practice anyway.

  7. Re-scan, and a note in the support plan to re-check quarterly, because content editors will add grey text and empty alt fields the week after you leave.

On a site we didn't build, an audit with fixes is usually 8 to 20 hours depending on page count and how far the custom CSS has drifted. On a site we do build, it's included, because it's cheaper to design with contrast than to fix it after.

The short version

Squarespace doesn't make your site accessible and doesn't stop you making it accessible. The platform gets you halfway. The other half is contrast, alt text, heading order, focus, motion and forms, plus checking that the embeds and PDFs you added didn't undo the work.

Questions we get

Is there a Squarespace accessibility certificate or statement I can use? Squarespace publishes its own accessibility information about the platform. It covers the platform, not your site. Your accessibility statement is about what you built.

Can I use a template marked "accessible"? All 7.1 sites use the same underlying template; the differences are styling. There's no accessible or inaccessible template, only accessible or inaccessible choices in colour, structure and content.

What does an audit cost if I do it myself? Free tools cover the automated third: the axe browser extension, Lighthouse in Chrome, WAVE. The manual part is your time: an hour with a keyboard and an hour with VoiceOver on a Mac or NVDA on Windows for a small site.

Are PDFs really a problem? Yes, and a common one. A restaurant menu as an untagged PDF is unreadable to a screen reader. Put the menu on the page as text; keep the PDF for printing if you like.

Does WCAG 2.2 change anything? 2.2 adds a few criteria, mostly around focus visibility, target size and dragging. The EAA references EN 301 549, which currently maps to 2.1 AA. Meeting 2.2 is a small step further and future-proofs you.

We're a US business with no EU customers. Does any of this apply? The EAA doesn't. ADA litigation does, and WCAG 2.1 AA is the standard in nearly every settlement. The work is identical.

Previous
Previous

Squarespace Website Maintenance: The Monthly Checklist an Agency Actually Runs

Next
Next

Connecting Squarespace to a CRM: HubSpot, Zapier, Make, and When to Write Code