Freelance engagement · 2026

ComplAudit — Web Accessibility (RGAA / WCAG)

Code-level accessibility audits prioritised by legal risk — the opposite of overlays promising compliance in one line of script.

Role Full-stack design & development
Period 2026
Sector Compliance / e-commerce (Europe)
Context Freelance engagement
01

The problem

The European Accessibility Act makes accessibility enforceable across a large part of European online commerce. The market answered with overlays: a third-party script layering a widget over the site. Those solutions are widely contested — they do not fix the underlying code, and several lawsuits have targeted sites that had one installed.

ComplAudit takes the problem from the other end: genuinely audit the pages, point at the defects in the code, and supply both the precise fix and the evidence needed if challenged.

02

What I built

Audit engine

automated traversal of pages in a real browser, analysed against the RGAA 4.1 and WCAG 2.1 AA standards.

Risk-based prioritisation

defects ranked by legal exposure and user impact, not just technical severity.

Authenticated-journey auditing

the ability to audit pages behind login, where most of a purchase funnel actually lives.

Reports and evidence packs

PDF and CSV export plus timestamped evidence bundles, usable during an inspection.

Public compliance badges

endpoints generating a verifiable badge to display on the audited site.

User feedback widget

an embeddable component letting visitors report an accessibility barrier.

Distribution

integration modules for the main e-commerce platforms.

SaaS foundation

multi-team organisations, invitations, admin back-office, subscriptions, front-end in five languages.

03

Architecture & technical decisions

The audit engine is a service separate from the main application. Auditing means driving real browsers over arbitrary pages: a heavy, unpredictable and potentially hostile workload. Isolating it protects the business application and lets both scale independently.

Communication between the API and the audit service is cryptographically signed in both directions, with idempotency keys and an event-deduplication table. An audit can run long and notify several times: without that discipline, a report could be counted twice or a notification replayed indefinitely.

The product builds on a proven accessibility analysis engine rather than home-grown rules: the value is not in redefining the criteria — they are standardised — but in running them at scale, prioritising them legally and producing evidence.

The public front-end is server-rendered for SEO, in five languages, with automated accessibility tests on the product itself. An accessibility audit tool failing its own criteria would have no credibility.

04

Technical challenges

Auditing sites you do not control. Slow pages, blocking scripts, bot protection, infinite content: the engine has to fail cleanly rather than hang.

Authenticated journeys. Auditing a checkout flow means handling test credentials securely and verifying site ownership before any access.

Result stability. Two audits of the same page must be comparable over time, otherwise the notion of progress is meaningless.

Translating a standard into priorities. Turning a technical reference framework into a work queue a non-specialist team can act on is the real product work.

Evidential value. An evidence pack must be dated, complete and tamper-evident to mean anything in a dispute.

05

Complete tech stack

API

Laravel 13 PHP 8.3 Fortify Sanctum Cashier / Stripe Reverb

Front-end

Nuxt 3 Vue 3.5 TypeScript Tailwind CSS 4 5-language i18n

Audit engine

Node / TypeScript Fastify Playwright axe-core HMAC-signed webhooks

Distribution & quality

E-commerce modules Public badges Embeddable widget Lighthouse Vitest

Have a similar project in mind?

Let's talk it through — scope, quote and timeline within 24 hours.