Own product — lukeduff.co.uk
Software / SaaS Product
The European Accessibility Act applies to a large number of commercial websites, and the practical obligations that come with it — testing every page, understanding which standard a failure breaches, and publishing a formal Accessibility Statement — are difficult to meet by hand. Most accessibility tools stop at listing violations and leave the legal and remediation work to the customer.
A11y Shield was built to cover the whole loop instead of one step of it: crawl a site, audit every page with axe-core running in real headless Chromium, score conformance against EN 301 549, generate the Accessibility Statement that the regulation requires, export a remediation plan the development team can actually work from, and then keep monitoring for regressions after each deploy.
This is an in-house product rather than client work, and it is written up here as an engineering case study. The platform is around 17,100 lines across 156 files, has been verified end-to-end against real websites, and the public marketing and legal site is live. The logged-in product is not yet transacting — it is gated on the final third-party provisioning (Clerk Organizations, a production Supabase project and the Fly worker deploy), so there are no customers, users or revenue figures to report.
| Problem | Solution Implemented |
|---|---|
| A list of violations does not tell anyone what to fix first or how bad the site actually is | Built a scoring model that weights each finding by severity and feeds a logarithmic element multiplier into exponential decay, producing a bounded, monotonic 0–100 conformance score and an A–F grade. The risk band is anchored on that score and escalated when critical barriers sit on a transactional journey. |
| Findings from an automated tool are not expressed in the language the regulation uses | Wrote a zero-dependency mapping layer of 406 lines that translates axe rule tags into WCAG 2.2 success criteria and then into EN 301 549 Chapter 9 clauses, with plain-English framing so a non-technical stakeholder can follow what each failure means. |
| Driving a real browser to arbitrary user-supplied URLs is a serious server-side request forgery risk | Implemented a byte-canonicalised SSRF guard with per-hop connection pinning — the addresses validated during the check are the exact addresses reused for the connection via a per-hop undici agent, so DNS cannot be rebound in between. A second network egress filter runs in the worker container because a headless browser resolves independently of the application. |
| Deciding whether a page sits on a transactional path needs to be accurate, not a naive substring match | Made the transactional-path detection boundary-aware, so a URL such as /my-account is correctly identified while /accountant-services is not — which matters because that classification is what escalates the risk band. |
| Auditing a full site is long-running work that cannot sit inside a single web request | Split the system into a Next.js 16 application and a standalone Fastify, Playwright and axe-core worker, with Inngest handling the durable crawl and per-page audit fan-out, so a scan survives restarts and each page is retried independently. |
| Optional integrations should not be able to break the core product | Built graceful degradation throughout: without an Anthropic key the statement prose and fix examples fall back to deterministic templates, without Resend email quietly no-ops, and without Stripe the billing screens show a reference and a clear message rather than erroring. |