UXDX is an international conference series for the people who actually build digital products: product managers, designers, engineers, and the leaders trying to get them all moving in the same direction. It exists specifically to bridge those roles instead of siloing them into separate tracks, which made it exactly the right room to talk about where accessibility falls through the cracks between design and code. This year, accessiBe showed up twice, once in New York and once in Berlin.

In New York, Sapir Yarden, Brand & Community Lead, and Remington Shea, Senior Account Executive, attended as guests rather than exhibitors, and came away with a clear read on the room. Accessibility came up in conversation. It just wasn’t the main focus for most of the room. Designers, many from large banking and insurance enterprises given the location, understood why accessibility mattered. What they didn’t have was a clear answer for who owned it. Every conversation pointed in the same direction: talk to product, talk to engineering.

In Berlin, the team led a full workshop for UXDX EMEA attendees. Haim Repael Azoulay, VP of Design & Experience, and Rina Volovich, Senior Accessibility Consultant, ran the session together. The room was packed, and the questions kept coming after it ended.

accessiBe also exhibited at UXDX Berlin with a dedicated booth, staffed by Gil Toledo, Product Lead for accessFlow, Aviva Drozdin, Head of Accessibility Services, and Account Executives Christian Lilley and Remi Shea, running conversations under a simple message: ship inclusive experiences, not accessibility debt.

Closing the accessibility gap between UX design and code

The Berlin workshop, “AI and web accessibility in practice: closing the design-to-code gap,” tackled a problem a lot of teams recognize: accessibility gets built into a prototype, then doesn’t survive the handoff. By the time QA catches it, fixing it costs far more than it would have at the start. The industry has a name for fixing this earlier: shifting left, catching problems at the start of a process instead of the end. Design is where that shift has to begin, because it’s also where most accessibility problems originate.

Haim and Rina walked attendees through a practical, end-to-end flow for breaking that pattern: how to embed accessibility into design systems from the start, how to steer AI-powered tools, including Figma plugins and code assistants, toward semantic and accessible output, and how to review that output with an accessibility lens before it reaches production.

Teams building this kind of accessibility-aware pipeline into their own workflow can use accessFlow, which integrates directly into existing development processes instead of adding a separate step.

“Design is where accessibility is born or broken. The way you design a product decides who can use it and who can’t, and most accessibility barriers get built in long before anyone writes a line of code. That’s what we wanted people to walk away with in Berlin: not another reason accessibility matters, but where in their own process it actually gets decided.” – Haim Repael Azoulay, VP of Design & Experience

What the room told us

Attendees said they walked away with insights they didn’t expect to get. Cameras went up on nearly every slide, and the energy held for the full session.

What stood out most wasn’t the reaction. It was who was in the room. Two of the largest global consumer goods companies chose accessiBe’s session for their workshop day at the conference, and their teams were grappling with the exact same question as teams a fraction of their size: how do you keep accessibility from slipping through the cracks at scale?

That’s the proof point that matters here. Massive organizations with dedicated engineering teams and mature design systems are running into the same wall as small teams. It’s structural, and our conversations in both cities suggest it shows up regardless of size.

What New York and Berlin had in common

New York and Berlin are different markets, with different regulatory landscapes and different product cultures. But the same gap showed up in both rooms, just at different altitudes.

In New York, it looked like an individual designer who cared but had no operational path to act. In Berlin, it looked like a global enterprise that still hadn’t figured out who owns accessibility once a product reaches real scale. Same gap. Different zip code, different org chart.

Teams understand why accessibility matters. What they don’t have is a clear answer to who owns it and how it survives the handoff from design to engineering. That’s the conversation we’re hearing in every market we’ve shown up in this year, not just the ones with the most mature regulation.

What’s next for the design to code pipeline

Who actually owns accessibility? No one had a clean answer. UXDX 2026 was one stop to figuring this out, but a meaningful one. Getting into rooms with the people actually building these products, and hearing where they get stuck, sharpens how we think about the work. The teams that figure out how to shift accessibility left, into design, before code and before QA, are going to spend a lot less time firefighting later.

If you were at the UXDX conference in New York or Berlin, or you’re a designer seeking to integrate accessibility and want to keep the conversation going, we’d love to hear from you.