← All projects
Live

AisleClear

Automated accessibility auditing for Shopify storefronts, delivered as a plain-English PDF.

BuiltJul 2026
RoleSole developer
StatusLive, pre-revenue
Cost per auditNear zero

What it does

A shop owner drops in their storefront URL. A few minutes later they get a PDF that names the five accessibility problems most worth fixing first, explains each one in language a non-developer can act on, and points at the theme or app that introduced it.

The last part is what makes it useful rather than noisy. Most automated accessibility scanners hand back a wall of raw WCAG violations with no sense of priority and no indication of who is responsible for the markup. If the broken contrast is coming from a review widget you installed, that's a completely different job than if it's coming from your theme — and it changes who you have to ask.

Why I built it

Accessibility lawsuits against ecommerce storefronts are a real and growing cost, and the people most exposed are small operators who have no idea their storefront is non-compliant. The gap looked like a good fit for automation: the detection is mechanical, the explanation is not.

The honest part: I built it before I researched the market, and it turned out audits of this kind were already being sold by other people. That was an expensive lesson and it changed how I start things now — market check first, then build. I kept going because the pipeline itself was worth finishing and the attribution angle is genuinely better than what I found being offered.

How it works

  1. IntakeA request form posts to a Netlify Function that screens for bots with Turnstile, a honeypot field, and per-IP rate limiting before anything expensive runs.
  2. DispatchThe function triggers a GitHub Actions workflow, which keeps the long-running crawl off the request path entirely.
  3. CrawlPlaywright walks the storefront and renders each page as a real browser would, so JavaScript-injected markup is included in the audit.
  4. Detectaxe-core runs the WCAG rule set against each rendered page and returns raw violations.
  5. AttributeViolations are traced back to the theme or the specific app that generated the offending markup.
  6. RankFindings are scored by severity and reach, and cut to a Top 5 — the point is a list someone will actually work through.
  7. ExplainClaude rewrites each finding into plain English with a concrete fix, rather than restating the rule ID.
  8. DeliverThe report is rendered to PDF and emailed through Resend.

Incident log

Things that were wrong, how they surfaced, and what I changed. This is the part of the project I'd actually want to talk about in an interview.

01

Confident reports about pages it never saw

Symptom

An audit completed normally and produced a clean, professional-looking report — for a storefront that was sitting behind Shopify's password page. The report was well-formatted, internally consistent, and completely meaningless.

Root cause

The crawler had no concept of whether it had reached the real storefront. A password gate or a placeholder page returns HTTP 200 with valid markup, so every downstream stage — detection, attribution, scoring, the plain-English rewrite — did its job correctly on the wrong input and produced a confident answer.

Why it mattered

This is the worst failure mode a tool like this can have. A crash is obvious and costs nothing. A polished report that's wrong gets forwarded to a client, and the person it misleads has no way to tell.

Fix

Added a gate ahead of the audit that detects password walls and placeholder pages, aborts the run, and sends an alert instead of a report. The tool now declines to answer rather than guessing. Covered by the test suite — 24 tests passing at 7456d59.

Known limits

What I'd do next