If you built your business site on Squarespace and ran a Lighthouse accessibility audit on it, the score that came back is genuinely impressive. Squarespace ships a lot of the basics correctly — landmark roles, decent default contrast on most templates, semantic headings on the simple blocks. The team has clearly thought about it.
The problem is that the audit your customer with a screen reader actually runs is not the same audit Lighthouse ran. Lighthouse is testing a static snapshot. The customer is tabbing through your site, opening the mobile menu, hovering on the gallery, submitting your contact form, and listening to what the screen reader announces along the way. About half of what WCAG 2.1 AA actually requires happens during those interactions, and that half is where Squarespace's block library has five very specific defaults that quietly break things.
We have audited a meaningful number of Squarespace sites in the last few months. The five issues below show up on roughly every site, including the ones whose owners had already done a careful pass with the built-in tooling. None of them require leaving Squarespace. Four of them are settings buried in block panels that nobody told you to check.
Why these patterns are so common on Squarespace
Squarespace is a block library. You drop a Heading block onto a section, then an Image block, then a Form block, and the site builds itself out of those primitives. Each block has its own settings panel, and the defaults in those panels were chosen by the Squarespace team to make a non-developer's first site look professional out of the box. They were not chosen to pass a manual screen reader pass.
This is not a knock on Squarespace. The defaults are reasonable for visual presentation. They are also five specific traps for accessibility that are easy to introduce without knowing.
The five things that almost always fail
1. Heading hierarchy that the section structure quietly broke
Squarespace 7.1 lets you stack sections vertically and put any block inside any section. The Heading block lets you pick H1 through H6. The Section block has its own "section title" treatment that is usually H2 by visual default but can be overridden. The Cover Page block, when used, ships an H1.
What we keep finding: a homepage with two H1 elements. One from the Cover Page section's title, one from a Heading block somewhere in the body that was set to H1 because the editor wanted big text. A screen reader user who navigates by heading lands on the page and hears two top-level "heading 1" announcements with no clear signal about which is the actual page title.
The fix lives in the block panel for each Heading block. Open every Heading block on the page, set the level explicitly (H1 once, H2 for top-level sections, H3 inside those, and so on), and verify the visual order matches the level order. The Site Style settings let you control the font size for each heading level globally, which means you can have a small H1 visually if the design calls for it without breaking the hierarchy.
2. Image blocks with empty alt text on photos that needed real alt text
Squarespace's Image block has a "Filename" field that doubles as alt text by default. When you drag an image in, the alt text is whatever the file was called — IMG_4823.JPG, final-final-revised.png, hero-section-cropped-v3.jpg. The Image block has a separate "Image Alt Text" field that is empty until you fill it in.
Most Squarespace sites we audit have inherited filenames as alt text on roughly half their images and empty alt on the rest. A screen reader user lands on the homepage and hears "image, IMG_4823 dot J P G" between the two paragraphs of body content, with no idea what was being shown.
The fix is mechanical. Click each Image block, open the panel, fill in the Image Alt Text field with a real description — what the image actually shows, not what the file was named. Decorative images like dividers, textures, and patterns should have empty alt text (the field literally left blank, which Squarespace correctly outputs as alt=""). Photos of you, photos of your work, infographics, charts — all need real descriptions.
There is a Bulk option in the asset library that lets you set alt text for many images at once, but it does not connect to the per-block alt text field. The block-level field overrides the asset-level one if filled, so per-block updates are still needed for anything Squarespace already shipped with the wrong default.
3. Form blocks with placeholders pretending to be labels
Squarespace's Form block has two layout modes for fields: "Floated Label" and "Standard Label." Floated Label is the prettier default — the label sits inside the input until you click into it, then floats up. To a sighted user this works fine. To a screen reader, the floated label is rendered as a placeholder that gets ignored once the input is focused, and the actual programmatic label is empty.
The result is a contact form where every input is announced as "edit text, blank" by VoiceOver. The visitor has no idea what each field wants. Submitting the form requires guessing.
The fix is one toggle. In the Form block settings, switch field-level Layout to "Standard Label" instead of "Floated Label." The label appears above the input visually and is properly associated with it programmatically. Some designers dislike the look. The compromise: keep Standard Label but customize the styling in Custom CSS to push the label tighter against the input.
This applies to every contact form, newsletter signup, and registration form on the site. Set it once on the form, and any new instance you create from a saved template inherits the corrected setting.
4. Mobile menu drawers that don't move focus on open or close
The default Squarespace mobile menu is a hamburger button that opens a full-screen overlay drawer. When a sighted user taps the hamburger, the drawer slides in. When a keyboard user presses Enter on the hamburger, the drawer also slides in — but their focus stays on the hamburger button. Tabbing forward then walks them through the underlying page content (which is now visually hidden behind the drawer overlay), not through the drawer's nav links.
Worse, when the drawer closes, focus often disappears entirely. The user is dropped at <body> and has to start over.
This one is not fixable through the standard editor settings. It requires Custom Code injected via Settings → Advanced → Code Injection. The script needs to listen for the drawer's open and close events, move focus to the first nav link on open, and return focus to the hamburger on close. It is roughly fifteen lines of JavaScript.
There are several free Squarespace Plugin sites that ship pre-tested versions of this fix. Sourcing one and pasting it into Code Injection is faster than writing your own, and the plugins have usually been tested across the major templates.
5. Gallery and slideshow blocks that trap or skip keyboard focus
Squarespace's Gallery block and Slideshow block both have keyboard navigation issues that automated scanners do not flag. The Gallery's Lightbox mode opens a full-screen overlay that traps focus inside the overlay until you click the close button — keyboard users can't escape with the Escape key. The Slideshow's autoplay setting starts cycling slides without a pause control, which also fails WCAG 2.2.2 (Pause, Stop, Hide).
The Lightbox fix requires a Custom Code injection that listens for the Escape key and triggers the close action. The Slideshow fix is simpler: in the block settings, turn off Autoplay, or set it to require a hover/pause control. The hover control is exposed in the Squarespace block settings as "Pause on Hover," which counts as a manual pause control under WCAG.
If you keep autoplay on, the Slideshow needs an aria-live region that announces "slide 2 of 5" when the slide changes. Squarespace does not ship this by default; you would need Custom Code to add it.
Verifying the fixes
For three of the five — heading hierarchy, image alt text, form labels — running Lighthouse or axe-core after the fix will tell you whether the change took. The automated scanners catch these reliably.
For the mobile menu and gallery focus issues, automated scanners cannot test them because they require triggering open and close events. The verification step is a keyboard-only pass: open your site, take your hand off the mouse, tab through the homepage, open the mobile menu (visualize the screen at phone width via DevTools device emulation), tab through the menu, close it, verify focus returns to a sensible element. Repeat for the gallery and slideshow blocks.
Then a screen reader pass on the same flows. NVDA on Windows + Firefox or Chrome. VoiceOver on Mac with Safari. Listen for whether form fields announce their labels, whether drawer state changes are announced, whether slides announce their transition.
Run all of this at desktop width and at mobile width. Squarespace's responsive CSS sometimes hides blocks at smaller breakpoints (the "Hide on Mobile" section toggle), and a fix that passes at one width can regress at another.
What to ask before you hire someone
If you are paying an auditor or a developer to fix accessibility on your Squarespace site, three questions before you sign:
Will the fix include the mobile menu and gallery Custom Code injections, not just the editor settings? The four block-level settings (label layout, alt text, heading levels, slideshow autoplay) are settings any non-developer can change. The mobile menu and gallery focus fixes need actual code. If the proposal does not mention Custom Code injection, the audit will look complete but the keyboard issues will remain.
Will the work cover both desktop and mobile widths? Squarespace's hide-on-mobile and hide-on-desktop toggles cause different DOM at different breakpoints. A fix verified only on desktop misses real issues that only mobile users hit.
Will the auditor identify which of the five patterns above are present? Any auditor or developer who has worked on Squarespace for a real project will recognize these immediately. If they look puzzled, they have not done it before. The score they hand you back will probably be a Lighthouse number, which is half of the audit your customer experiences.
If those three are clear with examples from past Squarespace work, you are talking to someone who has shipped this. If not, the report will read thoroughly and miss the half that lands ADA demand letters.
Closing
Squarespace is a fine platform. The team takes accessibility seriously and ships better defaults than several of its competitors. The five patterns above are not platform criticism; they are recurring traps that the block library makes easy to fall into without knowing. None of them require leaving Squarespace. Four of them are panel settings. One of them is a code injection that takes about an hour to source and paste.
If you have a Squarespace site and have already run Lighthouse on it, the next pass that catches the half Lighthouse does not is a manual keyboard and screen reader walkthrough of the same five blocks. That is the audit your customer is running for you whether you commission it or not.
If you want a free 5-minute manual pass on your highest-traffic page — keyboard tab order, mobile menu focus, form labels, the things automated tools do not test — drop the URL in the comments. We are running these for the first 5 sites that ask, mainly because we are building a public review base and the writeups make good case studies.
Top comments (0)