Under the hood
What a Squarespace source code fix actually looks like
“Real fixes, not an overlay” is easy to say, so here is the code. Every example below is a pattern we have applied on a live Squarespace site we maintain.
The through line: almost none of this is visible. Accessibility fixes mostly live in attributes a browser never draws, which is why a site can look identical before and after and still be materially better for someone using a screen reader.
Image alt text
WCAG 1.1.1 Non-text Content
Squarespace fills alt text with the uploaded file name when nobody sets one. A screen reader then reads the file name aloud, which tells the listener nothing.
Before
<img src="/s/DSC_0142.jpg" alt="DSC_0142.jpg">After
<img src="/s/DSC_0142.jpg" alt="Dried flower arrangement in a white ceramic vase">The description now says what the image shows. Nothing about the page looks different to a sighted visitor.
Links with no accessible name
WCAG 4.1.2 Name, Role, Value
A product image wrapped in a link, with no text and no alt, is announced as just “link.” A screen reader user has no way to know where it goes.
Before
<a href="/shop/morning-dew"><img src="/s/morning-dew.jpg" alt=""></a>After
<a href="/shop/morning-dew"><img src="/s/morning-dew.jpg" alt="Morning Dew dried flower arrangement"></a>The link now announces the product name. This is one of the few issues here that is a genuine WCAG Level A failure, not a best practice.
Vague repeated link text
WCAG 2.4.4 Link Purpose, 2.5.3 Label in Name
Four buttons all reading “Shop now” are indistinguishable in a screen reader’s list of links.
Before
<a href="/shop/candles">Shop now</a>After
<a href="/shop/candles" aria-label="Shop now: candles">Shop now</a>Note the label starts with the visible words. If it read only “Shop candles,” a voice-control user saying “click Shop now” would get nothing, which trades one problem for a worse one.
Decorative text marked as a heading
WCAG 1.3.1 Info and Relationships
A scrolling marquee built from heading tags is announced as several page titles, so the heading outline becomes nonsense.
Before
<h1>plants & flowers are natural mood boosters</h1>After
<h1 role="presentation">plants & flowers are natural mood boosters</h1>The role override removes the heading semantics while the tag, and therefore every pixel of the styling, stays exactly as designed.
Page with no top-level heading
WCAG 1.3.1 Info and Relationships
Squarespace store and system pages often start at an h2, so there is no heading that identifies the page itself.
Before
<h2>Menu</h2>After
<h2 aria-level="1">Menu</h2>Assistive technology honours aria-level over the tag, so the outline is corrected without changing the font size the tag controls.
Why this is harder than it looks on Squarespace
Two reasons, both structural. First, heading tags drive font sizes in most Squarespace templates, so retagging a heading for a correct outline can visibly resize it unless the size is pinned back in CSS. Second, store and system pages such as the cart are generated by Squarespace, so there is no block to edit and the fix has to be applied another way.
That is the work we do each month, and it is the reason we scan every page again rather than auditing once: a template change or a new product page can reintroduce any of the issues above.