@miki @marco Ah, so it’s because the controls are being rendered inside the “sandbox” of a graphical output instead of native system controls being used? (Sorry for the layperson speak)

That’s disappointing, and seems like a big software design hurdle to shift from now, if they decide to do the right thing and support accessibility.

Feb 13 *

**Mikołaj Hołysz** @miki · Feb 13

Mikołaj Hołysz @miki

@bntn @marco Yeah, Zed is basically telling the system something like "render these pixels, of this color, at these coordinates", not "here's a button, put it inside this window."

This is a massive oversimplification, it uses GPU acceleration a lot, which means a lot of that info isn't even calculated by the ap, but directly by the GPU.

Screen readers are a bit of a misnomer, they don't actually read the screen, they need the to get the semantic info about what controls are present from the system. If all the system knows about is pixels, then all the blind person sees is a blank window.

Feb 13

**M@ Bntn** @bntn@mastodon.social · Feb 13

M@ Bntn @bntn@mastodon.social

@miki I’m a front-end dev, so this makes perfect sense to me. It’s like using real web controls vs displaying a UI in a canvas element.

Feb 13

Mikołaj Hołysz @miki@dragonscave.space

@bntn Yes exactly.

Putting your UI in a canvas would produce the exact same result, total and utter inaccessibility on your page.

There's a way around it, you can create a fake accessibility tree that reflects your app's understanding of what controls actually are on the screen. This is what web browsers do, for example, along with third-party GUI toolkits like QT or Java.

The web dev equivalent of that would be a completely unstyled, visually hidden model of the UI in the DOM, created only if there is a screen reader running, that reflects what's displayed on the canvas. Google DOCs's Braille Mode uses this trick to make Docs accessible.

Feb 13, 2025, 02:55 PM··TweeseCake

0boosts·1favorite