AccessSpark: the accessibility platform I designed and built end to end
A live auditing platform that tests the modern web the way real users meet it, in a real browser, behind logins, and produces a VPAT from what it actually measured.
Why I built it
A blind friend couldn't get through a site that an automated checker rated clean. The scanner said everything passed; a real person using a screen reader was stuck. The tool said pass. A real person was stuck. AccessSpark exists to close that gap.
I built it to audit the web the way it actually ships today: single-page apps, React dashboards, pages behind a login, sites with bot protection that static scanners never reach. I built it for my own consulting work first, then turned it into a product.
The core decision: audit the rendered page, in a real browser
Static scanners read the HTML a server ships. That is exactly what failed my friend: the markup parsed clean while the rendered page was unusable. AccessSpark loads every page in headless Chrome and audits the fully rendered DOM, the same thing a screen reader meets. It costs more to run and to build. It's also the only way to catch problems in apps that render in the browser or sit behind a login. Choosing the cheaper static approach would have rebuilt the exact tool that rated the broken site as passing.
What I designed and built
End to end: product vision, UX, the design system, the architecture, billing, docs, and the marketing site. It ships four ways:
Web app
Audit and monitor
Run audits, manage multi-page crawls, track trends, and export reports.
Chrome extension
Behind the login
Audit authenticated and staging pages using your own session, one click.
CLI
In your pipeline
Drop into CI/CD and fail a build on an accessibility regression.
MCP server
For AI agents
Let an AI assistant run audits inline, right in the conversation.
Flint: the system underneath
Every surface above stands on one design system. I named it Flint. It runs AccessSpark and this portfolio today, and Inner Spark Media moves onto it next.
Flint is one token source for color, type, spacing, radius, control sizing, and icon and target-size minimums. Components read from semantic intent tokens rather than raw values, so a button or an input cannot drift between products, and the same tokens drive light and dark. Accessibility is built into the tokens from the start: color pairs are contrast-checked, and minimum target sizes and focus styles are tokens, so anything built on Flint inherits them.
Flint has its own case study: how the tokens, platforms, and build checks fit together.
One token source
Color, type, space, radius, control, and target size in a single place.
Semantic by default
Components use intent tokens, so they cannot drift between products.
Accessible primitives
Contrast, focus, and minimum target size are built into the tokens.
One base, many brands
One foundation; each identity is a brand layer on top.
What it does
One run gives the whole picture. Accessibility against WCAG 2.0 through 2.2 with axe-core plus my own checks, run against the fully rendered page, alongside SEO, security, and performance.
Real-browser rendering
Headless Chrome loads the real DOM, so SPAs and dynamic content get caught.
AI fix, one or all
Code-level remediation per element, written for the engineers who ship it.
Real VPAT 2.5
Every criterion derived from detected issues; anything untested is marked Not Evaluated.
Continuous monitoring
Crawl whole sites and track scores over 7, 30, and 90-day windows.
The outcome
AccessSpark is live and in real use. It also audits this very portfolio on every release, which is why the footer's accessibility claim comes from a real audit.
What I'd carry forward
Building all of it taught me one thing: put accessibility in the tokens early. Everything built on them gets it for free, and nobody cleans it up later. That's what I bring to enterprise teams. AccessSpark audits this site on every release, and anyone can open the audit and VPAT.
See the real output
Both files came straight out of AccessSpark. Judge the work yourself.