Accessibility (a11y) in Zed

[iamnbutler]

Opening up this discussion as a place y'all can leave comments, ideas & thoughts about accessibility in Zed.

A11y (accessibility) in Zed will be a long project. Likely lasting far beyond 1.0. Due to GPUI being written from the ground up we don't have access to the same a11y features that Swift, Web-based apps or [insert other language] does.

Making Zed accessible will be a join effort between things on the Zed side, and building out features in GPUI.

What is helpful to hear from you all:

• Specific places in Zed accessibility can be improved.
• Technologies we might use to speed up the implementation of accessible features.
• Examples of apps and products that do accessibility well.

What isn't helpful to hear:

• "You should have used ___ instead of GPUI." Just don't 🙂
• "X theme is not accessible" – If the theme matches it's appearance in other apps (vscode, Atom) this will not be fixed. If Zed's version does not match those themes, please create an issue and I'll take a look.

[mwcampbell]

A good first step would be to integrate AccessKit into GPUI. Feel free to refer to the AccessKit integration in egui for clarification on how to use AccessKit. Let me know if you need help.

[CurbaiCode]

I was just thinking that a high contrast mode would be good, but one that can be applied to any theme. This would include things like having all buttons, areas, and boxes have outlines; maybe even a higher contrast version of the UI typefaces.

[leopepe]

As a colorblind what helps me in general is having high contrast colours to differentiate the purpose of certain aspects of the UI (options and required to click). In IDEs what is certaily helpful is when the colour schemes contrast green and red, blue and yellow. For instance if the function name colour is in the spectrum of red, the variables will never be a colour in the spetrum of green. (same rule for blue and yellow).

[mikolysz]

Screen reader user here. Considering that Zed is being positioned as not just a simple editor but also a collaboration tool, this should be much more of a priority than it seems to be right now. If a team switches to Zed and requires its members to use it down the line, people who rely on accessibility features will be in serious trouble. This is actively going to make some people's lives worse in a very measurable way.

Considering the amount of effort required here, perhaps building a bridge to make collaboration with Zed users work in other editors (like VS Code for example) could be a stopgap measure for 1.0. VS Code is perfectly accessible already and even has some accessibility support for live collaboration built in, so this would be a good compromise if the team isn't willing to invest the resources required for actual accessibility right now.

[joeldodson]

Another screen reader here (NVDA on Windows 11) and a admitted VS Code fanboy.
It's encouraging this thread exists, but the idea that accessibility might be along term project that goes beyond the 1.0 release is a discouraging perspective. You wouldn't say keyboard navigation is a 1.0 feature, then, implicitly not a consideration in general. Okay, fighting a strawman here, but, to me at least, that's how that comment comes across.
One of the great features of VS Code is their continued active engagement with the blind developer community.
I'm afraid I don't know enough about accessibility APIs, especially outside of Windows, to be helpful technically. I am looking forward though to trying Zed on Windows and hope to engage at a deeper level then.
I read about the features of Zed and think, that sounds awesome, for the average sighted developer. I was sighted for the first 20 years of my career and appreciate all the features mentioned. Now I hear those features and am happy for my sighted colleagues, but if they come at the expense of further isolating my blind colleagues, are they worth it?
I'm not suggesting developer tools be limited so we can use them. That's not constructive for anyone, and I don't think it's necessary. At the very least though, thinking of accessibility as critical as privacy and security, for example, would be a great position. I suspect there must be some features passed over because they couldn't be made secure or lacked privacy. Have any features been passed over because they can't be made accessible? Has any product owner ever even considered that?
I appreciate Iamn's note to keep comments constructive, and I'm trying to not rant here. I am though trying to emphasize how frustrating it is when an entire industry, that's not inherently inaccessible, becomes, at least somewhat, inhospitable to a certain community.
How fast is fast enough? Is shaving off some milliseconds worth it if a product will be inaccessible? I appreciate shaving milliseconds on task repeated thousands of times a day adds up. But can that be done without leveraging the GPU? Again, my lack of technical depth here might be glaringly obvious, maybe try to read this as a meta-point. It sounds like engaging the GPU will make accessibility more difficult. How much speed up do you get by simply using Rust vs Electron? Is that enough speedup to make a difference?
Again, thanks for this thread and at least considering accessibility early in your journey. I hope there will be more, and continuous engagement with blind developers going forward.

[robertmeta]

I think hooks oriented accessibility should be considered. This is the approach used by Emacspeak which is IMHO leaps and bounds above other accessible interfaces. The reason I think this is a good approach is:

1. Allows for intelligent adaptation, because a voice stream is not a visual UI, it is an order of magnitude less data dense.
2. Improves the Zed hooks system as a whole, improving things for sighted and non-sighted users alike.
3. The majority of the code is OS-neutral, because reading a line aloud on mac, windows, linux should read the same, the only thing that needs to change is the reading system.
4. Can leverage existing voice servers written for Emacspeak, which already supports mac and linux and windows support is coming soon. This tracks well with Zed's roadmap.
5. Allows UI and TTS interface to both specialize without being hampered by the other side, as they are extremely different experience. For example, handling notification of an edit on another line by a different user. Emacspeak TTS servers already have the idea of notification streams (goes to one ear if enabled).

So, how does it work? It is extremely simple, here is an example of a possible flow.

1. Zed launched.
2. Zed config contains a "voice server" setting which is a process that is run when Zed starts up
3. Zed sends commands to STDIN of the process, these are simple commands like "tts_say Hello World" would say Hello World to the user.
4. Zed uses the interface to the voice server combined with a series of hooks to handle all TTS interface elements, which means a rich hooks system is required.
5. Build out the hooks one by one. First two hooks might be "line up" and "line down" each sending that entire line to the TTS server and it is evolutionarily grown. Hook to send char movements, hook to send line joins, etc, etc. Piece by piece until done.

This approach has happy side-effects too, like:

1. Contributes to shared servers used by multiple editors
2. As said, makes hooks system in Zed more robust.
3. Once basics are built out, makes it possible for the blind community to do the rest of the development.

[mikolysz]

I don't necessarily disagree, but here are a couple important things to note.

1. This solves one use case (screen readers), while integration with native accessibility APIs (e.g. via Accesskit) solves them all. Voice recognition is one notable use case that also relies on accessibility APIs but wouldn't be solved by a hooks system, and there are probably others.
2. I don't think you could do Braille display support this way, or at least not without a lot of pain, and this is something that's very important and a non-starter to many users. Braille displays are usually under exclusive control of the currently running screen reader, and most screen readers don't expose good APIs to manage them. Braille displays aren't just for output, they also let the user move between lines, jump to a specific character with a physical button located above that character's Braille cell etc. If we treat screen readers as dumb programs that should speak what they're told to, instead of giving them full semantic information about the UI, that has no chance of working.
3. Screen readers have specific shortcuts to read specific pieces of information, like "say current word" or "read continuously from the cursor to end of file". If screen readers aren't given the full contents of the document, those shortcuts aren't going to work. This will pollute Zed's keymap with a lot of accessibility-specific commands that users will have to re-learn instead of just using the shortcuts they already know and are used to.
4. Platform conventions. Every platform and every screen reader calls things slightly differently, has a different way of navigating the screen, speaks according to the user's settings, in the voice of the user's choosing, with its own punctuation scheme etc. Trying to replicate this would require a massive amount of work. You could just give up and do things "the Zed way" everywhere, but then you'd have to expose all of these settings in Zed itself.

You should also keep in mind that you'd need hooks for every single thing the editor lets you do, including navigating non-editor UI controls, the entire settings panel, menus, file switching etc. You'd also have to either build in a "micro screen-reader" that would allow reading the static, non-keyboard-navigable elements of the UI, like the current line number, or expose separate keyboard commands for all of them.

Google Docs tried this approach, because web accessibility standards just weren't good enough to implement accessibility for a complex, WYSIWYG rich text editor at the time, and it caused them so much trouble that they had to do a separate accessibility implementation called "Braille mode" that actually does things properly.

[robertmeta]

@mikolysz great points.

This solves one use case (screen readers)...

Didn't mean to imply it was an "instead of" more of a possible route that is slightly easier on the main editor widget implementation, which right now seems to be a black hole. Didn't mean to imply a "don't implement proper accessibility APIs".

I don't think you could do Braille display support this...

Correct, at least on Mac you couldn't.

Screen readers have specific shortcuts to read specific pieces of information...

True, but an advanced editor has many movements and editor tooling that are well beyond the primitives provided by the OS editing capacity. This is one of the major features of this appraoch being able to handle things that do not exist in the OS primitives. Multi-user editing events, complex editor operations (multiline join maybe, multiple cursors, etc), this is one of the use cases I specifically was thinking about.

Platform conventions. Every platform and every screen reader calls things slightly differently, has a different way of navigating the screen, speaks according to the user's settings, in the voice of the user's choosing, with its own punctuation scheme etc. Trying to replicate this would require a massive amount of work. You could just give up and do things "the Zed way" everywhere, but then you'd have to expose all of these settings in Zed itself.

Well, it is work for sure, I wrote the Swiftmac server that does exactly this for Emacspeak (not the bindings, but voice, punctuation, rate, etc). This allows a set of features for heavy text editing and syntax highlighting that translates to voices. From tone changes to complete voice changes for syntax highlighted elements, even rate changes if you want numbers read slower, etc. But you are absolutely right, this is very much making "the Zed way", which seems almost a foregone conclusion when Zed supports text editing primitives and modes (collaboration) that the OS doesn't so the basic text editor won't.

You should also keep in mind that you'd need hooks for every single thing the editor lets you do, including navigating non-editor UI controls, the entire settings panel, menus, file switching etc. You'd also have to either build in a "micro screen-reader" that would allow reading the static, non-keyboard-navigable elements of the UI, like the current line number, or expose separate keyboard commands for all of them.

Yep, but many things very useful for developers on Mac and Linux are not easily exposed via the screen readers. Windows is far better in this regard. For example, there is no feature that I am aware of on MacOS to get the current line number. I believe VoiceOver simply does not have this. Because screenreaders provide basic primitives there are rather huge gaps for heavy text editing. So either the user with a screen reader doesn't get the feature or you add in support. Line numbers are fairly basic, more advanced stuff is even less supported... and even line numbers I believe on MacOS is missing.

Google Docs tried this approach, because web accessibility standards just weren't good enough to implement accessibility for a complex, WYSIWYG rich text editor at the time, and it caused them so much trouble that they had to do a separate accessibility implementation called "Braille mode" that actually does things properly.

... indeed, I basically gave up on Google Docs because of it, I will have to revisit it. TIL.

---

Again, a lot of great points and this was never a instead of just something that might have value in addition to and depending on the level of hooks could have a lower implementation cost.

[sempruijs]

I myself am a screen reader user. Currently I only found one editor that is accesible and implements vim and that is emacspeak. Would love to see accessible vim for zed.