6 ms·

Their custom UI framework might be all fun and games for now, but that will probably change once they realize they need to implement accessibility. Doing this i

Their custom UI framework might be all fun and games for now, but that will probably change once they realize they need to implement accessibility. Doing this in a custom framework without sacrificing performance won't be easy and is going to require lots of messy, per-platform work. It's not like it's optional for them either. It would be for a simple editor that you can just decide not to use, but they're positioning Zed as a collaboration tool, so making sure that everybody on a given dev team can use it is going to be crucial. I wish developers finally learned this lesson. As a screen reader user, I'm sick of all these "modern" tools written in Rust (and yes, it's nearly always Rust) where Voice Over just sees an empty window. It's far easier to dig yourself out of the trap of no accessibility if all you need to do is to slap a few aria labels on your buttons and sort out some focus issues than when you need to expose every single control to every single OS. At least there's AccessKit[1] now, which might make the work a bit easier, though I'm not sure how suitable it is for something as big as an editor. [1] https://accesskit.dev/ https://accesskit.dev/

Klonoar 3y ago
[flagged]
- nindalf 3y ago
  They’ve only spent 10 years writing text editors. They might not have heard of accessibility before. /s
  - miki123211 3y ago
    To be honest, the previous editor they've worked on was Atom, and they didn't care then either, even though their job would be much easier. It's definitely in the realm of possibility that they have next to no accessibility experience.
- deleted 3y ago
  [deleted]
- kaashif 3y ago
  I think it's likely they have. But is there anything specific where they've written or spoken about Zed and accessibility?
  - Jtsummers 3y ago
    I just posted a quote from this page: https://zed.dev/docs/themes https://zed.dev/docs/themes They've thought about it, and have a "follow this link to discuss" that links to the wrong thing so you can't actually follow the link to discuss it. Unless you're interested in a closed issue regarding back and forward buttons.
- miki123211 3y ago
  From the current state of things, which to Voice Over is an empty window with no elements whatsoever, if they have thought about accessibility, they definitely don't consider it a priority. With such a monumental task, I'd be willing to excuse some slip-ups, but there was literally zero work put into this.
  - Klonoar 3y ago
    Saying “zero work out into this” and noting they didn’t prioritize it is different from implying they’re naive and unaware of how complex and intricate Accessibility can be. I’m not actually interested in whether they support it or not - I just think your comment is a poor and/or lazy attempt at dunking on them. It contributes to this site being less interesting discussion and turning it into /. 3.0. (For what it’s worth, if I was building a next gen (attempt) at developer tooling, I would punt on Accessibility at the start as well. It sucks, but that’s such a smaller segment of the market that you don’t _need_ to serve immediately. It only matters that you eventually get there.)
    - codetrotter 3y ago
      Also, even if they did use native widgets that come with integrated accessibility features, would those actually work as intended for a multi user collaborative editor like Zed? Imagine a group of four people live collaborating on a file in Zed. How do you present the actions that are being taken by everyone so that a screen reader can understand what is going on? Mute everyone except the user? Speak every keystroke pressed by everyone all of the time? Announce line changes made by others when they pause for a while / when they move to another line? In short, I think if accessibility for screen readers were to happen for Zed it would take a monumental amount of effort to make it usable, regardless of whether they are using native widgets or not.
- cmrdporcupine 3y ago
  You would not believe the hubris of our profession in general around "how hard can writing a GUI toolkit be?" and also how little most engineers seem to think about accessibility when scheduling and estimating and architecting. Backdrop: helped ship accessibility features onto the Google "Nest" Home Hub, somewhat last minute. And then watched it all get re-written for Fuchsia w/ Flutter (which of course had no accessibility story yet) and, yeah, last minute again.
  - Klonoar 3y ago
    No, I’m aware of how people downplay the scope involved in building a GUI framework. I’ve written your comment no less than (I estimate) 10 times on this very site. I give these devs the benefit of the doubt given their prior body of work.
Jtsummers 3y ago
Here's their only blurb on accessibility: > Currently, many of Zed's themes are largely inaccessible. We are working on a new accessible theme system, which will launch with Zed 1.0 > 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 joint effort between things on the Zed side, and building out features in GPUI. > For now, you can join this discussion to talk further about a11y in Zed: Accessibility (a11y) in Zed [links to: https://github.com/zed-industries/zed/pull/1297 https://github.com/zed-industries/zed/pull/1297] And that link is useless, it goes to a Github issue about back and forward buttons. https://zed.dev/docs/themes https://zed.dev/docs/themes https://github.com/zed-industries/zed/pull/1297 https://github.com/zed-industries/zed/pull/1297 - the link they use that's supposed to be for accessibility discussions. It appears it's supposed to be a link to this: https://github.com/zed-industries/zed/discussions/6576 https://github.com/zed-industries/zed/discussions/6576 So they've thought about it, but they haven't actually done it yet.
- sangnoir 3y ago
  > So they've thought about it, but they haven't actually done it yet. In my experience, a11y shouldn't be an afterthought but baked-in from the beginning. Doing the latter results in hacky, harder-to-maintain code.
  - cmrdporcupine 3y ago
    100% this. If you think about it, doing accessibility right -- in particular screen reader work -- requires thinking very carefully about the data model behind the presentation. What you need to declare and when. And doing that thinking actually could force engineers into building UI frameworks that not only are accessible for the visually or auditory impaired, but for broader systems as a whole. It's hard work that has to get done, but it's not particularly sexy.
    - logicprog 3y ago
notso411 3y ago
Why bother with accessibility. If a disabled wants to use an IDE, use a different one??
- mplewis 3y ago
  Accessibility helps all users, not just disabled users.
  - pimlottc 3y ago
    Which is to say, we are all (temporarily, situationally, eventually) disabled in some way
    - fanf2 3y ago
      I have most commonly heard this phrased as, we are all temporarily able-bodied.
  - tonis2 3y ago
    Which accessibility features are you most commonly using ? Just wondering, what are the most used accessibility features, that new GUI-s don't have.
    - notso411 3y ago
      Getting ratioed because people think “my app must follow accessibility for… oh.. uh… because big company does so we must do same ooga booga smoothbrain incapable of critical thinking” Waste of time unless you are aiming your application AT people who use screen readers e.g. medical or public sector. EVEN THEN has anyone actually tried? Even accessible websites are garbage.
      - dieortin 3y ago
        This is not Twitter
    - mikojan 3y ago
Szpadel 3y ago
I'm not surprised that most of rust guis are not a11y friendly, there is no established gui library yet, none of them I would call mature yet Not long ago there weren't any gui libraries that wouldn't be just binding to existing C framework or was in proof of concept state of lifecycle I'm sure this situation will improve in the future and I understand frustration of someone that rely on a11y features, but you need to understand that everyone first will try to achieve solid gui library before will start adding accessable functionality
- yoyohello13 3y ago
  System76 is making headway getting a11y accessibility for Cosmic Desktop. They are doing a lot of good work in the Rust gui space.
  - Szpadel 3y ago
    Agree, I think they might shape first mainstream rust gui library. They are doing amazing job with whole desktop environment. I'm yet to check first hand their work, but so far looks very promising
CharlesW 3y ago
> I wish developers finally learned this lesson. From a product perspective, re-inventing the wheel for something that — at best, many years from now — will be at parity with native presentation layers in terms of performance, a11y support, user experience, etc. is normally considered a risky move. Many startups have failed in part from pouring resources into shiny non-differentiators. The only examples of successful products that use non-native UIs either (1) leverage web technologies or mature frameworks like Qt, or (2) are Blender (age 30). Apple did this with iTunes, but iTunes felt unpleasant on Windows, and people used iTunes for Windows in spite of this. I understand the appeal of creating frameworks like GPUI, but the article doesn't explain the relationship to the problem Zed is trying to solve.
- miki123211 3y ago
  There's also Zoom, which apparently uses an internal, heavily-modified fork of some Chinese UI framework on Windows (and QT on everything else). They did go the extra mile and add accessibility support though, their American clients, particularly the ones in government, healthcare and education, didn't really give them any other option. There's also Google Docs, which uses weird tricks instead of rendering straight to DOM. They didn't even bother implementing accessibility in that layer, something which would probably have been impossible back then. Instead, they offer an accessibility mode and mark their entire UI as hidden to assistive technologies. When the accessibility mode is on, all speech is generated by a micro screen reader implemented in Google Docs directly, and the generated messages are sent as text to be spoken by your real screen reader. This is an ugly hack that doesn't really support braille displays very well, so they later implemented yet another layer of ugly hacks that retrofits the document on top of an actual DOM. Your point still stands though, these are exceptions that prove the rule.
  - CharlesW 3y ago
    Interesting, thanks! It looks like Figma (a clear success) also took the "just give me a canvas" route: "Pulling this off was really hard; we’ve basically ended up building a browser inside a browser. […] Instead of attempting to get one of these to work, we implemented everything from scratch using WebGL. Our renderer is a highly-optimized tile-based engine with support for masking, blurring, dithered gradients, blend modes, nested layer opacity, and more. All rendering is done on the GPU and is fully anti-aliased. Internally our code looks a lot like a browser inside a browser; we have our own DOM, our own compositor, our own text layout engine, and we’re thinking about adding a render tree just like the one browsers use to render HTML." https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/ https://www.figma.com/blog/building-a-professional-design-to... The value proposition of a "boil the ocean" approach to UX frameworks is clearer for browser-based apps than native apps. That said, 7 years in, Figma apparently has a long way to go: "To repeat a familiar refrain: We still have a lot of work to do! As we continue to improve access to our own products, we’re also advancing our understanding of what our users need to design accessibly." https://www.figma.com/blog/announcing-figjam-screen-reader-support/ https://www.figma.com/blog/announcing-figjam-screen-reader-s...
pmarreck 3y ago
Honest question out of curiosity- Are there possibly AI-based solutions possible that can add assistance at a more generic level that doesn't require software that has "deep" knowledge of the window architecture (and the actual text in it etc.)? My understanding is that this is how tech like VoiceOver works- it knows the actual window definition and all the elements of it at a programmatic level and can take advantage of that. I'm not asking if they're already available (although that would be a nice option), but for projects like this that wanted the speed of rendering on the GPU (at the possible cost of, as you said, VoiceOver seeing an "empty window"), it would be at least a fallback position. (So does this mean that ALL content that renders through the GPU, such as games, are inaccessible to you? If so, I'm sorry...) Not sure if this might help you but I have an Apple shortcut defined on my iPhone called "GPT Explains" that is activated by a double-tap on the back of the phone (which you can assign, as you probably know, in Accessibility settings)- it takes a screenshot, ships it off to OpenAI and returns with a description of what it's seeing, any to-English translation of non-English text, and any counterarguments to any claims made in a meme, etc. (yeah, the prompt for this is kinda wicked, lol). If this is helpful to you, I can give you a link after I remove my OpenAI key (you'd have to provide your own). EDIT: I made a copy of it without the API key: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f692776b https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
- miki123211 3y ago
  iOS already has such a feature, but it's obviously not 100% accurate, not real time, and not great for battery life. It's good enough if you have to click a broken "I accept your terms and conditions" checkbox, but nowhere near good enough to daily drive your phone with. In other words, a band-aid solution for when everything else fails, mostly for situations where the app you're trying to use is mostly usable, but has an accessibility barrier preventing you from carrying out a crucial step somewhere. There's also vocr on Mac (and equivalent solutions on Windows), which recently got some AI features, but it doesn't even recognize control types (a very basic feature of any screen reader), just text. Again, good enough to get you through most installers where all you're doing is clicking "next" ten times, probably good enough to get you through the first-run experience in a VM that doesn't yet have a screen reader installed, at one tenth the speed of a sighted person, but that's about it.
nojvek 3y ago
Don’t want to downplay the concern. With modern machine learning is there an opportunity to build a better accessibility tool? Something that works on any set of pixels and sees like a human does? I.e parses text with OCR.
- KTibow 3y ago
  That would be useful if the normal way fails but would always be slower and not as accurate than intentionally implemented accessibility

Klonoar 3y ago

[flagged]

nindalf 3y ago
They’ve only spent 10 years writing text editors. They might not have heard of accessibility before. /s
- miki123211 3y ago
  To be honest, the previous editor they've worked on was Atom, and they didn't care then either, even though their job would be much easier. It's definitely in the realm of possibility that they have next to no accessibility experience.
deleted 3y ago
[deleted]
kaashif 3y ago
I think it's likely they have. But is there anything specific where they've written or spoken about Zed and accessibility?
- Jtsummers 3y ago
  I just posted a quote from this page: https://zed.dev/docs/themes https://zed.dev/docs/themes They've thought about it, and have a "follow this link to discuss" that links to the wrong thing so you can't actually follow the link to discuss it. Unless you're interested in a closed issue regarding back and forward buttons.
miki123211 3y ago
From the current state of things, which to Voice Over is an empty window with no elements whatsoever, if they have thought about accessibility, they definitely don't consider it a priority. With such a monumental task, I'd be willing to excuse some slip-ups, but there was literally zero work put into this.
- Klonoar 3y ago
  Saying “zero work out into this” and noting they didn’t prioritize it is different from implying they’re naive and unaware of how complex and intricate Accessibility can be. I’m not actually interested in whether they support it or not - I just think your comment is a poor and/or lazy attempt at dunking on them. It contributes to this site being less interesting discussion and turning it into /. 3.0. (For what it’s worth, if I was building a next gen (attempt) at developer tooling, I would punt on Accessibility at the start as well. It sucks, but that’s such a smaller segment of the market that you don’t _need_ to serve immediately. It only matters that you eventually get there.)
  - codetrotter 3y ago
    Also, even if they did use native widgets that come with integrated accessibility features, would those actually work as intended for a multi user collaborative editor like Zed? Imagine a group of four people live collaborating on a file in Zed. How do you present the actions that are being taken by everyone so that a screen reader can understand what is going on? Mute everyone except the user? Speak every keystroke pressed by everyone all of the time? Announce line changes made by others when they pause for a while / when they move to another line? In short, I think if accessibility for screen readers were to happen for Zed it would take a monumental amount of effort to make it usable, regardless of whether they are using native widgets or not.
cmrdporcupine 3y ago
You would not believe the hubris of our profession in general around "how hard can writing a GUI toolkit be?" and also how little most engineers seem to think about accessibility when scheduling and estimating and architecting. Backdrop: helped ship accessibility features onto the Google "Nest" Home Hub, somewhat last minute. And then watched it all get re-written for Fuchsia w/ Flutter (which of course had no accessibility story yet) and, yeah, last minute again.
- Klonoar 3y ago
  No, I’m aware of how people downplay the scope involved in building a GUI framework. I’ve written your comment no less than (I estimate) 10 times on this very site. I give these devs the benefit of the doubt given their prior body of work.

Jtsummers 3y ago

Here's their only blurb on accessibility: > Currently, many of Zed's themes are largely inaccessible. We are working on a new accessible theme system, which will launch with Zed 1.0 > 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 joint effort between things on the Zed side, and building out features in GPUI. > For now, you can join this discussion to talk further about a11y in Zed: Accessibility (a11y) in Zed [links to: https://github.com/zed-industries/zed/pull/1297 https://github.com/zed-industries/zed/pull/1297] And that link is useless, it goes to a Github issue about back and forward buttons. https://zed.dev/docs/themes https://zed.dev/docs/themes https://github.com/zed-industries/zed/pull/1297 https://github.com/zed-industries/zed/pull/1297 - the link they use that's supposed to be for accessibility discussions. It appears it's supposed to be a link to this: https://github.com/zed-industries/zed/discussions/6576 https://github.com/zed-industries/zed/discussions/6576 So they've thought about it, but they haven't actually done it yet.

sangnoir 3y ago
> So they've thought about it, but they haven't actually done it yet. In my experience, a11y shouldn't be an afterthought but baked-in from the beginning. Doing the latter results in hacky, harder-to-maintain code.
- cmrdporcupine 3y ago
  100% this. If you think about it, doing accessibility right -- in particular screen reader work -- requires thinking very carefully about the data model behind the presentation. What you need to declare and when. And doing that thinking actually could force engineers into building UI frameworks that not only are accessible for the visually or auditory impaired, but for broader systems as a whole. It's hard work that has to get done, but it's not particularly sexy.
  - logicprog 3y ago

notso411 3y ago

Why bother with accessibility. If a disabled wants to use an IDE, use a different one??

mplewis 3y ago
Accessibility helps all users, not just disabled users.
- pimlottc 3y ago
  Which is to say, we are all (temporarily, situationally, eventually) disabled in some way
  - fanf2 3y ago
    I have most commonly heard this phrased as, we are all temporarily able-bodied.
- tonis2 3y ago
  Which accessibility features are you most commonly using ? Just wondering, what are the most used accessibility features, that new GUI-s don't have.
  - notso411 3y ago
    Getting ratioed because people think “my app must follow accessibility for… oh.. uh… because big company does so we must do same ooga booga smoothbrain incapable of critical thinking” Waste of time unless you are aiming your application AT people who use screen readers e.g. medical or public sector. EVEN THEN has anyone actually tried? Even accessible websites are garbage.
    - dieortin 3y ago
      This is not Twitter
  - mikojan 3y ago

Szpadel 3y ago

I'm not surprised that most of rust guis are not a11y friendly, there is no established gui library yet, none of them I would call mature yet Not long ago there weren't any gui libraries that wouldn't be just binding to existing C framework or was in proof of concept state of lifecycle I'm sure this situation will improve in the future and I understand frustration of someone that rely on a11y features, but you need to understand that everyone first will try to achieve solid gui library before will start adding accessable functionality

yoyohello13 3y ago
System76 is making headway getting a11y accessibility for Cosmic Desktop. They are doing a lot of good work in the Rust gui space.
- Szpadel 3y ago
  Agree, I think they might shape first mainstream rust gui library. They are doing amazing job with whole desktop environment. I'm yet to check first hand their work, but so far looks very promising

CharlesW 3y ago

> I wish developers finally learned this lesson. From a product perspective, re-inventing the wheel for something that — at best, many years from now — will be at parity with native presentation layers in terms of performance, a11y support, user experience, etc. is normally considered a risky move. Many startups have failed in part from pouring resources into shiny non-differentiators. The only examples of successful products that use non-native UIs either (1) leverage web technologies or mature frameworks like Qt, or (2) are Blender (age 30). Apple did this with iTunes, but iTunes felt unpleasant on Windows, and people used iTunes for Windows in spite of this. I understand the appeal of creating frameworks like GPUI, but the article doesn't explain the relationship to the problem Zed is trying to solve.

miki123211 3y ago
There's also Zoom, which apparently uses an internal, heavily-modified fork of some Chinese UI framework on Windows (and QT on everything else). They did go the extra mile and add accessibility support though, their American clients, particularly the ones in government, healthcare and education, didn't really give them any other option. There's also Google Docs, which uses weird tricks instead of rendering straight to DOM. They didn't even bother implementing accessibility in that layer, something which would probably have been impossible back then. Instead, they offer an accessibility mode and mark their entire UI as hidden to assistive technologies. When the accessibility mode is on, all speech is generated by a micro screen reader implemented in Google Docs directly, and the generated messages are sent as text to be spoken by your real screen reader. This is an ugly hack that doesn't really support braille displays very well, so they later implemented yet another layer of ugly hacks that retrofits the document on top of an actual DOM. Your point still stands though, these are exceptions that prove the rule.
- CharlesW 3y ago
  Interesting, thanks! It looks like Figma (a clear success) also took the "just give me a canvas" route: "Pulling this off was really hard; we’ve basically ended up building a browser inside a browser. […] Instead of attempting to get one of these to work, we implemented everything from scratch using WebGL. Our renderer is a highly-optimized tile-based engine with support for masking, blurring, dithered gradients, blend modes, nested layer opacity, and more. All rendering is done on the GPU and is fully anti-aliased. Internally our code looks a lot like a browser inside a browser; we have our own DOM, our own compositor, our own text layout engine, and we’re thinking about adding a render tree just like the one browsers use to render HTML." https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/ https://www.figma.com/blog/building-a-professional-design-to... The value proposition of a "boil the ocean" approach to UX frameworks is clearer for browser-based apps than native apps. That said, 7 years in, Figma apparently has a long way to go: "To repeat a familiar refrain: We still have a lot of work to do! As we continue to improve access to our own products, we’re also advancing our understanding of what our users need to design accessibly." https://www.figma.com/blog/announcing-figjam-screen-reader-support/ https://www.figma.com/blog/announcing-figjam-screen-reader-s...

pmarreck 3y ago

Honest question out of curiosity- Are there possibly AI-based solutions possible that can add assistance at a more generic level that doesn't require software that has "deep" knowledge of the window architecture (and the actual text in it etc.)? My understanding is that this is how tech like VoiceOver works- it knows the actual window definition and all the elements of it at a programmatic level and can take advantage of that. I'm not asking if they're already available (although that would be a nice option), but for projects like this that wanted the speed of rendering on the GPU (at the possible cost of, as you said, VoiceOver seeing an "empty window"), it would be at least a fallback position. (So does this mean that ALL content that renders through the GPU, such as games, are inaccessible to you? If so, I'm sorry...) Not sure if this might help you but I have an Apple shortcut defined on my iPhone called "GPT Explains" that is activated by a double-tap on the back of the phone (which you can assign, as you probably know, in Accessibility settings)- it takes a screenshot, ships it off to OpenAI and returns with a description of what it's seeing, any to-English translation of non-English text, and any counterarguments to any claims made in a meme, etc. (yeah, the prompt for this is kinda wicked, lol). If this is helpful to you, I can give you a link after I remove my OpenAI key (you'd have to provide your own). EDIT: I made a copy of it without the API key: https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f692776b https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...

miki123211 3y ago
iOS already has such a feature, but it's obviously not 100% accurate, not real time, and not great for battery life. It's good enough if you have to click a broken "I accept your terms and conditions" checkbox, but nowhere near good enough to daily drive your phone with. In other words, a band-aid solution for when everything else fails, mostly for situations where the app you're trying to use is mostly usable, but has an accessibility barrier preventing you from carrying out a crucial step somewhere. There's also vocr on Mac (and equivalent solutions on Windows), which recently got some AI features, but it doesn't even recognize control types (a very basic feature of any screen reader), just text. Again, good enough to get you through most installers where all you're doing is clicking "next" ten times, probably good enough to get you through the first-run experience in a VM that doesn't yet have a screen reader installed, at one tenth the speed of a sighted person, but that's about it.

nojvek 3y ago

Don’t want to downplay the concern. With modern machine learning is there an opportunity to build a better accessibility tool? Something that works on any set of pixels and sees like a human does? I.e parses text with OCR.

KTibow 3y ago
That would be useful if the normal way fails but would always be slower and not as accurate than intentionally implemented accessibility