Sunset · This app is no longer running

Conformly: an accessibility compliance agent for the European Accessibility Act

A compliance agent for the European Accessibility Act, built on an uncomfortable principle: never tell a customer they're compliant.

The European Accessibility Act has been in force since June 2025, and most teams reach for an overlay widget that promises a green badge overnight. Conformly takes the opposite stance. It runs deterministic, LLM-free scans mapped to EN 301 549 and WCAG, opens validated fixes as real pull requests, routes anything ambiguous to human review, and writes every step to a hash-chained, tamper-evident audit trail. The output isn't a badge. It's dated evidence you can hand to a regulator, a customer, or a court. This is the design story of making honest status the product.

EN 301 549 conformance summary

EN 301 549 v3.2.1 · Generated 9 Jun 2026
38 criteria: no automated issues 6: routed to human review 12: not applicable

Each line is a status with a date and a reason: remediated, no automated issues, or human review. Nowhere does it say “compliant.” That word is a legal conclusion the tool refuses to make on a customer's behalf.

Non-text content 1.1.1 · remediated
Contrast (Minimum) 1.4.3 · remediated
Keyboard 2.1.1 · no issues
Focus Order 2.4.3 · human review
Labels or Instructions 3.3.2 · remediated

The conformance summary, reinterpreted in the portfolio design language. Statuses and dates, never a verdict.

01: The problem

The problem: a legal deadline, and a market selling green badges

The European Accessibility Act came into force in June 2025. For a large class of digital products sold into the EU, EN 301 549 (which leans on WCAG 2.1 AA) stopped being a nice-to-have and became a legal obligation with real exposure.

The market's instinct was to buy the fastest-looking fix: an accessibility overlay, a script you paste in that promises instant compliance and a badge in the corner. Overlays don't repair the underlying experience. They layer a second, often broken interface on top of a broken one, and a growing body of litigation has targeted sites that use them. Worse, a badge is a claim with nothing behind it. When a regulator or a blind user says “prove it,” there's no evidence, only marketing. The real design problem isn't generating confidence. It's earning it, and being able to show your work.

Grounded in the regulation

EN 301 549 is the European harmonised standard for ICT accessibility. For web content it adopts WCAG 2.1 Level AA as its core. Conformly is built and positioned against the overlay model: overlays are not remediation, and honest, evidenced status beats a synthetic badge.

02: The thesis

The thesis: report conformance, never claim compliance

Conformly's founding principle is a refusal: it will never tell you you're compliant. Compliance is a legal verdict about your whole product and your whole obligation, and no scanner can responsibly assert it. What a tool can do is report the conformance of the criteria it can detect, attach a date and a reason to each one, and keep the receipts. Designing for that honesty, instead of around it, is the whole job.

Detectable, not declared

Automated checks cover a real but bounded slice of WCAG. Conformly reports status for exactly that slice and labels the rest as needing human review. It never turns a clean scan into a clean product.

Dated, not perpetual

Every status is a snapshot with a timestamp. “Conformant on 9 Jun 2026” is defensible. “Conformant” forever is not. The date sits next to the claim, always.

Evidenced, not asserted

Behind every status sits a chain of artifacts: the scan, the fix, the re-scan, the reviewer. The claim is only as strong as the evidence, so the evidence is what the product is built to produce.

03: The loop

Detect → Fix → Document → Monitor

Accessibility isn't a one-time audit. It's a property that decays with every deploy. So the product is a loop, not a report. Each stage produces an artifact the next stage consumes, and a human is always the one who decides what “done” means.

  1. STAGE 01
    Detect

    Deterministic, LLM-free scans run a real headless browser over real pages, the same engine class teams already trust, so findings are reproducible.

  2. STAGE 02
    Fix

    Validated fixes open as real pull requests against your repo and are confirmed by a re-scan before they're called resolved. Uncertain cases go to a human.

  3. STAGE 03
    Document

    Every event is written to a hash-chained, tamper-evident audit trail and rolled up into an accessibility statement generated from evidence, not prose.

  4. STAGE 04
    Monitor

    Re-scans run continuously. A regression reopens the finding and dates it, so the audit trail always reflects the product as it ships today.

Deterministic detection: findings

axe-core · real headless browser · LLM-free

Contrast below 4.5:1 on primary actions

WCAG 1.4.3 Contrast (Minimum) · Low-vision users

Blocks task completion

Focus traps & skipped order in the checkout dialog

WCAG 2.4.3 Focus Order · Keyboard-only users

Blocks task completion

Form field missing a programmatic label

WCAG 3.3.2 Labels or Instructions · Screen-reader users

Degrades experience

Redundant title attribute duplicates visible text

Advisory · best-practice hygiene

Cosmetic / advisory

The detection surface, rebuilt in the portfolio design language. The engine is deterministic. The design work is the ranking, the language, and the affected-user framing.

Stage 01 of 04

04: Detect

Findings framed by who is blocked, with the rule as the citation

A raw axe-core dump is a list of rule IDs. Correct, and useless to the person who has to triage it. The design move is to lead with who is blocked and how badly, then attach the WCAG criterion as the citation underneath.

Severity is framed as task impact: does this block task completion, degrade the experience, or is it cosmetic or advisory? Each finding names the population it hurts, so triage maps to real harm rather than abstract conformance.

Stage 02 of 04

05: Fix

Fixes ship as pull requests, resolved only after a re-scan

Most accessibility tools stop at telling you what's wrong. Conformly proposes the change as a real GitHub pull request against your codebase (reviewable, revertible, attributable) and marks the finding resolved only once a re-scan verifies the fix closed it. A fix that doesn't pass the re-scan isn't a fix.

Where a change is ambiguous, anything a deterministic rule can't safely settle, it goes to human review instead of auto-merge. The agent suggests. A person decides. It runs as a least-privilege GitHub app with EU data residency, so the blast radius is exactly “open a PR,” never “push to main.”

Fix opened as pull request

least-privilege app · re-scan gated

Finding detected: 1.4.3 Contrast (Minimum)

Primary action measured below the 4.5:1 minimum · blocks task completion

Fix opened as PR #418

Token --btn-primary darkened to meet 4.5:1 · diff scoped to one file

Fix verified by re-scan

Re-scan after merge cleared the 4.5:1 threshold · finding closed with evidence attached

“Fix opened as” and “Fix verified by re-scan”: the product's own loop, drawn as the chain it is.

Hash-chained audit trail

tamper-evident · EN 301 549 mapped

Scan completed

56 criteria evaluated · deterministic engine · 9 Jun 2026 09:14 UTC

sha256:9f2a…c401 ← genesis

Fix opened as PR #418

1.4.3 Contrast · author attributed · awaiting re-scan

sha256:b7e1…22da ← prev 9f2a…c401

Fix verified by re-scan

1.4.3 cleared on re-scan · status → remediated · 9 Jun 2026 11:02 UTC

sha256:4c8d…91f0 ← prev b7e1…22da

Accessibility statement generated

Built from the chain above · human review noted for 2.4.3

sha256:e0a6…7b5c ← prev 4c8d…91f0

Hashes are illustrative. The real chain links cryptographically, so the record can be audited but not edited.

Stage 03 of 04

06: Document

A hash-chained audit trail behind every status

If honest status is the product, the evidence behind each status has to be unfakeable. Conformly writes every event (scan, finding, fix, re-scan, human review) into a hash-chained, tamper-evident audit trail. Each entry carries the hash of the one before it, so altering history breaks the chain visibly.

From that trail it generates an accessibility statement built from real, dated events rather than aspirational copy. The kind of artifact you can attach to a procurement questionnaire or a regulator's request and defend.

Stage 04 of 04

07: Monitor

Continuous scanning, because conformance decays with every deploy

A finding closed in June is not a finding closed in September. A theme change, a new component, a copy edit: any of them can put a criterion back under the line. Conformly re-scans continuously, and a regression reopens the original finding rather than filing a fresh one, so the history of that criterion stays in one place.

The reopen is dated and written to the same chain, which means the accessibility statement moves back to under review on its own. Nothing has to be remembered by a person, and the published status is the product as it ships today rather than as it passed once.

Continuous re-scan: a regression reopens

every deploy · dated · same chain

1.4.3 Contrast closed

Remediated 9 Jun 2026 11:02 UTC · statement published from the chain

Deploy detected, re-scan queued

Marketing theme update shipped · 56 criteria re-evaluated on the live pages

1.4.3 Contrast reopened

Primary action back below 4.5:1 · dated 24 Jun 2026 08:41 UTC · statement returned to under review

Fix opened as PR #602

Same token, same one file diff · the loop starts again at Fix, not at Detect

The design question here was what a regression should look like. Reopening the finding keeps one criterion's whole history on one thread; a new finding would have split it.

08: The stance

How this differs from an overlay

An overlay and Conformly look adjacent on a feature list: “we do accessibility.” They are opposites in what they deliver. Making that contrast legible is a positioning job as much as a design one, and it's where the product's point of view earns its keep.

The overlay model

Injects a second UI over a broken one

Sells a badge, a claim with nothing behind it

Leaves your source code untouched

No durable evidence when challenged

Asserts “compliant”

Conformly

Fixes the real markup at the source

Ships fixes as reviewable pull requests

Re-scan-gated; uncertain → human review

Hash-chained, tamper-evident audit trail

Reports honest, dated status, never a verdict

09: The design work

Designing trust into a regulated, AI‑assisted workflow

The hard part of an accessibility agent isn't the scanner. That part is deterministic and bought, not built. The product is won or lost in the surfaces around it: how a finding is framed, how a fix earns the word “resolved,” and how a status stays honest under legal pressure. That's the design.

Impact-first findings. Reframed rule IDs as task-blocking severity plus named affected users, so triage tracks human harm.
Honesty as a constraint. Designed the status vocabulary (remediated, no issues, human review, not applicable) so “compliant” is structurally impossible to render.
Human-in-the-loop seams. Made the suggest-versus-decide boundary visible: the agent opens PRs and flags uncertainty; people merge and review.
Evidence as interface. Treated the audit trail as a first-class surface. The receipts are the product, not a log buried in settings.
Anti-overlay positioning. Built the comparison that makes “we do accessibility” legibly different from “we prove accessibility.”
Accessible by construction. A tool that judges accessibility has to pass its own bar: keyboard paths, contrast, and semantics held to the standard it enforces.

Why it belongs in the Lab

Conformly is the AI Product Design Lab thesis in a regulated domain: turning model behavior into a workflow people can direct, understand, and trust. The model proposes, the evidence persuades, the human decides. It sits beside Vantage and Criterion as work about making AI's judgment legible and accountable, this time with a regulator in the room.

Explore more work

Three more case studies about work that shows its reasoning: an interview score you can argue with, four earthquakes told in data, and the interaction principles underneath both.

Criterion, an interview score you can argue with
Every score links to the exact words that earned it, and a score you disagree with can be challenged: the model re-evaluates in the open. Live at criterionscore.com.
Readout, four earthquakes in Japan
A long form data story about Kobe, Tohoku, Kumamoto and Noto, told with a live D3 chart library over two pinned USGS catalogues. Every chart opens for a closer look, and the dashboard behind them is public.
The Interaction Layer, seven principles of interaction design
Seven principles of what an interface is like to use, each grounded in human computer interaction research and proven by a demo you can run. Hand built, no animation library.