In reply to @_slack_teamkodi_U07J7TDRU:matrix.org
and a binary addon is much more effort

hello there!

So, today I set up a new kodi installation, and was reminded again of how complex it actually is to install the kodi screenreader, aka services.xbmc.tts, especially since it's not in the repository anymore.

Before recently, the only possible options for making stuff accessible were:

• write it in a toolkit which supports accessibility, gtk, qt, electron, etc are all good options
• implement the accessibility logic yourself, which is undesirable because it's platform-specific and tedious besides
• use text to speech solutions to essentially self-voice your ui, which is clearly not working out with kodi, because y'all don't want to make the screenreader a part of the program, with a good reason

So then, a new option appeared relatively recently, it's called accesskit, which I believe would be awesome for integrating with kodi. Here's what I know about access kit, all good reasons for which adding it should be considered

• it's cross-platform, working with all platforms it supports behind the adaptor abstraction. This only works with windows, mac OS and linux, but that's very important as well, even if that's what we could access with the previous kodi screenreader before, this time the adon wouldn't be required and kodi would be accessible by default
• its architecture is based on imediate UI paradigms, which means you provide it with tree diffs of what changed between the current frame and the previous one, not unlike what you already do with rendering, and it figures out the rest in such a way that it just works with all supported screenreaders and operating systems
• it's written in rust, so less memory management issues over all, plus a relatively simpler dependency chain if you just take it vendored like that, though you can also actually integrate it with sources and all. Most important though, it has C bindings, which means it would integrate nicely with kodi. It also has python bindings, if adding it at that layer instead is better
• because it's native UI, a lot more controls would be accessible than the screenreader could present before, media descriptions for example, along with other similar things, so a win win for everyone

Finally, the relevant links:

• accesskit website: https://accesskit.dev/
• C bindings, including an example accessible application, which uses sdl to manage focus and such, for a dummy application which is invisible to everything but the accessibility infrastructure: https://github.com/AccessKit/accesskit-c
• python bindings: https://pypi.org/project/accesskit/

So, what do y'all think? could this be revisited again, now that there's a universal framework to make this kind of UI accessible? I really hope so, and would be glad to do the testing to make sure it works, at least on linux, and I know people who can test on windows too