A poll for all #blind #VoiceOver #Mac users out there who do coding. Which code editor are you using? Boost OK for further reach...
Visual Studio Code
44.4%
Panics Nova
8.9%
TextMate
5.6%
Other, see comment
41.1%
Poll ended at .
@marco have you tried https://zed.dev/ (overlook the AI hype)? I wonder how it fairs for blind users, as a new, cross-platform product.
Zed — Love your editor again

Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.

Zed
@bntn @marco Zed is completely inaccessible for now because it uses GPU rendering instead of native controls.

@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.

@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.

@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.

@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.

@miki Thank you for the explanations, Mikołaj.
@miki Also, I wonder if this highlights the feat that @mitchellh has done with Ghostty, using native controls on different platforms. I hope that means Ghostty is able to support accessibility!
@bntn @miki Its still a challenge, but yes, we plan on doing AX support. We have a discussion about it and a solid roadmap (though, not assigned to any version). Our AX support will be macOS-only though, because the availability of accessibilty APIs for graphical Linux applications is abysmal.

@mitchellh Glad to hear it is being addressed on macOS, and sad to hear the situation on Linux. I think I’ve seen @aral raising a stink over accessibility limitations over there.

Please prioritize shipping these 🙏🏻

@bntn @mitchellh Yeah, I’m back to using a Mac as my daily driver after six years on Linux because of this.

This was the last straw: https://ar.al/2024/06/23/fedora-has-been-shipping-with-a-broken-screen-reader-for-nine-years-but-the-real-problem-is-me/

Fedora has been shipping with a broken screen reader for nine years but the real problem is me

Fedora has an ableism problem but woe to you if you point it out.

Aral Balkan