Squarespace is a popular website builder known for its visually stunning templates and drag-and-drop editing experience. However, this emphasis on visual design has historically come at the cost of accessibility. Unlike WordPress where you have full control over the HTML output, Squarespace generates its markup automatically, which means you are working within the constraints of what the platform produces. The good news is that Squarespace has made meaningful improvements to accessibility in recent versions, including better semantic HTML output, improved keyboard navigation, and built-in alt text support for images. The challenge is that many of these features require conscious effort from the site owner to use correctly, and some accessibility gaps remain that require workarounds. With EAA enforcement now active across Europe, Squarespace site owners serving EU customers must take accessibility seriously. This checklist identifies the most common accessibility issues found on Squarespace sites and provides practical fixes that work within the platform's constraints. For each issue, we specify the WCAG success criterion, the severity level, and detailed remediation steps using Squarespace's editor and settings panels. Where the platform has limitations that cannot be fully addressed through the editor, we provide custom code injection solutions that can be added via Squarespace's Code Injection feature or custom CSS panel.

Common Accessibility Issues

critical

Images Without Alt Text or With Filename Alt Text

WCAG 1.1.1

Squarespace allows adding alt text to images through the image editor, but many site owners either do not know the feature exists or skip it during content creation. By default, images added without alt text receive no alt attribute or an auto-generated one based on the filename. Gallery blocks, background images, and banner images are particularly prone to missing alt text because the alt text field is less prominent in the editing interface for these elements.

How to fix:

For standard image blocks, click on the image in the editor, then click the pencil icon or 'Edit' to open image settings, and fill in the 'Image Alt Text' field under the Design tab. For gallery blocks, click on each individual image within the gallery to add alt text. For banner and background images that are purely decorative, Squarespace typically handles these appropriately, but verify with a screen reader. For images added via the summary block or blog post thumbnails, edit the alt text through the media manager.

Before
<!-- Squarespace output without alt text configured -->
<img src="https://images.squarespace-cdn.com/content/v1/.../photo.jpg" 
     alt="photo-1" loading="lazy">

<!-- Gallery image with no alt -->
<img src="https://images.squarespace-cdn.com/content/v1/.../gallery-3.jpg" 
     loading="lazy">
After
<!-- After adding alt text in the Squarespace editor -->
<img src="https://images.squarespace-cdn.com/content/v1/.../photo.jpg" 
     alt="Downtown Seattle skyline at sunset with Mount Rainier visible in the background" 
     loading="lazy">

<!-- Decorative image properly marked -->
<img src="https://images.squarespace-cdn.com/content/v1/.../divider.jpg" 
     alt="" role="presentation" loading="lazy">
critical

Missing Heading Hierarchy Due to Visual-First Editing

WCAG 1.3.1

Squarespace's editor encourages visual-first content creation, leading many users to select heading levels based on appearance rather than semantic structure. The platform's text block offers Heading 1 through Heading 4 options, but there is no built-in validation of heading hierarchy. Sites frequently have multiple H1 elements per page, skip heading levels, or use headings purely for visual styling of non-heading content.

How to fix:

Audit your heading structure on every page using a browser extension like HeadingsMap. Ensure each page has exactly one H1 (in Squarespace, the page title is typically the H1, so do not add another H1 in the content area). Use H2 for main content sections and H3 for subsections. If the visual size of a heading level does not match your design needs, use Squarespace's custom CSS panel (Design > Custom CSS) to restyle the heading rather than choosing the wrong level.

serious

Squarespace Form Blocks With Poor Label Associations

WCAG 1.3.1

Squarespace form blocks sometimes rely on placeholder text as the only indication of what information a field requires. While recent versions have improved label visibility, some templates still render form labels that are visually hidden in a way that certain screen readers may not consistently announce. Custom forms built with code injection often lack proper label associations entirely.

How to fix:

In the Squarespace form block settings, ensure the 'Show Field Labels' option is enabled rather than relying on placeholder text alone. For each field, provide a clear, descriptive label. If you need custom forms via code injection, always use explicit <label for="id"> associations. Add aria-required="true" to required fields and use aria-describedby for supplementary help text.

Before
<!-- Code injection custom form with missing labels -->
<form>
  <input type="text" placeholder="Your name">
  <input type="email" placeholder="Email address">
  <textarea placeholder="Tell us about your project"></textarea>
  <button>Send</button>
</form>
After
<!-- Accessible custom form via code injection -->
<form>
  <div>
    <label for="contact-name">Full Name <span aria-hidden="true">*</span></label>
    <input type="text" id="contact-name" name="name" required aria-required="true">
  </div>
  <div>
    <label for="contact-email">Email Address <span aria-hidden="true">*</span></label>
    <input type="email" id="contact-email" name="email" required aria-required="true">
  </div>
  <div>
    <label for="contact-message">Project Details</label>
    <textarea id="contact-message" name="message" aria-describedby="message-hint"></textarea>
    <p id="message-hint" class="hint">Describe your project goals, timeline, and budget.</p>
  </div>
  <button type="submit">Send Message</button>
</form>
serious

Video Backgrounds and Auto-Playing Media

WCAG 1.2.1

Squarespace templates prominently feature video background sections and auto-playing ambient video. These elements lack captions, transcripts, or audio descriptions. For users who are deaf or hard of hearing, any information conveyed through audio is lost. For screen reader users, the video may not be announced at all or may be announced without any description of its content. Auto-playing video with motion can also trigger vestibular disorders.

How to fix:

For essential video content, use Squarespace's Video Block instead of background video, and add captions through the video hosting service (YouTube or Vimeo). Provide a text transcript below the video using a text block. For background/ambient video that is purely decorative, ensure it has no audio track or is muted, and add a visible pause button. Use Squarespace's Code Injection to add a prefers-reduced-motion media query that disables auto-playing video for users who have enabled that OS setting.

serious

Accordion and Toggle Blocks Not Fully Accessible

WCAG 4.1.2

Squarespace's accordion block may not consistently expose the expanded/collapsed state to all assistive technologies. Some older templates generate accordion markup that does not use proper ARIA attributes, making it impossible for screen reader users to determine whether a section is open or closed, or to understand the relationship between the toggle trigger and its associated content.

How to fix:

Test your accordion blocks with a screen reader (VoiceOver on Mac, NVDA on Windows). If the expanded/collapsed state is not announced, use Code Injection to add JavaScript that sets aria-expanded on the trigger buttons and aria-hidden on the content panels. Ensure accordion triggers are buttons (or have role="button" and tabindex="0") and respond to both Enter and Space key presses. If Squarespace's built-in accordion is not accessible enough, consider replacing it with a custom accessible accordion via Code Injection.

serious

Mobile Navigation Menu Accessibility Issues

WCAG 2.1.1

Squarespace's mobile hamburger menu and off-canvas navigation panels can have focus management problems. When the mobile menu is opened, focus may not move into the menu. When it is closed, focus may not return to the hamburger button. The menu may not be closeable with the Escape key, and focus may leak behind the overlay to elements that are visually hidden.

How to fix:

Test the mobile navigation thoroughly with keyboard and screen reader. Use Squarespace's Code Injection to enhance the mobile menu behavior: add an Escape key listener to close the menu, ensure focus is trapped within the menu when open, move focus to the first menu item when opened, and return focus to the hamburger button when closed. If the template's mobile menu is severely inaccessible, consider using a custom accessible menu implementation via Code Injection.

moderate

Low Contrast Text in Template Typography

WCAG 1.4.3

Several popular Squarespace templates default to light gray body text, thin font weights, or semi-transparent text that fails WCAG contrast requirements. The platform's Site Styles panel allows color customization, but the default values in many templates do not meet the 4.5:1 minimum contrast ratio for normal text.

How to fix:

Go to Design > Site Styles and adjust your text colors. Use a contrast checker to verify that all text/background combinations meet WCAG requirements: 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Pay special attention to body text, meta information (dates, categories), footer text, and form placeholder text. If the Site Styles panel does not provide enough control, override specific elements via Design > Custom CSS.

Squarespace-Specific Tips

  • Use Squarespace's built-in accessibility features: the Image Alt Text field (available in all image editing interfaces), the Form Block's 'Show Field Labels' option, and the SEO panel's page title and description fields which help define the document structure for assistive technologies.
  • Add accessibility enhancements via the Code Injection panel (Settings > Advanced > Code Injection). This is the primary way to add skip links, enhance ARIA attributes, improve focus management, and implement prefers-reduced-motion media queries on Squarespace sites that do not support direct template editing.
  • Use Squarespace's Custom CSS panel (Design > Custom CSS) to fix contrast issues, add visible focus indicators, improve text readability, and ensure interactive elements have adequate touch target sizes for mobile users. CSS-based fixes are the safest customization method as they survive template updates.
  • When choosing a Squarespace template, test the demo site with keyboard navigation and a screen reader before committing. Templates in the Brine, Bedford, and Tremont families have generally better accessibility foundations than some of the more visually complex templates.
  • For video content, always upload videos to YouTube or Vimeo first (not direct to Squarespace) and add captions through those platforms. Then embed the captioned video using Squarespace's Video Block. This ensures captions are available and controlled by the user.

Recommended Tools

WAVE Web Accessibility Evaluation Tool

A free browser extension and online tool by WebAIM that evaluates web page accessibility by visually overlaying icons and indicators on the page, making it easy to identify and locate accessibility issues on Squarespace sites.

axe DevTools

A comprehensive browser extension for automated accessibility testing that identifies WCAG violations with detailed guidance. Particularly useful for Squarespace since you cannot run server-side testing tools on the platform.

HeadingsMap

A browser extension that displays the heading structure of any web page in a sidebar, making it easy to verify that your Squarespace content has a proper heading hierarchy without skipped levels.

Further Reading

Other CMS Checklists