I build developer tools and AI-native products. Accessibility is the thing I know best, and it's why the things I build tend to hold up in real use.
Most of my work starts as a rough idea and ends up in front of people. At GitHub, that was an open-source scanner that lives in your CI pipeline, finds problems, opens the issue, and suggests the fix, with Copilot and Actions handling the tedious parts. Then an agentic pipeline on the Models API that reads incoming reports, sorts them against WCAG 2.2, scores severity, and routes each one to the team that owns the code. It teaches as it goes, giving whoever filed the report the context to understand the issue they ran into. What it replaced was essentially a spreadsheet and a great deal of goodwill. Median time to fix went from 126 days to 52.
Before that I built component libraries and design systems, wrote Google's Learn Accessibility (opens in new tab) curriculum on web.dev, created the A11y Style Guide that teams still build on, and started A11yTalks (opens in new tab) – now a hundred-some talks and a few thousand people who keep showing up. I've spent years running usability studies with people who navigate the web using screen readers and voice control, which is where I learned how confidently wrong I could be about my own designs.
I get to new technology early and work out how to use it responsibly, before the defaults harden and someone gets left out. Responsive web, then ARIA when nobody knew how screen readers would handle it, then XR in grad school, where I built AR and VR programs for education and got interested in a specific problem – how to make learning genuinely fun without making it shallow. Now it's LLMs and agents, and the question is the same. The engaging part is the surface. Underneath there's usually a complicated system somebody had to build from scratch. Prototypes are how I get to it – build the rough version, put it in front of people, find out what I was wrong about.
Accessibility has a reputation for making things plainer and safer and duller – the gray box, the skipped animation, the version you ship when the budget for the good version is gone. That has not been my experience. You can build something beautiful and creative and genuinely fun and have it work for everyone. Those have never been competing goals in anything I've built.
I also build small things on purpose. I know the GitHub API and Copilot well, so the interesting exercise was building without that much power underneath – Ask Wookiee and the Oracle of Inclusion are lightweight by design, and they're where I worked out real-time requests and custom instructions on a free model. The Oracle turned out genuinely useful. Ask Wookiee is just fun.
The thread through all of it is the same: build something people can use, ideally something they enjoy using, and don't make anyone the exception. The tools and systems I build tend to teach while they work, because the fix is temporary and the understanding isn't. I want to keep doing that in AI-native products, developer tooling, design systems infrastructure, and agentic workflows – building accessibility in from the start rather than retrofitting it after. The intersection of UX, AI, and accessibility is mostly uncharted, and there aren't many people working across all three. I'm looking for a place to take that further, with more room to build.