Sulagna Ghosh

Let an AI model patch your accessibility tree live, and the first thing it will teach you is how it fails. Not occasionally, reliably, in specific, learnable ways: confident but wrong ARIA states, patches that compile but break keyboard flow, fixes that pass an automated audit while making the actual screen reader experience worse.This talk is not a victory lap for a clever pipeline. It's the failure modes first, then the architecture that exists specifically because of them. We'll look at why static linters structurally can't catch dynamic ARIA bugs, what it actually takes to make an AI-generated accessibility patch safe to apply automatically, and the much larger lesson underneath: the accessibility tree is downstream of component state, not of markup which means most AI-accessibility tooling is analyzing the wrong layer entirely.You'll leave with a concrete mental model for the gap between markup-level and state-level accessibility analysis, a typed validation pattern for constraining what an AI agent is allowed to touch in your UI, and an honest account of where this approach still falls short because if a talk about AI and accessibility doesn't tell you where it breaks, it hasn't been tested enough yet.

Most AI agents touching a React app today do it the crude way, scrape the DOM, guess at selectors, simulate clicks and hope. WebMCP proposes something different: defining explicit tools, backed by JSON schemas, that give an agent a real contract instead of a markup tree to reverse-engineer. I built a small two-agent setup to actually test that contract against real React state, not just read the explainer. Some of it worked cleanly, plain state, simple mutations expose well as tools. Some of it didn't: derived state, Suspense boundaries, and effect-driven updates don't map onto a clean tool definition the way the spec makes it look like they should, and each one needed a different workaround. I'll walk through the real component code, the exact points a tool-based approach broke down, and what I changed to make it work — a grounded account of where WebMCP's tool model holds up under real React state, and where the spec still has real gaps, from someone who's actually built against it rather than just read the explainer.

In this session, we’ll explore why JavaScript’s single-threaded model causes UI lag, why setTimeout() and requestIdleCallback() fail at task prioritization, and how scheduler.postTask() finally gives developers fine-grained control over execution.Through real-world examples, performance analysis, and a live demo, we’ll show how prioritized scheduling can eliminate UI freezes, improve responsiveness, and make JavaScript execution truly user-centric. If you care about JavaScript performance, this is the talk you don’t want to miss! 🚀