Accessibility Is a System Constraint, Not a Final Step
Accessibility rarely fails because teams don’t care.
It fails because it’s treated as a visual adjustment instead of a system decision.
I recently worked on a Squarespace accessibility audit that reinforced this clearly. The issues weren’t dramatic. They weren’t malicious. They were the natural result of customizing without considering how assistive technologies interpret structure.
When accessibility is layered on at the end, even small aesthetic decisions can quietly break usable systems.
Here’s what we found.
Where Things Started to Break
Squarespace provides relatively accessible defaults. But once customization overrides semantic structure, those benefits disappear.
1. Form styling overrides
Custom form styles unintentionally removed native label associations and disrupted keyboard navigation.
The forms looked polished — but screen readers lost context. Keyboard users lost flow.
When we override native behavior, we assume responsibility for rebuilding it correctly.
2. Duplicate navigation landmarks
On mobile, multiple menu folders shared the same aria-label.
For screen reader users, each folder sounded identical. There was no orientation, no hierarchy.
Navigation is a structural contract. If landmarks aren’t distinct, the experience collapses into ambiguity.
3. Mobile contrast issues
A “Read More” CTA looked excellent on desktop.
On mobile, the same text became nearly invisible against a darker background.
Accessibility includes responsiveness.
A system that works on one breakpoint but fails on another isn’t accessible.
What We Changed
The fixes were not complex. They were structural.
Restored form accessibility by removing problematic overrides and preserving semantic associations.
Added unique aria-labels to mobile navigation folders.
Adjusted CTA contrast across breakpoints.
Included an Accessibility Statement outlining current standards and future improvements.
None of these changes required a redesign.
They required intention.
What This Reinforced
Accessibility isn’t a checklist. It’s a constraint that should inform the system from the beginning.
That means:
Start with semantics.
Native elements exist for a reason. They carry meaning.
Treat customization as engineering.
If you override defaults, you inherit responsibility for rebuilding behavior correctly.
Test continuously.
Keyboard-only navigation. Contrast checks. Screen reader passes. Small checks prevent systemic failure.
Accessibility doesn’t need to be dramatic.
It needs to be embedded.
Final Thought
The client cared deeply about their users. Once we identified the issues, improvements were immediate.
Most accessibility gaps are not philosophical resistance. They’re process gaps.
When accessibility is integrated into the first wireframe, the first style choice, the first component decision, it becomes far less expensive — and far more effective.
Design systems either include everyone, or they exclude by default.
The choice is structural.