Conformly: finding and fixing accessibility issues under the European Accessibility Act
A tool for the European Accessibility Act, built on one rule: it never tells a customer they're compliant.
The European Accessibility Act has applied since June 2025. Many teams respond by adding an overlay, a script that sits on top of a site and promises instant compliance. Conformly does the opposite. It scans pages with fixed rules and no AI model, mapped to EN 301 549 and WCAG, so the same page always gives the same result. It opens fixes as real pull requests (proposed code changes your team reviews). Anything unclear goes to a person. Every step is saved in a hash-chained audit trail, a record that shows if anyone edits it later. What you get is dated evidence, not a badge.
- Context
- My own product
- My role
- Designed and built it alone, end to end
- What I built
- A tool that scans sites against EN 301 549 and WCAG, opens fixes as pull requests and keeps an audit trail
- Status
- Site live, scanning paused. Not tested with users
EN 301 549 conformance summary
Each line is a status with a date and a reason: remediated, no automated issues, or human review. It never says "compliant." That is a legal judgment, and the tool won't make it for a customer.
The conformance summary, redrawn in this site's style. It shows statuses and dates, never a verdict.
01: The problem
The problem: a new law, and a market full of quick fixes
The European Accessibility Act came into force in June 2025. For many digital products sold in the EU, meeting EN 301 549 (which builds on WCAG 2.1 AA) became a legal requirement.
Many teams reached for the fastest-looking fix: an accessibility overlay. That's a script you paste into your site that promises instant compliance and adds a badge. Overlays don't fix the site underneath. They add a second layer on top, which often has problems of its own, and a growing number of lawsuits have targeted sites that use them. A badge is also just a claim. If a regulator or a blind user asks for proof, there is nothing to show.
About the standard
EN 301 549 is the European standard for accessible technology. For web content, it uses WCAG 2.1 Level AA as its core. Conformly is built as the alternative to overlays: they don't fix anything, and honest status with evidence behind it is worth more than a badge.
02: The main idea
The main idea: report what was checked, never claim compliance
Conformly will never tell you you're compliant. Compliance is a legal judgment about your whole product, and no scanner can make it responsibly. What a tool can do is report on the checks it can run, give each one a date and a reason, and keep the records. Designing around that limit was most of the work.
Only what can be checked
Automated checks cover part of WCAG, not all of it. Conformly reports on that part and marks the rest for human review. A clean scan never turns into a claim that the whole product is fine.
Dated, not permanent
Every status has a date. "Conformant on 9 Jun 2026" can be defended. "Conformant" with no date can't. The date always sits next to the status.
Backed by records
Each status is backed by a chain of records: the scan, the fix, the re-scan and the reviewer. A status is only as strong as those records, so producing them is the product's main job.
03: How it works
Four steps: Detect, Fix, Document, Monitor
Accessibility isn't a one-time audit. Any deploy can break something, so Conformly runs as a loop instead of producing a single report. Each step hands its output to the next, and a person always decides when something is done.
-
STAGE 01
Detect
Scans run in a real browser on your real pages, using the kind of checker many teams already trust. Fixed rules and no AI model mean the same page gives the same results every time.
-
STAGE 02
Fix
Fixes open as real pull requests on your code. A fix only counts as resolved after a re-scan confirms it. Unclear cases go to a person.
-
STAGE 03
Document
Every event is saved in a tamper-evident audit trail. The accessibility statement is generated from that record, not written by hand.
-
STAGE 04
Monitor
Scans keep running. If something breaks again, the original finding reopens with a date, so the record always matches what is live today.
Deterministic detection: findings
Contrast below 4.5:1 on primary actions
WCAG 1.4.3 Contrast (Minimum) · Low-vision users
Focus traps & skipped order in the checkout dialog
WCAG 2.4.3 Focus Order · Keyboard-only users
Form field missing a programmatic label
WCAG 3.3.2 Labels or Instructions · Screen-reader users
Redundant title attribute duplicates visible text
Advisory · best-practice hygiene
The findings view, redrawn in this site's style. The scanning engine is off the shelf. My design work was the ranking, the wording and naming who is affected.
04: Detect
Findings start with who is blocked, then cite the rule
Axe-core is a common open-source accessibility checker. Its raw output is a list of rule IDs: accurate, but hard for the person who has to sort through it. So each finding leads with who is blocked and how badly, with the WCAG criterion underneath as the reference.
Severity describes what the problem does to a task: does it block task completion, degrade the experience, or is it cosmetic or advisory? Each finding also names the people it affects, so the team fixes the most harmful problems first.
05: Fix
Fixes arrive as pull requests and count only after a re-scan
Most accessibility tools stop at listing problems. Conformly proposes the change as a real GitHub pull request: a suggested code change your team can review, undo and trace back to its author. The finding is marked resolved only after a re-scan confirms the fix worked.
If a rule can't safely make a change, it goes to human review instead of being merged automatically. The tool suggests and a person decides. It runs as a GitHub app with only the permissions it needs and keeps data in the EU. The most it can do is open a pull request. It can never push code straight to your main branch.
Fix opened as pull request
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" are the product's own labels, shown here as the steps they describe.
Hash-chained audit trail
Scan completed
56 criteria evaluated · deterministic engine · 9 Jun 2026 09:14 UTC
sha256:9f2a…c401 ← genesisFix opened as PR #418
1.4.3 Contrast · author attributed · awaiting re-scan
sha256:b7e1…22da ← prev 9f2a…c401Fix verified by re-scan
1.4.3 cleared on re-scan · status → remediated · 9 Jun 2026 11:02 UTC
sha256:4c8d…91f0 ← prev b7e1…22daAccessibility statement generated
Built from the chain above · human review noted for 2.4.3
sha256:e0a6…7b5c ← prev 4c8d…91f0Hashes are illustrative, not real values. In the product, each entry is linked to the one before it by a hash, so the record can be checked but not edited.
06: Document
An audit trail behind every status
The evidence behind each status has to be impossible to change quietly. Conformly writes every event (scan, finding, fix, re-scan, human review) to a hash-chained, tamper-evident audit trail. Each entry carries a hash, a short digital fingerprint, of the entry before it. If anyone changes an old entry, the chain visibly breaks.
Conformly then generates an accessibility statement from that trail, using real dated events instead of hopeful wording. You can attach it to a procurement questionnaire or a regulator's request and stand behind it.
07: Monitor
Scans keep running, because any deploy can break something
A finding fixed in June may not still be fixed in September. A theme change, a new component or a copy edit can each break a criterion again. Conformly re-scans continuously. When something breaks again, it reopens the original finding instead of filing a new one, so that criterion's history stays in one place.
The reopened finding is dated and written to the same chain, and the accessibility statement goes back to under review automatically. Nobody has to remember to update it. The published status always matches the site as it is today.
Continuous re-scan: a regression reopens
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 how a regression (something fixed that breaks again) should look. Reopening the finding keeps one criterion's history in one thread. A new finding would have split it.
08: Compared with overlays
How this differs from an overlay
On a feature list, an overlay and Conformly look alike: both say they "do accessibility." What they deliver is the opposite. I designed this comparison to make that difference easy to see.
Conformly
Fixes the real code at its source
Delivers fixes as pull requests your team reviews
Checks every fix with a re-scan and sends unclear cases to a person
Keeps a tamper-evident audit trail
Reports dated status, never a verdict
09: My design work
What I designed, and why
The scanner was the easy part. It uses fixed rules and came off the shelf. The real design work was everything around it: how a finding is described, when a fix earns the word "resolved," and how a status stays honest under legal pressure.
Why it is part of the Lab
Conformly applies the AI Design Lab's main idea to a regulated field: turn what an automated system does into a workflow people can direct, understand and trust. The tool proposes, the evidence backs it up, and a person decides. It sits next to Criterion, which is also about making automated judgment clear and accountable. This one has a regulator involved.
More case studies
Three more case studies: interview practice with scores you can question, a data story about four earthquakes in Japan, and seven principles of interaction design.