Acces­si­bil­i­ty by Design Engineering

Most accessibility problems don’t start as code bugs. They start as a focus state that was never specified in the design file. A color token that passes contrast in the design tool but shifts in the CSS implementation. An error message that’s visible on screen but never announced to a screen reader, because the ARIA attribute that would announce it was nobody’s job.

By the time these problems surface in a compliance review, a user complaint, or a formal audit, components have to be rebuilt and decisions teams thought were settled have to be revisited.

Here’s one I find in almost every audit:

A designer notices that interactive elements show a browser default focus ring. It looks inconsistent with the design. The fix seems obvious: remove it. One line of CSS. outline: none. Done. Most automated tools won’t catch this – checking focus states reliably means triggering focus on every interactive element and inspecting what actually renders, not just what the CSS says.

But try to navigate that page without a mouse now. Tab through the navigation. Try to reach the checkout button. You can’t tell where you are. For everyone who navigates by keyboard – screen reader users, people with motor disabilities, power users, anyone without a working mouse – the product has become unusable.

The design decision was reasonable. The implementation was correct. The automated scan was clean. And the product is broken.

There’s a CSS property, by the way, that resolves exactly this tension: :focus-visible. But knowing it exists and making sure it’s actually specced and implemented – that falls into the space between design and engineering nobody felt responsible for.

I work on both sides #

I trained as a designer. I build in code. Working at the intersection of both means I can follow an accessibility decision from the design file to what a screen reader actually announces – and understand at every step why it did or didn’t hold.

I can review a component in Figma and in the browser in the same conversation. I can work with your designer on why a particular pattern won’t survive implementation, and with your developer on why the result doesn’t reflect what the design intended.

On this engagement, the person who reviews your Figma file is the same person who opens your repository.

Three ways to work together #

Accessibility Audit #

A manual review against WCAG 2.2 and EN 301 549 – the standard underlying both the EAA and Germany’s BFSG – tested with assistive technology, not just automated scanning tools. For public sector clients, audits also cover BITV 2.0.

You get a prioritized report with actionable, context-specific recommendations. An analysis of where in your process they originate, and what needs to change so they don’t come back. Not a checklist of criteria. Not a PDF to file away. A document your design and engineering teams can actually use.

Good for: Products preparing for EAA/BFSG compliance. Redesigns that need a baseline before new work begins. Design systems that haven’t been tested end-to-end.

Hands-On Implementation #

I work directly in your codebase – reviewing pull requests, writing accessible components, fixing specific issues, or supporting your team through a focused remediation sprint.

No handoff document. Actual changes. This is what you need when the bottleneck isn’t knowledge – it’s bandwidth, or the gap between what the audit found and what your team knows how to fix.

Good for: Teams with limited frontend capacity. Specific components that need to be rebuilt correctly. Post-audit support when you want the findings resolved, not just documented.

Workshops for Interdisciplinary Teams #

Half-day or full-day workshops built around real accessibility problems from real products. Designers and developers work through the same problems together: how a component should behave semantically, what needs to be specified in the design, what needs to happen in implementation, and where the typical breakdowns are.

The goal is a team that can make better decisions independently. Not permanent dependency on external consultants.

Good for: Teams starting an accessibility practice. Agencies onboarding to EAA/BFSG requirements. Organizations that want to build internal capability, not outsource it.

How I Work #

I’m a freelancer, not an agency. You work with me directly – on calls, in Figma, in your repository. No account managers, no junior handoffs, no one else writing the report.

Engagements are scoped to what’s actually useful. I don’t build in unnecessary phases. If a half-day workshop is what your team needs, that’s what I’ll propose.

I’ve spent nearly twenty years working at the intersection of design and engineering – and over a decade teaching at Muthesius Academy of Fine Arts and Design. I’ve seen where accessibility breaks in practice, not just in theory. That experience shapes everything I recommend.

Where teams usually are when they call me #

Maybe accessibility is on the agenda but nobody owns it yet. Maybe your designers and developers are solving the same accessibility problems independently, in two different directions, and the results aren’t consistent.

The goal isn’t a product that passes a single audit – it’s accessibility that survives the next project, by making it part of how your team works. If any of this sounds familiar, let’s figure out whether what I do is a good fit for what you need.

I’m based in Stuttgart and work with clients across Germany, Europe, and internationally. Engagements are available in German and English.