4 ms·

Searched for “accessibility” — 0 results (I couldn’t see anything skimming down the page). Speaking as a Rust user, everyone in Rust land loves insulting Elect

Searched for “accessibility” — 0 results (I couldn’t see anything skimming down the page). Speaking as a Rust user, everyone in Rust land loves insulting Electron, but they have put some solid work into accessibility. In particular, using WASM to draw text with webgl or canvas, instead of DOM, may in the long term be one of the biggest steps back in accessibility ever.

hnon 4y ago
I think it's interesting that we take it for granted that accessibility is primarily the responsibility of GUI toolkit developers. I would think that maybe some amount of blame would fall on OS vendors, who have billions of dollars flowing through their organizations, rather than some random open source projects. If your app can be described to a screen reader, then there should be an easy cross platform API[0] for GUI toolkit makers to use, provided by the underlying platform in a reasonably simple way. [0]: I am aware of AccessKit. Where's the OS backing?
capableweb 4y ago
I'm not familiar with the entire ecosystem but at least egui offers accessibility via AccessKit
- CJefferson 4y ago
  Thanks. Last time I looked in depth (about 6 months ago), nothing supported accessibility, but you are right, it looks like egui at least has made excellent progress. I still keep my comment about the article -- I feel discussions of GUIs should talk about this type of thing, as so many people require accessibility support.
jenadine 4y ago
Desktop solutions don't use wasm/canvas for their primary use. Although you can wasm to compile it for web demo, they are primarily meant to be used as native apps outside of a browser. I know Slint and egui have accessibility support.
eviks 4y ago
There's AccessKit that's integrated in a couple of frameworks (egui is one) (but hopefully it'd be a temporary step back)
chrismorgan 4y ago
Since people will bring up AccessKit, assuming it to be a potential panacea (… despite the obvious performance cost of doing absolutely everything twice): The pure canvas approach used by things like egui (and it probably can’t change it) and current iced (it used to have iced_web which rendered to DOM, but that’s been abandoned for now for no obvious reason) is fundamentally and irredeemably unsuitable for general-purpose web content and apps, in ways that things like AccessKit cannot fix. I’ve written about this a few times; https://news.ycombinator.com/item?id=33861831 https://news.ycombinator.com/item?id=33861831 is probably the best thread. The two items I like to focus on are links and scrolling, both of which are unavoidably broken.
- LeanderK 4y ago
  this take is a little bit too simplistic. There are use-cases where you are bound to a web-based framework but JS solutions are just not fast enough, e.g. data visualisations via jupyter notebooks. So you're stuck with some horribly slow solutions or non-interactive ones giving you pngs. Since you're plotting data, the text is minimal and the needed dialogs etc. are also minimal (clicking on a point and getting a label) or having a few options to rotate/turn on some features/zoom. And pngs with rendered text is as inaccessible as it gets, although data-visualisation may be fundamentally incompatible with accessibility tools since it is all about seeing stuff. So I usually produce pngs via matplotlib and only selectively use interactive, js based, visualisations but they are get so unbelievable slow quickly when that your whole tab freezes.
  - chrismorgan 4y ago
    I believe you’ve misunderstood my intent. When I speak of the pure canvas approach, I mean throwing away almost all that the browser gives you, and rendering everything in a single canvas, with fake scrolling, fake links, &c. For individual widgets like data visualisation, go ahead, use canvas if you want; I won’t complain—though make sure if you have any links in it that you have actual <a> links on top of the canvas for the user to interact with. And also consider if you can SVG. Anyway, individual canvases are fine; but don’t put everything in a single canvas. Things like Google Docs and Figma are often cited as examples of how canvas-based rendering can be not bad, but neither are pure canvas: the user interface of both is full DOM, and it’s only the document area that’s canvas. (Also, I find Google Docs somewhat unpleasant: its rendering latency and throughput while you type is terrible, and keyboard caret navigation doesn’t match my platform’s behaviour in many places.) See also https://news.ycombinator.com/item?id=33863185 https://news.ycombinator.com/item?id=33863185 (similar content to this comment).
low_tech_punk 4y ago
I think Tauri bypassed the a11y challenge by delegating rendering to platform native web engines.
- rwalle 4y ago
  Eh, that's not how it works. Web engines do a great job at providing accessibility for basic stuff, but to make an application and its content fully accessible, you would need to have accessibility as a requirement from the very beginning, make sure every little UI element is accessible (sometimes meaning provide additional fallback content), and constantly test your UI, which is never something that can be automatically added on top of an existing non-accessible UI.

hnon 4y ago

I think it's interesting that we take it for granted that accessibility is primarily the responsibility of GUI toolkit developers. I would think that maybe some amount of blame would fall on OS vendors, who have billions of dollars flowing through their organizations, rather than some random open source projects. If your app can be described to a screen reader, then there should be an easy cross platform API[0] for GUI toolkit makers to use, provided by the underlying platform in a reasonably simple way. [0]: I am aware of AccessKit. Where's the OS backing?

capableweb 4y ago

I'm not familiar with the entire ecosystem but at least egui offers accessibility via AccessKit

CJefferson 4y ago
Thanks. Last time I looked in depth (about 6 months ago), nothing supported accessibility, but you are right, it looks like egui at least has made excellent progress. I still keep my comment about the article -- I feel discussions of GUIs should talk about this type of thing, as so many people require accessibility support.

jenadine 4y ago

Desktop solutions don't use wasm/canvas for their primary use. Although you can wasm to compile it for web demo, they are primarily meant to be used as native apps outside of a browser. I know Slint and egui have accessibility support.

eviks 4y ago

There's AccessKit that's integrated in a couple of frameworks (egui is one) (but hopefully it'd be a temporary step back)

chrismorgan 4y ago

Since people will bring up AccessKit, assuming it to be a potential panacea (… despite the obvious performance cost of doing absolutely everything twice): The pure canvas approach used by things like egui (and it probably can’t change it) and current iced (it used to have iced_web which rendered to DOM, but that’s been abandoned for now for no obvious reason) is fundamentally and irredeemably unsuitable for general-purpose web content and apps, in ways that things like AccessKit cannot fix. I’ve written about this a few times; https://news.ycombinator.com/item?id=33861831 https://news.ycombinator.com/item?id=33861831 is probably the best thread. The two items I like to focus on are links and scrolling, both of which are unavoidably broken.

LeanderK 4y ago
this take is a little bit too simplistic. There are use-cases where you are bound to a web-based framework but JS solutions are just not fast enough, e.g. data visualisations via jupyter notebooks. So you're stuck with some horribly slow solutions or non-interactive ones giving you pngs. Since you're plotting data, the text is minimal and the needed dialogs etc. are also minimal (clicking on a point and getting a label) or having a few options to rotate/turn on some features/zoom. And pngs with rendered text is as inaccessible as it gets, although data-visualisation may be fundamentally incompatible with accessibility tools since it is all about seeing stuff. So I usually produce pngs via matplotlib and only selectively use interactive, js based, visualisations but they are get so unbelievable slow quickly when that your whole tab freezes.
- chrismorgan 4y ago
  I believe you’ve misunderstood my intent. When I speak of the pure canvas approach, I mean throwing away almost all that the browser gives you, and rendering everything in a single canvas, with fake scrolling, fake links, &c. For individual widgets like data visualisation, go ahead, use canvas if you want; I won’t complain—though make sure if you have any links in it that you have actual <a> links on top of the canvas for the user to interact with. And also consider if you can SVG. Anyway, individual canvases are fine; but don’t put everything in a single canvas. Things like Google Docs and Figma are often cited as examples of how canvas-based rendering can be not bad, but neither are pure canvas: the user interface of both is full DOM, and it’s only the document area that’s canvas. (Also, I find Google Docs somewhat unpleasant: its rendering latency and throughput while you type is terrible, and keyboard caret navigation doesn’t match my platform’s behaviour in many places.) See also https://news.ycombinator.com/item?id=33863185 https://news.ycombinator.com/item?id=33863185 (similar content to this comment).

low_tech_punk 4y ago

I think Tauri bypassed the a11y challenge by delegating rendering to platform native web engines.

rwalle 4y ago
Eh, that's not how it works. Web engines do a great job at providing accessibility for basic stuff, but to make an application and its content fully accessible, you would need to have accessibility as a requirement from the very beginning, make sure every little UI element is accessible (sometimes meaning provide additional fallback content), and constantly test your UI, which is never something that can be automatically added on top of an existing non-accessible UI.