Wix and Squarespace Accessibility: What the Platform Handles vs. What You Fix
Short answer: Wix and Squarespace provide the underlying page structure and some accessibility features, but you still control alt text, color contrast, headings, link text, captions and any custom code. Owners remain responsible for the content and design choices they make on the platform.
Website builders like Wix and Squarespace take care of a lot of technical work. They do not take care of everything. Platform features, template design and your own content all affect whether people using screen readers, keyboards or magnification can use your site.
This guide separates the two: what the platform generally provides, and what remains your job. Platform features change over time, so confirm current details in each vendor's official accessibility documentation. This is general information, not legal advice. For legal questions, talk to an attorney.
The shared responsibility model
Think of a site built on a hosted platform in three layers:
- The platform's code: the editor, the published page framework, built-in widgets and menus.
- The template or theme: layout, default fonts, default colors, spacing, and how navigation behaves.
- Your content and settings: text, images, alt text, colors you choose, embedded video, forms, and custom code.
Both vendors work on the first layer. The second layer varies by template. The third layer is entirely yours, and it is where most audit findings come from.
Using a builder does not make a site conformant to WCAG 2.1 AA on its own, and no platform can promise that outcome for your specific pages. Conformance is a property of the finished site, not the tool.
What the platform generally handles
These areas are typically the platform's responsibility, though quality can vary by template and feature:
- Basic page scaffolding: valid document structure, a language attribute, and page title fields (see WCAG 3.1.1 Language of Page and WCAG 2.4.2 Page Titled).
- Responsive layouts that adapt to different screen sizes, which supports reflow and zoom.
- Keyboard support in built-in components such as menus, buttons and some galleries, to varying degrees.
- Fields for accessibility information, such as alt text on images, and settings for headings and page titles.
"Generally" matters here. Built-in components can still have gaps, and third-party apps and embedded widgets are often outside the platform's control. Test the actual pages you publish rather than assuming the builder got it right.
What you must handle
Alt text on images
Both platforms give you a place to write alt text for images. Neither can know what an image means in your context. Automated suggestions, where offered, are a starting point that you should review.
Good alt text describes the purpose of the image, not just its appearance:
- A product photo: the product, color and relevant detail.
- A logo linking home: the company name or "Home", depending on the link's purpose.
- A purely decorative flourish: mark it decorative if the platform offers that option, or leave alt text empty where it allows.
Text inside images is a common problem. If a banner or menu image contains words, those words need to appear in the alt text or, better, as real text. See WCAG 1.1.1 Non-text Content.
Headings and structure
Builders make it easy to pick a heading style because of how it looks. That can lead to headings chosen for size rather than meaning: a bold Heading 1 used as a decorative tagline, or Heading 4 used for body emphasis.
Use headings to reflect outline structure:
- One clear main heading per page.
- Subheadings nested in logical order, without skipping levels for visual effect.
- Body text styled as paragraph text, not as a heading.
Lists, tables and form labels also need to be real structure, not visual imitations. See WCAG 1.3.1 Info and Relationships.
Color and contrast in design settings
Both platforms let you set brand colors, font colors and background colors in design or style panels. The platform will not stop you from choosing low-contrast combinations.
Check these places specifically:
- Body text against its background.
- Text placed over photos or video, especially in hero sections and banners.
- Button text against button color, including hover and focus states.
- Placeholder text and light gray captions.
- Footer and announcement bar text.
WCAG 2.1 AA sets minimum contrast ratios for text and for interface components. A free contrast checker from a reputable source can measure your color pairs. See WCAG 1.4.3 Contrast (Minimum).
Changing a global color in a style panel can affect every page, so recheck a few page types after any brand color change.
Link text and buttons
Links labeled "click here" or "read more" are meaningless when a screen reader lists all links on a page. Write link text that makes sense out of context, or make sure the surrounding context makes the purpose clear. See WCAG 2.4.4 Link Purpose (In Context).
Video, audio and captions
Embedding a video does not add captions. If you host video through the platform or embed from a video service, you need to supply accurate captions for prerecorded video with speech. See WCAG 1.2.2 Captions (Prerecorded). Also avoid autoplaying media with sound.
Forms and labels
Contact forms, newsletter sign-ups and booking forms are frequent problem areas. Check that every field has a visible, programmatically associated label, that required fields are identified in text (not by color alone), and that error messages explain what went wrong. See WCAG 3.3.2 Labels or Instructions.
Third-party form and booking embeds are often the weakest link, because the platform doesn't control their code.
Template choices matter
Templates differ in navigation patterns, default typography, spacing and how they handle focus. Before committing to one:
- Tab through the demo with your keyboard only. Can you reach every menu item, and can you see where focus is? (See WCAG 2.1.1 Keyboard and WCAG 2.4.7 Focus Visible.)
- Zoom the browser to 200% and check that text stays readable and nothing is cut off. (See WCAG 1.4.4 Resize Text.)
- Look for hover-only menus, image-heavy sliders, and text over busy photos, which are common trouble spots.
- Check whether the template provides a way to skip repeated navigation. (See WCAG 2.4.1 Bypass Blocks.)
Simpler templates with plain layouts usually give you fewer problems to fix later. Heavy animation, parallax effects and complex overlays add risk.
Custom code blocks: you own everything inside them
Both platforms allow custom HTML, CSS or JavaScript in code blocks, header injection or embed elements. Whatever you add there is your responsibility, and it can override the platform's own accessible behavior.
Common mistakes in custom code:
- Removing focus outlines with CSS.
- Building clickable elements from non-interactive tags without roles or keyboard handling.
- Injecting third-party widgets that trap focus or lack labels.
For example, this CSS removes the visible keyboard focus indicator for everyone:
a:focus,
button:focus {
outline: none;
}Instead, keep a clear focus style:
a:focus-visible,
button:focus-visible {
outline: 3px solid #1a4fd6;
outline-offset: 2px;
}If you build custom controls, they need proper names, roles and states. See WCAG 4.1.2 Name, Role, Value. Prefer native elements like <button> and <a> over custom ones wherever possible.
Platform tools and overlays
Both platforms offer built-in accessibility features and checkers of some kind, and third-party apps promise one-click fixes. Treat any automated tool as a helper, not a verdict. Automated checkers catch only a portion of possible issues, and many problems, such as whether alt text is meaningful, need human judgment.
Accessibility overlays and widgets deserve particular caution. They do not replace fixing the underlying site, and they have been the subject of legal disputes. See accessibility overlays and lawsuits for background.
Quick reference: who handles what
| Area | Platform | You |
|---|---|---|
| Page structure and language attribute | Generally | Verify |
| Alt text | Provides the field | Write it |
| Heading order | Provides styles | Use them by meaning |
| Color contrast | Provides settings | Choose and test values |
| Captions | No | Provide them |
| Forms and third-party embeds | Partly | Test and label |
| Custom code | No | Everything |
A practical workflow
- Pick a simple template and test it by keyboard before you build.
- Set brand colors that pass contrast checks from the start.
- Write alt text as you upload each image.
- Review headings, link text and form labels on every page type.
- Caption video and avoid autoplay.
- Audit any custom code and third-party embeds.
- Run an automated scan, then manually test key pages with a keyboard and screen reader.
- Keep a dated record of what you tested and fixed. See dated accessibility audit records.
For a fuller list of criteria, use the WCAG 2.1 AA checklist. The W3C's Web Content Accessibility Guidelines are the source standard.
If you have received a demand letter, read the ADA website demand letter guide and speak with an attorney before responding. To get a baseline of your current site, run a free scan.
Frequently asked questions
Does using Wix or Squarespace make my website ADA compliant?
No. A platform can provide a solid technical foundation and useful tools, but compliance depends on your finished site, including your content, colors, media and code. No builder can guarantee legal protection. For legal questions, consult an attorney.
Who is responsible if my template has an accessibility problem?
Generally, the site owner is the one who publishes the site and faces any complaint about it. Whether you have any recourse against a platform or template designer is a legal question that varies, so ask an attorney. In practice, test a template before you commit and report problems to the vendor.
Do I need to write alt text myself, or can the platform do it?
You should review and write it yourself. Automated suggestions, where available, can't know your purpose for an image and are often generic or wrong. Describe what the image conveys in context, and mark purely decorative images as decorative where the platform allows.
Can an accessibility app or overlay fix my Wix or Squarespace site?
Not reliably. Overlays and one-click apps don't fix the underlying content and markup, and some have been challenged in legal disputes. Use them, at most, as a supplement to fixing the actual site problems.
Is custom code a risk for accessibility?
Yes. Custom code can override the platform's accessible behavior, for example by removing focus outlines or adding controls that keyboards and screen readers can't operate. Use native HTML elements, keep visible focus styles, and test everything you add.
Related
- WCAG 2.1 AA checklist for business websites
- Do accessibility overlay widgets prevent ADA lawsuits?
- WCAG 1.1.1 Non-text Content
- WCAG 1.4.3 Contrast (Minimum)
Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.