Skip to main content
AdityaChinchakar
Back to Case Studies
Figma Plugin · 0→1 Product

Aulys:
The AI Accessibility Engine.

Making WCAG 2.2 compliance achievable for every design team — through an automated Figma plugin I designed, built, and shipped solo.

Product Designer · Solo BuilderOct 2024 – Present
View Live Plugin

Beta Performance

30
Active testers in beta
500+
Frames already scanned
<10s
Per 500-layer document
WCAG
2.2 AA full · AAA selective

01 — Problem

The Accessibility Crisis

96.3%of the top 1 million websites fail basic WCAG compliance — WebAIM 2024

Designers want to build inclusively. But for teams working fast in Figma, WCAG compliance sits at the end of the pipeline — expensive, error-prone, and always late.

Human Error at Scale

Checking contrast ratios, touch targets, and focus indicators manually across hundreds of screens leads to inevitable, costly oversights.

No Real-Time Feedback

Designers have zero visibility into compliance issues while designing. Non-compliant handoffs reach engineering teams with no warning.

Reactive, Not Preventive

Accessibility is tested post-deployment. Finding issues after launch is 6× more expensive than catching them at the design stage.

02 — The Insight

The Real Blocker Wasn't Awareness. It Was Friction.

Designers I spoke to already knew WCAG mattered. What they lacked was a tool that surfaced problems inside their existing workflow — not as an afterthought.

“I check contrast in a separate tool, copy values back to Figma, and still miss things — it breaks my flow completely.”

— Recurring sentiment from early user conversations

Key Decision

Plugin-first, not a standalone app

Embedding the scanner in Figma eliminated context switching — the #1 reason designers ignore accessibility tools.

Key Decision

Fix suggestions, not just reports

Surfacing a problem without a fix creates frustration. Aulys provides AI-powered one-click remediation so designers can act immediately.

Key Trade-off

Figma only, not multi-tool

I deliberately scoped to Figma for v1 to achieve depth over breadth — full WCAG 2.2 coverage for one platform beats shallow coverage across many.

03 — How I Built It

From Canvas to Cloud

I started with a focused Figma Plugin solving a single, painful problem: contrast checking inline. Once beta users validated it, a larger architectural vision took shape.

✓ Live in Beta

Phase 1: Figma Plugin

A local scanner embedded directly in the Figma canvas. I implemented the Polychrom algorithm for accurate WCAG AAA contrast, text-spacing validation, and AI-powered one-click fixes — all without leaving the design tool.

  • Interactive visual overlays on the Figma canvas
  • i18n support — RTL and CJK typography
  • Scans 500+ layers in under 10 seconds
  • GPT-4 suggestions for one-click fixes
⚡ In Development

Phase 2: CI/CD SaaS

Beta signal validated a bigger need: teams wanted accessibility checks integrated into their engineering pipeline, not just design. I'm now building a platform using Playwright and axe-core to run scheduled audits and block non-compliant deployments.

  • Headless browser scanning via Playwright
  • CI/CD pipeline blocking for non-compliant builds
  • Executive compliance dashboards and reports
  • Multi-tenant workspace with SSO (roadmap)

03.5 — Plugin Interface

Production UI

Three panels from the live Aulys plugin — the WCAG audit checklist, the color blindness simulator, and the scan history that tracks compliance over time.

Aulys
×
Aulys
WCAG 2.2 AA Compliant
PRO
#
AI Rubric Generator Screen Design
Frame Selected
Preview
What to Check
Color Contrast
Text Spacing
Line Height
Paragraph Spacing
Non-text Contrast
Alt TextNEW
Heading HierarchyNEW
Link PurposeNEW
Touch Target Size
Scan
Live Production UI

9 configurable checks including 3 new WCAG 2.2 criteria (Alt Text, Heading Hierarchy, Link Purpose). Each check maps to a specific success criterion — not just a generic "accessibility" bucket.

04 — Architecture

System Specifications

A distributed architecture designed for high-concurrency accessibility auditing and real-time design validation. Each choice was made deliberately.

Frontend Application

Next.js 14 for SSR performance; React 18 concurrent features for real-time scan updates.

Next.js 14React 18Tailwind CSS

Backend & Scan Engine

Playwright over Puppeteer for cross-browser coverage; BullMQ for multi-tenant job prioritization.

Express.jsPlaywrightaxe-coreBullMQ

Infrastructure

Supabase for instant Postgres + RLS; Redis for scan result caching; Vercel for zero-config deploys.

PostgreSQL (Supabase)RedisVercelGitHub Actions

AI & Integrations

GPT-4 for remediation suggestions; Figma Plugin API for canvas-level layer traversal.

OpenAI GPT-4Figma Plugin APIRazorpay (India launch)

05 — Impact

Early Results

Aulys is in active beta. Here's what's validated so far — and what's being built next.

30

Beta Testers Active

30 designers are actively testing the plugin, surfacing real-world edge cases across diverse design systems and enterprise-scale Figma files.

500+

Frames scanned across beta — in under 10 seconds each.

RTL + CJK

Validated multilingual typography support — covering Arabic, Hebrew, Japanese, and Chinese scripts.

What's Next: CI/CD Platform

Beta feedback made one thing clear: teams want accessibility baked into their deployment pipeline, not just the design stage. The Phase 2 SaaS platform — currently ~50% built — will integrate Playwright and axe-core to scan live deployments and block non-compliant builds automatically.

GPT-4 RemediationPlaywright Matrix TestingCI/CD Pipeline BlockingEnterprise Dashboards

06 — Reflection

What I'd Do Differently

Building a 0→1 product solo — design, engineering, and product — taught me things no spec document ever could.

Design Constraint

Figma plugin API shapes every interaction decision

The plugin runtime has no background threads — every scan must complete synchronously within a 60fps canvas budget. This ruled out streaming results, forced a batch-scan model, and made the progressive reveal of violations (grouped, not streamed) a technical necessity, not just a UX preference.

What didn't work

V1 had drag-to-reorder violations — too complex

The first violations list let users drag-and-drop to reprioritize issues. In beta testing with junior designers (primary target users), this interaction pattern caused confusion — they expected the list to be sorted by severity, not be a task manager. Removed it in v2 and defaulted to severity-ordered, read-only grouping. Fix rate improved.

Next time

Design decisions need to be documented as they happen

When context-switching between design and engineering, I lost the rationale for several key UX decisions. I now maintain a lightweight decision log alongside the codebase.

Aulys is still evolving. The CI/CD platform is in active development — and with 30 beta designers giving live feedback, it's going in the right direction.

WCAG 2.1 AA Compliant

Verified via axe-core automated testing

We build accessible tools. This portfolio proves it.

Aulys is an accessibility tool — so this case study page itself meets WCAG 2.1 AA. Every heading, contrast ratio, focus indicator, and landmark on this page has been audited with axe-core and manually verified.

WCAG 2.1 Guidelines

Verified Criteria

Contrast (Minimum)1.4.3
AA
Resize Text1.4.4
AA
Keyboard Accessible2.1.1
A
Bypass Blocks (skip link)2.4.1
A
Focus Order2.4.3
A
Focus Visible2.4.7
AA
Label in Name2.5.3
A
Language of Page3.1.1
A
Name, Role, Value4.1.2
A
Tested with axe-core + Playwright✓ 0 violations