EAA Accessibility Consultant.

Most of my clients come to me with the same feeling: they know the EAA is enforceable and they're not sure where they stand or what to do first. That looks different depending on who you are — a Dutch SME owner staring down EAA enforcement for the first time, a marketing lead trying to squeeze a compliance retrofit into a packed quarter, a developer who wants clear requirements instead of vague guidelines, or an agency bringing in outside expertise for a client project. Whatever brought you here, I've probably seen a version of it before. And I can help.

The short answer: because the work is here. The EAA created real demand for accessibility expertise across Europe, and the Dutch market — with its strong digital economy, high public-sector standards, and DigiToegankelijk inheritance — needed people who understand both EU regulatory frameworks and the operational discipline that comes from US federal accessibility work. The longer answer: Alexandra and I had been talking about living in Europe for years. When the professional opportunity aligned with the personal dream, we made the jump. Being here in person means an actual understanding of how Dutch businesses think and operate.

"I believe the internet should connect us and make information accessible to everyone." That belief shapes how I work. I default to transparency — you'll always know where your project stands, what I'm finding, and what it costs. I approach every engagement with honesty, even when the audit results aren't what a client wants to hear, because trust is built through actions, not promises. I'm still learning new standards, new tools, new perspectives from the people I work with; and I think that's how it should be. Accessibility itself is a form of giving back by making the web work for everyone. This is one of the most meaningful things I can do with my skills. I also believe in taking care of the world outside the screen. I try to run my practice sustainably — minimal waste, conscious choices, doing what I can.

I test your site against the European Accessibility Act, EN 301 549, and WCAG 2.2 AA, document every finding with screenshots and code references, then map each issue by severity, user impact, and estimated effort to fix. You get a clear report your team can act on — not a 200-page PDF that sits in a drawer. I was on the receiving end of reports like that in my government days. They get filed and forgotten. So my findings are organized so developers, designers, and content editors each know exactly what to address.

Every project runs through a dedicated workspace on my Project Flow system. You get a personal dashboard with milestones, deliverables, files, and billing. It is all in one place so you are not chasing updates over email and wondering where things stand.

Years of managing digital content across government, media, and agency environments taught me something most accessibility specialists miss: it doesn't matter how good your standards are if your content team can't maintain them. I understand how content actually gets produced, published, and maintained — not just how it should be structured in theory. In practice, that means fixing heading hierarchies that break screen reader navigation, rewriting link text so it makes sense out of context, restructuring page templates so new content is accessible by default, and auditing document libraries where PDFs have been uploaded without tags or alt text for years.

EU and NL work is the focus, but I keep US-facing capability for clients who have both. If you're a Dutch company selling into the US, or a US firm with EU operations, I handle ADA Title II, Section 508, and VPAT 2.5 / Accessibility Conformance Report drafting under the same engagement. Most accessibility specialists know one framework. I work across both, so if your business spans both jurisdictions, you don't need two consultants.

Sixteen years across US states and a handful of countries before settling in Leiden. The places where I've worked or lived inform how I think about accessibility — different infrastructures, different baselines, different default behaviours.