@prism @DiogoConstantino @iaruffell As a law it becomes applicable when it becomes a commercial project.

If you're freely distributing your "hobby" OS then whatever. But the minute you make a job of it, or more specifically that you make a product of it, like Red Hat, Canonical or System76 do, then you're fully liable.

So while it is "hobby" it is the developer. While it is corporate, extractivism is the priority and legal compliance is deferred by bullshitting instead.

@prism @DiogoConstantino @iaruffell That being said for accessibility and development, there are major hurdles for some developers: If you make your GUI with Tk, McCLIM or other smaller or less common GUI frameworks, they frequently lack accessibility tooling entirely.

(Interestingly Emacs is a notable exception for this, if your definition of GUI is flexible enough.)

The kind of skills & knowledge required to make accessibility tooling are considerably more and different than those required to merely use it. Especially with frameworks that make it basically automagically handled like Qt & Gtk.

@lispi314 @prism @DiogoConstantino

Yes, of course. I am really thinking of GNOME, KDE and core apps. It is not quite automagic if custom widgets are involved, as they often are with Kde., in particular
, I think there is also an issue of why someone would want to use a toolkit without accessibility tooling, at least for new apps.

@iaruffell @prism @DiogoConstantino

if custom widgets are involved, as they often are with Kde.

Ah that's unfortunate.

The KDE widgets fail to implement it? It would be nice to see that improve, particularly since it's one of the few sane options for desktop Delta Chat (Electron-driven abominations are not good options).

, I think there is also an issue of why someone would want to use a toolkit without accessibility tooling, at least for new apps.

Well, for Tk mostly because it's a lot less annoying to use for a simple one-off utility.

(And then before long it turns into a not-a-one-off at all long-term utility that does a lot more than it was originally thought or intended to.)

For McCLIM because it's native to the language and has a much more interesting approach to the representation of interface modes (there's nothing preventing accessibility support being added to it, its architecture might even allow it to take better to it than many others, it just needs someone dedicated and with the right skills & know-how to get it done).

Also Gtk & Qt are awful to interface with using FFI and having to autogenerate FFI from a parser is gross (this is how Qt bindings work in most languages).

Tk gets around that by enabling remote-controlling via pipes (typically), which is something Gtk & Qt could absolutely have enabled (there's some third-party Gtk-server that does that, though I think it fell back in supported versions).

(Accessibility could probably be added to Tk, but I think it would require someone not only with the accessibility skillset, but also comfortable with Tcl which is fairly rare now, which I take to be the reason it hasn't been done yet.)

The use of something like BMessages for interface control (yes, this made GUIs sanely scriptable on BeOS/Haiku) would also have gotten around that. Instead we have to deal with C++ having basically no stable ABI (it technically does, unlike Rust, but how practical it is for interop & FFI is a different matter) and assuming people use similar or identical languages (or have gone through a lot of work to hide the impedance mismatch, as with Java (either the options are very obvious generator output or they required a lot of manual massaging) or LQML (possible solely through Common Lisp having implementations in those very same or similar languages)(not to be confused with an identically-named LLM slop project)).

(Part of managing the verbosity of those FFIs from the large framework is due to language feature mismatch.)

Of course with Java there's Swing and JavaFX which do have their own accessibility integration (I had been under the impression it had no Open Source or Free Software mobile support but apparently I was mistaken, it does).

Having only one or two options (KDE isn't really independent from Gtk) also feels far too much like a low-diversity ecosystem that could quickly die out.