Hitting the Wall
For most of my career, I’ve hit the same wall. I’d have an idea for a tool, a workflow, and a better way to test something. I’d write it up: requirements docs, slide decks, and detailed explanations of the logic. Then I’d hand it to an engineering team and hope they saw what I saw.
I’m not a developer. I’m a subject matter expert. I’ve spent over thirteen years working on accessibility: auditing, testing, training, and developing programs. I know about assistive technologies. I have an encyclopedic knowledge of the WCAG. But when it came to building my own tools? That required skills I didn’t have. So, ideas stayed on paper, dependent on someone else to bring them to life for me.
The Breakthrough
Earlier this year, I was building an accessibility training for content authors at Adobe. These are people working in a content management system on marketing pages. They can only affect what’s inside the <main> element of the page, the section that holds the primary content. They can’t touch the <header> or <footer>, which are defined in templates outside their control. So, I scoped the training tightly: alt text, link text, headings, tables, color contrast, captions. The things they could actually change.
As I built the link text lesson, I kept thinking about what happens after training. I’d show them a common problem: three card components with “Open” links that a screen reader announces as “Open, Open, Open.” I’d explain how to fix it. But when they went back to their desks, they’d be on their own. The major automated testing tools wouldn’t catch this. Axe wouldn’t. WAVE might give an alert.
So, I decided this time to build my own tool based on my own knowledge, analyzing Jira tickets and interviewing the team to understand the extent of the problem in their unique environment.
Using Cursor AI, I created a bookmarklet with a graphical interface. It analyzes links inside <main> only, because that’s their scope. It flags the specific issues I taught them about: identical link text pointing to different destinations, ARIA labels that don’t start with visible text, and links that rely on color alone without underlines. It gives them the error, the reason, and a suggestion for fixing it. Not generic guidance, but specific answers for their environment, referencing their component names and CSS classes.
I am not claiming I became a developer overnight. But I built a working tool that embodies my subject matter expertise in a way a requirements document never could.
The Handoff
Here’s what changed about working with engineering. The development team for Adobe.com saw my tool and asked if they could have it. What I handed them wasn’t a pitch deck. It was a working prototype, documented logic, and code snippets they could leverage in their own development. They effectively translated my thirteen years of expertise into something they could tangibly see and use.
That’s a different conversation than “here’s a concept I hope you’ll prioritize.”
The Big Win
I don’t think I’m unique. Accessibility practitioners across the field have deep expertise and years of great ideas that never made it past paper. In 2026, I believe that access to AI tools will have lowered the barrier between knowing what should exist and actually making it exist.
We’re not all becoming engineers. But we’re becoming better collaborators, showing up with working examples alongside documented requirements. The gap between idea and implementation is shrinking.
And that benefits the people we’re ultimately serving: individuals with disabilities seeking equitable online experiences. When practitioners can prototype their own solutions, feedback loops tighten. Tools get built by the people who understand the problems most deeply. Better tools, faster.
The future of accessibility isn’t waiting for resources to align; you can begin building tools that fill gaps you observe in the field. It’s you building the tool first and then having those resources come into alignment based on the value you show up with.
