Skip to main content

I think one of the first non-Rust GUI toolkits that I want to see #AccessKit integrated into is Tk. It's still the de-facto default GUI toolkit for Python, and I just came across a Python IDE designed for beginners that uses Tk. In the meantime, I hope that IDE isn't being used in intro programming classes.
#accesskit
in reply to Matt Campbell

Matt Campbell
Matt Campbell
• •
Of course, getting a Rust dependency, even with a C API (which we don't have yet), accepted upstream in Tk itself is probably a long shot.
in reply to Matt Campbell

Matt Campbell
Matt Campbell
• •
Interesting bit of prior art in retrofitting accessibility onto Tk, or rather Python's Tkinter: There's an old Python package called Tka11y (pypi.org/project/Tka11y/) that implements accessibility on top of Tkinter using ATK (so Unix-only in practice). I hadn't realized that ATK could be used in applications that don't use GTK at all.

Tka11y

Accessibility-aware Tkinter
PyPI

Peter Vágner reshared this.

in reply to Matt Campbell

Matt Campbell
Matt Campbell
• •
Of course, ATK was itself an abstraction, for which AT-SPI was theoretically just one back-end (though it ended up being the only one in practice). So one could think of ATK as being a C-based equivalent of AccessKit, developed over 20 years ago. Not that I want to abandon AccessKit and go with ATK instead, of course. The GObject dependency and use of LGPL would probably prevent wider adoption of ATK outside the GNOME world. And even GNOME has effectively deprecated ATK now.
in reply to Matt Campbell

Federico Mena Quintero
Federico Mena Quintero
• •

Oh, yeah, ATK is still widely used. It was *the* accessibility library that was promoted back then as the way to make toolkits accessible.

LibreOffice, Firefox, and gnome-shell still use it, even though they don't use GTK.

⇧