The platform looked premium. The accessible experience did not.
Swadesh is a luxury e-commerce platform by NMACC that brings Indian artisanal craft to a global audience. I worked on the UX, content and end-to-end experience design, and led the accessibility work as it prepared for US expansion.
- Role
- UX, content & experience design
- Scope
- WCAG 2.2 AA readiness
- Focus
- Design tokens + semantics
- Platform
- Web · luxury e-commerce
- Problem
- Preparing for US expansion under ADA, Swadesh had 24 colour-contrast errors, the worst of seven luxury platforms benchmarked, and a VoiceOver experience where the main Buy Now was announced as “image”.
- My move
- Ran a VoiceOver + keyboard audit and a WCAG 2.2 AA technical audit in parallel, traced 24 symptoms to two root causes (tokens and semantics), and fixed at the source: 8 corrected brand tokens and a documented accessibility annotation layer.
- Outcome
- Priority flows moved to WCAG 2.2 AA readiness: 24 → 0 contrast errors, a 9.9 PDP accessibility score, with the brand's soft palette kept intact.
- Learning
- Audit accessibility before the visual tokens are finalised. Accessibility work exposes system assumptions; catching them early prevents rework.
If the journey feels degraded for one user group, the brand promise stops being true.
Why accessibility was the brand promise, not a legal layer
A system-level gap, not a page-level bug
US expansion made accessibility a hard requirement, but the real stake was the brand promise itself.
When Swadesh started preparing for US expansion, accessibility became a hard requirement under ADA. But this was bigger than compliance. If a premium experience breaks for a visually impaired user, the brand breaks its own promise.
The first audit found 24 colour-contrast errors across Swadesh, the highest count in the luxury set we benchmarked. This was not a page-level bug, it was a system-level gap.
Two audits, run in parallel
- 01The main “Buy Now” action was announced as “image”, not “button”.
- 02Required form fields gave no accessible required-state signal before submission.
- 03Add-to-cart feedback was silent for screen-reader users.
- 0426 homepage elements had weak focus order or missing labels.
- 05Modal overlays had no focus trap, so users could move behind the open layer.
Two root causes, not twenty-four symptoms
The 24 errors traced back to two root causes: a token problem in the palette and a semantic problem in the HTML.
- The palette was built for a soft luxury look, not accessible contrast
- Fixing components one by one only patches the symptom
- Correct the tokens and every downstream component inherits the fix
- The visual layer looked right, the HTML semantics were wrong
- Buttons weren't buttons; live regions were missing
- Focus followed layout, not user intent, so it needs a flow-by-flow pass
Token correction vs local override
A local override would fix today's screen and keep the source broken; correcting the tokens fixes every future screen automatically.
The fastest option was to override failing colours at the component level and move on. But Swadesh runs on shared tokens: a local fix would solve today's screen and keep the source broken for every future one. So we pushed for a token-level fix, working with the brand team because the palette was part of Swadesh's identity. We kept backgrounds soft, corrected only the text tokens and found the minimum values that passed WCAG AA without losing the brand's warmth.
- Local component overrides
- Faster delivery
- Broken source tokens stay in the system
- Token-level correction
- Needs brand sign-off
- Every future component inherits the fix automatically
Fixing the source, then the flows
Fix the tokens and the semantics at source first, then rebuild focus and reading order around user intent, flow by flow.
Fix colour tokens at source, not in components
I corrected 8 text-related brand colour tokens that were failing WCAG AA. Updating the token library meant every component using those tokens improved without creating override drift.
Fix button semantics before polishing journeys
The main CTA pattern was visually correct but semantically wrong: VoiceOver read it as “image”. I documented the semantic fix with explicit role and label guidance so the pattern could be corrected at source, not screen by screen.
Add accessible required states, and live regions for feedback
Login, checkout and enquiry forms didn't expose required fields to screen readers, so I added aria-required guidance communicated through text, not just visual convention. Add-to-cart announced nothing, so I specified an aria-live="polite" pattern so users hear confirmation without interrupting the current narration.
Trap focus in modals, and rebuild reading order around intent
Image viewers and filter drawers let users wander the page behind them, so every modal got focus-trap rules. I rewrote the homepage reading order around what users need first: logo, navigation, search, featured content, then product discovery.
An annotation layer the team could build from
From non-compliant baseline to AA-ready
Priority flows reached WCAG 2.2 AA readiness with the brand's soft palette intact.
The priority flows moved from a non-compliant baseline to WCAG 2.2 AA readiness across PDP, cart, login and navigation. Swadesh now has a stronger accessibility foundation for US expansion, and a better quality bar across the product.
What I'd do earlier next time
Audit accessibility before the visual tokens are finalised: the work exposes system assumptions.
Swadesh's design system wasn't careless: it was built without an accessibility lens early enough. Once the patterns were named, the fixes were straightforward. The harder part was finding the right level to solve them.
With more runway, I'd audit accessibility before the visual tokens were finalised. Catching those issues early would have prevented a lot of rework later.