#AccessKit question. I'd like to recommend this to developers so they can make their projects more #accessible. I noticed there's no documentation. Is it easy enough to learn without the need for documentation? If not, I'm hesitant to recommend something that I know developers are going to struggle with. It's tough enough asking them to make their apps accessible when they don't know much about us, let alone asking them to learn a new library with no docs. #Accessibility#Blind#VisuallyImpaired
@nekohayo Faut que je jette un oeil en effet. Après c'est bien beau de faire des plans sur la comète et d'ériger des standards mais il faut des solutions concrètes à l'accessibilité malheureusement :/
Yesterday in #LibrePlanet chat I named the #Makepad project, a real adorable 😍 effort that's still lacking on the #a11y side, i.e. could do with some #AccessKit on board.
Today I found out that Makepad is apparently part of a #Rust appdev effort, called #Robius. Another project here is #Dioxus.. also in for @accesskit#accessiblity support.. maybe. 🤔
Robius looks like a very loose conglomeration of independent projects. Maybe AccessKit is even a fit to it?
@smallcirclessigh getting Makepad to use AccessKit is going to be hard, because they're very strict about what dependencies they accept. They obsess over compile time. Of course, if they want to use our code as a starting point for their own, minimal-dependency accessibility implementation, that's fine with me.
> #a11y has long been confined to only a handful of the largest, most well-resourced UI toolkits, leaving a large proportion of #FreeSoftware inaccessible to disabled people. AccessKit [provides] an accessibility abstraction and glue layer that can be reused by many toolkits across programming languages.
TIL; iOS allows accessibility elements to have non-rectangular bounds, using bezier paths. Clearly I should add that feature to my #AccessKit cross-platform library (no, AccessKit isn't an Apple thing).
@Alper_Celik If I add it to AccessKit, then the new Wayland protocol will get it too. The current plan is to use serialized AccessKit trees. Of course, as the new Wayland protocol is more widely tested and reviewed, we may find deficiencies in the AccessKit schema.
Just saw that the Zed code editor (https://zed.dev/) is now open source. It's written in Rust and has its own GUI toolkit, called GPUI. Doesn't look like they've done any work on accessibility yet. Hopefully they'll see fit to spend time integrating #AccessKit soon.
I want to do an overhaul of the #AccessKit project website (https://accesskit.dev/). The current site is kind of broken, but more than that, I want to do a static site with source in Git, not WordPress. The site contains a blog, but it's not just a blog. I haven't yet decided whether tutorial/narrative documentation should be part of the same site or on a separate docs site. The theme needs to prioritize accessibility but also not be ugly. I'd gladly pay someone to work on this.
Thanks to some excellent work by Arnold Loubriat, #AccessKit now has Python bindings. https://pypi.org/project/accesskit/ This will be useful for GUI toolkits where the widgets are actually implemented in Python, such as Kivy or UIs on top of Pygame, as opposed to Python wrappers over C/C++ toolkits or platform widgets. Documentation is still pretty thin, but there's a pygame-based example in the source distribution.
I should also thank everyone who has worked on PyO3 (https://pyo3.rs/v0.20.1/), which makes it much easier to write Python extension modules in Rust. If Java had something equivalent, my Java bindings for #AccessKit would probably be done already.
It's tempting to reduce the compiled size of one's software by excluding debug info from release builds. For end-user apps, it makes sense to exclude the debug info from the main distribution, and for proprietary software, to keep it to oneself. But for pre-built binaries of open-source libraries, like my #AccessKit project, I think we have a duty to include debug info in the build and pass it along, so the ultimate app developer can debug issues in release builds if they need to. Thoughts?
I can't stop wondering if, to truly meet my goals for the #AccessKit project (https://github.com/AccessKit/accesskit), it will be necessary to rewrite it as a C library. Not a Rust library with a C API, but actually in C. I've had doubts before; you'd think the question would be settled by now. But two things prompted me to think about this again. 1/?
First, there was a Hacker News thread yesterday (one of several over the years) about the most popular C++ immediate-mode GUI library, Dear ImGui. I'm happy to say that others brought up accessibility; I didn't have to. But it occurred to me that, while some applications using Dear ImGui may be willing to use AccessKit via the C API, Dear ImGui itself probably wouldn't, because that would make it impossible to just drop a handful of C++ source files into any build system. 2/?
@matt I don't think that my shitpost ought to be the sole inspiration for your desire to rewrite-it-not-in-rust
Micro-optimizing which languages we choose for software projects on the basis of climate change is not productive, unless the language you choose is some Ethereum shit or whatever. There are better ways to address environmental goals.
I occasionally have to remind myself, when promoting my #AccessKit project, that what really matters isn't whether developers use AccessKit, but that they implement accessibility one way or another. AccessKit isn't always the best solution. For example, it may be overkill for a project that's only targeting the browser but is still rendering the UI in a canvas. In that case, it may be simpler to create the hidden HTML elements directly rather than going through a layer of abstraction.
Also, while Arnold Loubriat (the other main #AccessKit developer) and I were together in Albuquerque, where we met in person for the first time, we worked on the web platform adapter for AccessKit. This is specifically for web applications that render their UI to a canvas. We ran into an unexpected complication at the end, but the results so far are promising.
My #RustConf talk about #AccessKit yesterday went pretty well, though it went a few minutes over, and I'm pretty sure my conclusion in particular was too long. Not exactly looking forward to listening to the recording when it comes out, but I know I should.