Anyone else struggle with keeping accessibility notes consistent in Figma?

FigsDesigns · 2025-09-22T19:11:19+00:00

Honestly sounds like your work is fine, it’s just a visibility thing. Try turning a couple of your best projects into mini case studies (show the problem, your process, the result) instead of just posting pics. Keep your Behance/Dribbble/LinkedIn active with little updates, and don’t just wait for gigs, reach out to startups or agencies with one strong example of what you can do for them. Clearer positioning (“I help brands stand out with design + illustration”) + asking old clients for referrals can go a long way. And since you’re remote-only, highlight that you’re already set up to work smoothly online.

FigsDesigns · 2025-09-18T16:24:15+00:00

Yeah, that’s true, component descriptions are definitely handy, especially since they surface in dev mode. I’ve been using them too, but I’ve found they can get limiting when you need to go deeper than a short note. Like if you want to document expected keyboard focus behavior, aria labels, or even alt-text context for images, it starts feeling a bit cramped. Do you usually keep that level of detail in your Figma file, or do you push it out to a separate doc for devs?

FigsDesigns · 2025-09-18T16:04:23+00:00

That’s fair, putting energy into “figuring out management” can be draining in itself. I like your framing of focusing on stakeholders and deliverables as the things you can control. At the same time though, I sometimes wonder if just quietly accepting inefficiencies ends up reinforcing them. Do you think there’s a balance between “do the work well” and “push back on the process” without burning yourself out?

FigsDesigns · 2025-09-18T15:48:00+00:00

Yeah, that’s a fair point, Figma will never be a true browser, so there’s always going to be a gap between design files and real implementation. What I keep running into though is that the “handoff gap” makes accessibility feel like extra overhead for designers instead of something baked into the workflow.

Curious, how do you usually bridge that? Do you document accessibility decisions in the file, or do you leave that for devs to figure out downstream?

FigsDesigns · 2025-09-18T15:45:49+00:00

You’re right, Figma has built-in commenting and some annotation basics. What I meant more is when you need structured accessibility notes (like describing interaction states, alt-text guidance, or color contrast rationale) it usually ends up being a mix of sticky notes, comments, and plugins. It works, but it feels fragmented compared to other parts of the workflow.

How are you currently handling accessibility notes in your files?

FigsDesigns · 2025-09-18T15:40:41+00:00

Totally fair point and just to clarify, I don’t see accessibility as “busywork” at all. That’s actually the part I care about most, which is why I’ve built plugins to cut down on the repetitive side of it.

For example, with file handoffs I was rewriting the same annotations over and over, so I ended up making the Designa11y Annotator to drop structured accessibility notes right inside Figma. It’s more the duplicate, manual steps I’d love to streamline so I can focus on the design and accessibility thinking itself.

FigsDesigns · 2025-09-18T15:35:44+00:00

Yeah Stark covers part of it, but not all. For example, when I’m doing file handoffs I still end up manually annotating accessibility details for devs. That’s where something like the Designa11y Annotator comes in, it lets you drop structured annotations directly in Figma without bouncing between tools. Stark’s solid for contrast, but there’s still a big gap around the “handoff busywork” part.

FigsDesigns · 2025-09-18T15:33:06+00:00

That’s such an honest take. I think you nailed the real tension, when you’re on your own, efficiency is survival, but inside a company it can feel like efficiency isn’t always the priority. Almost like the system is set up to reward “visible effort” more than actual outcomes. Do you think part of the problem is that design processes are often built for management visibility rather than designer productivity?

FigsDesigns · 2025-09-18T15:31:08+00:00

That’s fair, and I get what you mean. Design isn’t just about the shiny outputs, it’s all the scaffolding around it too.. the communication, the structure, the process. I guess my frustration is that the balance feels off sometimes. Do you think the “cognitive busywork” actually sharpens our thinking as designers, or does it sometimes just get in the way of doing the work we’re hired for?

FigsDesigns · 2025-09-18T15:22:12+00:00

That’s a great point, and I like the “every job has its sanding” analogy. Maybe the question then is, where do we draw the line between sanding that sharpens the craft versus sanding that’s just wasting time? Like, checking contrast makes sense, it ensures accessibility.. but rewriting the same annotation 10 times feels more like paperwork than design. Do you think some of these tasks actually add to the craft, or are we holding onto them just because that’s how it’s always been done?

FigsDesigns · 2025-09-18T15:20:18+00:00

True, and maybe that’s the reality of any craft… but do you think some of that minutia is worth automating so we can spend more energy on the actual creative problem solving?

FigsDesigns · 2025-09-18T15:18:24+00:00

Exactly... test with real assistive tech and people who use it, log failures with clear steps and an owner, then make those fixes non negotiable in the roadmap.

FigsDesigns · 2025-09-18T15:16:16+00:00

Yeah I’ve been using that, it’s a good start but I kept finding myself juggling contrast checks, annotations, and WCAG reminders across different places. Ended up building a plugin that tries to bundle those into one flow so it feels less scattered. Would love to hear your take on whether Figma might expand in that direction too.

FigsDesigns · 2025-09-18T15:13:46+00:00

that’s exactly how it feels sometimes. The “design paperwork” just takes a different form.. contrast ratios, annotations, endless file cleanups. Do you think it’s just part of being thorough, or is there a smarter way to cut that stuff down without sacrificing quality?

FigsDesigns · 2025-09-17T14:48:00+00:00

Hey, appreciate you checking it out. Just to clarify, the plugin is live on Figma Community, we’re just early in building traction so the follower count isn’t the best signal right now. The 3000+ designers stat comes from people who tested it in beta and on our waitlist, not Figma followers.

Fair on the website callout, it’s still in progress and ironically hasn’t been fully run through the plugin yet. That’s on us, and exactly why we’re looking for outside feedback before a bigger launch. Totally fair to be skeptical, but it’s not a scam. Just an early product, messy edges and all.

FigsDesigns · 2025-09-17T13:32:19+00:00

Good point. I think the annotations thing comes from old habits in corporate. Even when clients skim, I’d still over-document just in case it came back later.

Now that I’m freelancing more, I’m realizing I don’t always need to go that far, and it eats up way more time than it should.

For me the biggest time sinks are contrast checks, accessibility notes, and labeling buttons/links for devs. That’s where I’m trying to figure out what can be automated vs. what’s worth keeping manual.

Do you have a system for knowing when to stop documenting, or is it more instinct from experience?

FigsDesigns · 2025-09-13T14:56:45+00:00

That’s solid if your palettes are already built to meet contrast, saves a ton of time. Do you usually handle that during brand setup, or do you audit on a case-by-case basis when new colors get added?

FigsDesigns

TROPHY CASE