That's the hill that almost every new UI toolkit effort dies on.

If I were going to start one, I would actually start with accessibility. If everyone keeps tripping over the same thing, start by tackling that thing first.

Edit: it's occurred to me that an approach of starting with accessibility could also lead to an approach that degrades gracefully into text UIs (TUI) and command line usage and then scales all the way up to a GUI. That would be super interesting. Not sure it's ever been done.

Shout it from the hills: OXO!

(As in the easy-to-use kitchenware https://en.wikipedia.org/wiki/OXO_(kitchen_utensils_brand) "In June 2004, Helen of Troy Limited bought OXO housewares for $273.2 million.")

It's a general pattern, make your thing easy for old people and folks with disabilities and it's also easy for everybody else.

- - - -

Check out Elm's accessible-html module. Enforces accessibility at compile-time.

https://package.elm-lang.org/packages/tesk9/accessible-html/...

https://dev.to/nimmo/easier-paths-to-accessibility-in-elm-4o...

I've been thinking about something similar. A polyvalent UI with CLI, GUI, and AUI (audible user interface). The AUI could be implemented as a TUI/HTML page (to leverage existing work on screen readers) but designed to be read rather than seen.

The behaviour based api that Fyne is designed with will degrade to a text UI, if anyone implements that driver ;). I always thought I would but it’s never reached high on priorities…

Yea this is a big gap. It is planned but the task is huge. Once we have sufficient sponsorship or financial support in place you can be assured it will come.

Would you be willing to consider using a non-Go library via a C API for this? I'm working on AccessKit [1], a cross-platform abstraction over the various platform-specific accessibility APIs. It's written in Rust, and it doesn't yet have a C API, but that's planned. I'm aware that using cgo complicates build requirements, particularly on Windows, but it looks like you're already dependent on cgo on Windows (unlike, say, Gio).

[1]: https://github.com/AccessKit/accesskit I know I haven't yet done much with it this year. Hopefully I'll start doing substantial work on this again in the next few weeks. Threads like this one remind me that the world is waiting.

Please continue working on this. After years of work and having a novel backend infrastructure figured out for something that may have a lot of value for people, I have simultaneously been completely unsatisfied with frontend options — and I’ve tried nearly all of them. Accessibility is a major issue in almost all I tried, and closed source, vendor-specific UI options are not acceptable.

The main one I’ve been very interested in these days is called Makepad. Also written in Rust, still early in dev, but they need a lot of help on the accessibility front and their codebase is trying to do everything else. But the techniques are what I have been looking for in a UI kit. Anyway, I imagine there are a lot of cases like theirs.

The main issue is most of us do not have these accessibility issues. That domain knowledge needs to be collected and distilled into a framework that is open & simply covers most cases by its inclusion. Many JS frameworks have a lot of care in this regard, but their performance and dep hell make me want to avoid them (however tempting their ease of use may be).

Long story shot: this is very much needed and when I have time I would be willing to contribute.

Rust derive macros would be very powerful with implementing accessibility features.

Yes, we have actually considered AccessKit in our discussions :)

thanks for this. saves me from wasting time on it.

Thanks, I thought "maybe they implemented accessibility by now", but it seems to be a huge task.

> As expected, same problem as all the other UI toolkits.

Qt and Swing have this problem?

No. Swing does not suffer from that problem because Sun actually cared about accessibility requirements back in the days, in fact, the only reason there's a desktop on Linux that has decent accessibility, Gnome (through the Orca screen reader and gtk accessility libs) comes from Sun's interest in having an accessible desktop for Solaris. KDE's track record is miserable in comparison to Gnome. Sun provided much of the funding for the initial efforts in making an accessible desktop.

Qt is partially accessible, in practice, it doesn't work well.