Accessibility Beyond the Checklist
Every Squarespace designer knows they should add alt text to images. Most know about colour contrast. Some have heard of WCAG. And almost none have actually read the specification, tested their sites with a screen reader, or tried to navigate one of their own builds using only a keyboard.
Accessibility is the most important skill gap in the Squarespace design community. Not because designers don't care, but because the conversation around accessibility has been reduced to a checklist of surface-level tasks that create a false sense of compliance without actually making sites usable for people with disabilities. Add alt text. Check contrast. Done. Except it isn't done, and the gap between “technically compliant" and “genuinely accessible" is where real skill lives.
Why This Matters Now
The European Accessibility Act came into force in June 2025, requiring digital products and services sold in the EU to meet accessibility standards. In the United States, ADA Title III lawsuits against websites continue at a high rate, and the DOJ's Title II rule mandates WCAG 2.1 AA compliance for state and local government sites by April 2026. The UK's Equality Act 2010 already requires reasonable adjustments for disabled users, and the Public Sector Bodies Accessibility Regulations 2018 mandate WCAG 2.1 AA for public sector websites.
These aren't future considerations. They're current legal requirements. If you're building Squarespace sites for clients who sell to EU customers, serve the public sector, or operate in industries with regulatory oversight, accessibility is not optional. And even for clients outside those categories, the ethical case is straightforward: approximately 16% of the world's population lives with some form of disability. Designing a website that excludes 16% of potential visitors is a business decision, and not a good one.
What WCAG Actually Requires
WCAG 2.2 (the current version at time of writing) organises its success criteria around four principles: Perceivable, Operable, Understandable, and Robust. Most designers only engage with the first two, and only partially.
Perceivable means all content must be presentable to users in ways they can perceive. This includes text alternatives for images (alt text), captions for video, sufficient colour contrast, and the ability to resize text without breaking the layout. It also includes things that most Squarespace designers don't consider: providing text alternatives for non-text content that conveys information (icons, infographics, decorative images that happen to contain text), ensuring content doesn't rely solely on colour to convey meaning (a form that marks required fields only with red text fails this criterion), and ensuring content can be presented in different ways without losing information (assistive technologies need to access the same content as visual users).
Operable means all interface components must be usable by all users. The most critical requirement here is keyboard accessibility: every interactive element (links, buttons, form fields, navigation menus, dropdowns, carousels) must be operable using only a keyboard. This is how many users with motor disabilities navigate the web, and it's also how screen reader users interact with content. Beyond keyboard access, operable also requires that users have enough time to read and use content (no auto-advancing carousels without pause controls), that content doesn't cause seizures (no flashing content more than three times per second), and that users can easily navigate and find content.
Understandable means content and interface operation must be understandable. This includes using clear language, providing error messages that explain what went wrong and how to fix it, ensuring form labels are associated with their inputs, and maintaining consistent navigation across pages. It also includes a requirement that designers often overlook: predictable behaviour. If clicking a checkbox triggers a page navigation, that's a predictability failure. Users expect checkboxes to toggle a state, not navigate somewhere.
Robust means content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. In practice, this means using valid, semantic HTML. A button should be a <button> element, not a styled <div> with a click handler. A heading should be an <h2>, not a <p> with large bold text. Semantic HTML is what allows screen readers and other assistive technologies to understand the structure and function of content.
Semantic HTML: Where Squarespace Helps and Hurts
Squarespace generates its own HTML, which means you have limited control over the semantic structure. The good news is that Squarespace generally uses appropriate HTML elements: headings use <h1> through <h6>, paragraphs use <p>, lists use <ul> and <li>, and links use <a>. The platform's navigation uses <nav> elements, and the main content area uses appropriate landmarks.
The bad news is threefold.
First, the heading hierarchy issue. As covered in our SEO article, designers frequently use heading levels for visual sizing rather than semantic structure. An H3 used because it's the right size, followed by an H2 because that section needs to be bigger, creates a semantic structure that's nonsensical to a screen reader user navigating by headings. Screen reader users frequently jump between headings to scan a page (the equivalent of a sighted user skimming visually), and a broken heading hierarchy makes this navigation method unreliable.
Second, Squarespace's Fluid Engine generates a significant amount of wrapper <div> elements that add DOM complexity without semantic meaning. This doesn't necessarily break accessibility, but it can make the experience more verbose for screen reader users who are navigating the DOM tree.
Third, some Squarespace features have accessibility gaps that you can't fix without custom code. The gallery lightbox, for example, may not properly trap keyboard focus (meaning a keyboard user can tab "behind" the lightbox to invisible elements). Accordion blocks may not use proper ARIA attributes to communicate their expanded/collapsed state. These are platform-level issues that Squarespace continues to improve, but awareness of them is necessary for honest client communication about accessibility compliance.
Writing Alt Text That Actually Works
Alt text is the most discussed accessibility feature and simultaneously the most poorly implemented. The standard advice (“describe the image") is insufficient.
Alt text should convey the function of the image, not just its appearance. For an image of a smiling team standing in an office, “Our team of five standing in our Brighton office" is better than “Group of people smiling." But the best alt text depends on context. If the image is on the About page alongside the team's bio, a detailed description matters. If the same image is decorative on the homepage, used purely for visual warmth, it should have empty alt text (alt=""), which tells screen readers to skip it entirely.
Yes, empty alt text is sometimes the correct choice. A decorative image, a background pattern, an icon that's accompanied by text, or a purely aesthetic element should have alt="" so screen readers don't waste the user's time announcing "image" or reading a filename. The distinction between informative images (which need descriptive alt text) and decorative images (which need empty alt text) is one of the most important accessibility judgments a designer makes.
For complex images like charts, graphs, or infographics, alt text alone is insufficient. The alt attribute should provide a brief summary (“Bar chart showing revenue growth from 2020 to 2025"), and the detailed data should be available in the surrounding text or a linked data table. A screen reader user should be able to access the same information as a sighted user, just through a different format.
In Squarespace, alt text is set in the image block's settings or in the image editor. The platform does not distinguish between informative and decorative images, so you'll need to make that judgment yourself. Squarespace's AI can generate alt text automatically, but treat AI-generated alt text as a starting point that needs human review. AI tends to describe visual content literally (“a woman sitting at a desk with a laptop") rather than contextually (“Dr. Sarah Chen in her therapy practice"), and it can't determine whether an image is decorative or informative.
Keyboard Navigation Testing
The single most revealing accessibility test you can perform on any Squarespace site takes five minutes and requires no tools: close your eyes (or turn off your monitor), and try to navigate the site using only your keyboard.
Tab moves focus to the next interactive element. Shift+Tab moves focus backwards. Enter activates links and buttons. Space activates buttons and checkboxes. Arrow keys navigate within menus and radio groups. Escape closes modals and dropdowns.
Things to check: Can you reach every interactive element by tabbing? Is the focus order logical (does it follow the visual layout, or does it jump around unexpectedly)? Can you see where focus is at all times (is there a visible focus indicator, like an outline around the currently focused element)? Can you open and close dropdown menus? Can you operate any sliders, carousels, or accordions? Can you submit forms?
Squarespace's default focus indicators are often minimal (a thin outline that may be invisible against certain backgrounds). Enhancing focus visibility is one of the most impactful accessibility improvements you can make with custom CSS:
/* Visible focus indicator for keyboard navigation */
*:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 2px;
}
The :focus-visible pseudo-class is important here because it applies the outline only when focus is achieved via keyboard, not via mouse click. This means sighted mouse users won't see the outline (which many find visually intrusive), while keyboard users will see a clear, high-contrast indicator of where they are on the page.
Colour and Beyond: Multi-Modal Communication
The WCAG requirement that information not be conveyed by colour alone is frequently misunderstood. It doesn't mean you can't use colour. It means you can't use colour as the only way to communicate something.
A form where required fields are indicated only by a red label fails this criterion. A user with red-green colour blindness may not distinguish the red labels from the non-red ones. The fix is to add a secondary indicator: an asterisk, the word "required," or a different visual treatment (bold text, for example) in addition to the colour.
A chart where data series are distinguished only by colour fails too. A line chart with a red line, a blue line, and a green line is indistinguishable for a user with deuteranopia (the most common form of colour blindness, affecting roughly 6% of men). Adding different line patterns (solid, dashed, dotted), data point shapes, or labels directly on the chart provides the secondary indicator.
In Squarespace design, this principle applies to status indicators (using both colour and an icon to show success or error), navigation states (the active page should be indicated by more than just colour change), and any interactive element where colour communicates state (hover, active, disabled).
Cognitive Accessibility
WCAG 2.2 expanded its attention to cognitive accessibility, and this is the frontier where most designers have the most room to grow. Cognitive accessibility addresses the needs of users with conditions like dyslexia, ADHD, autism, traumatic brain injury, and age-related cognitive decline.
Practical principles include: use clear, concise language (aim for a reading level that doesn't require specialist knowledge); break long content into scannable sections with meaningful headings; provide consistent navigation so users don't need to relearn the interface on every page; avoid time limits on interactions (or provide easy ways to extend them); don't auto-play media; provide clear error messages that explain what went wrong and what to do about it; and maintain predictable interface behaviour (buttons should look like buttons, links should look like links, and neither should behave differently from what users expect).
For Squarespace designers specifically, cognitive accessibility often comes down to content clarity and interface predictability. Avoid ambiguous labels ("Submit" is less clear than "Send Your Enquiry"). Don't use hover-only interactions for essential content (touchscreen users can't hover, and users with motor difficulties may struggle to maintain a hover state). Ensure that animated content can be paused, and that nothing on the page moves in a way that's distracting or disorienting.
Testing With Real Tools
Automated accessibility testing tools (WAVE, axe, Lighthouse's accessibility audit) catch between 30% and 50% of accessibility issues. They're excellent at identifying missing alt text, insufficient contrast, missing form labels, and improper heading structure. They cannot identify whether alt text is actually useful, whether the tab order is logical, whether content is understandable, or whether interactions are usable with a keyboard.
The minimum testing protocol for a Squarespace site should include: an automated scan with WAVE or axe (available as browser extensions), a manual keyboard navigation test of every page, a contrast check of every text-background combination (the automated tools will catch most of these, but not text over images or gradients), and a screen reader test of at least the homepage and one key interior page.
For screen reader testing, VoiceOver is built into every Mac (activate with Cmd+F5), NVDA is free for Windows, and TalkBack is built into Android. You don't need to become a screen reader expert, but spending thirty minutes navigating your own site with a screen reader will teach you more about accessibility than any article, including this one.
Accessibility is not a feature you add at the end of a project. It's a design principle that should inform every decision from site structure to colour palette to content writing. The checklist is a starting point, not a destination. Moving beyond it, into genuine understanding of how different people experience the web, is the mark of a designer whose work doesn't just look good but actually works for everyone.
Related Articles
