A11ySidekick: An accessibility sidekick for designers

Every time I nerded out about accessibility at design conferences, someone would inevitably ask me: but how do I actually create accessible designs?

And I get it. Handing a designer 55 technically-written WCAG 2.2 AA success criteria and asking them to figure out which ones apply to the ten screens they're working on is not guidance, that's a research project.

That's when it hit me: the problem wasn't that designers weren't using WCAG because they didn't care, it's that they just couldn't. Success criteria for accessibility wasn't accessible to the very designers who were meant to use it.

So I asked myself a few questions.

Can the criteria be simplified? WCAG is written for legal and technical precision. Useful in a compliance audit. Not useful when a designer is mid-flow in Figma. Could I rewrite each criterion in plain language, something you could read, understand, and act on in thirty seconds?

Who actually owns what? Not every criterion is a designer's problem. Some things you handle in a mockup. Some things need a handoff note for the engineer. Some things the engineer handles entirely. If I could split the criteria into those buckets, a designer could stop worrying about the parts that aren't theirs.

Can I filter by what's on the screen? WCAG is organised by the POUR framework: Perceivable, Operable, Understandable, Robust. That's a useful mental model but a terrible working model. A designer looking at a screen with no forms doesn't need the ten criteria about form inputs. What if the criteria surfaced based on what's actually on the screen?

I had three buckets in my head. That's when I brought Claude in, which already had a lot of context on my accessibility work, to help me process through the criteria and stress-test the logic.

While mapping responsibilities, it became obvious that a chunk of criteria had nothing to do with design and nothing to do with engineering either. Things like reading level, plain language in error messages, alt text for images, captions for video, transcripts for audio: none of that can be fixed in a mockup or a pull request. It requires a human to author meaning, and whoever owns that on your team, whether that's a writer, a product manager, a marketer, or the designer themselves, that's who this belongs to. So the responsibility map ended up with four buckets, not three:

1. Design — things you can handle directly in your mockups
2. Design → Dev — things you design and then document for the engineer
3. Dev Only — things the engineer handles without needing input from you
4. Content — everything that requires a human to author meaning: words, captions, alt text, descriptions, transcripts. Whoever owns that on your team owns this.

The same kind of clarity showed up with the element-filtering logic. My original hypothesis was that every criterion connects to something on the page, so why not filter by element? But working through it surfaced a problem: a sticky header isn't an element you place, it's a structural decision about how the screen is built. That distinction ended up producing a three-layer model:

1. Always On — 7 criteria that apply to every screen, no matter what
2. Screen Structure — criteria triggered by how the screen is built (sticky elements, overlays, timeouts, navigation)
3. Elements — criteria triggered by what you actually place on the screen

Instead of 55 criteria staring back at you, you get maybe 14 that actually apply to what you're designing right now.

The full journey looked like this:

• Simplification answered: what does this criterion actually mean?
• Responsibility mapping answered: whose job is this?
• Contextual filtering answered: which criteria even apply to my screen?

Each step made the thing more useful by answering a more specific question.

Once the thinking was solid, my original instinct was to bring this knowledge as close to the designer as possible, right inside Figma, where they're actually working. But before jumping into the complexities of a plugin, I wanted to see the thing come to life first.

That's when I decided to build it as a web app. I asked Claude Chat to generate a full specification, detailed enough to hand directly to Claude Code, and built A11ySidekick from there.

The result is exactly what I had imagined: two modes. A Screen Checklist where you name your screen, select its structure and elements, and get a filtered list of exactly what applies. And a Full Reference where you can browse all 55 criteria by role.

One honest caveat before you use it: while all of this was worked out with Claude's help, I haven't gone through and validated every simplified criterion one by one. That's not a flaw in the logic, it's just something that'll happen in practice, as my team and I start using this as part of our daily design work. Think of it as a living document, not a finished one.

This is version one. The Figma plugin is still ahead. But I wanted to share where the thinking came from before moving ahead, because the logic behind the tool is more interesting than the tool itself right now.

Give it a try: A11ySidekick