I was helping an open-source app become more #accessible yesterday and we ran into the problem that it looks like #screenReader Orca has a bit of a tendency to crash when exposed to webkitGTK applications. I've not done Desktop #linux for a long time and have no idea what the workarounds for this would be, does anyone know anyone who might know what's happening here? Do we need to set a random environment variable somewhere or update a specific package so this person can do basic screen reader testing on their app? #tech #openSource #screenReaders #linux #GTK #webdev
The consensus seems to be that yes, this is broken, and no, there's not really any way around it for the moment. Also no, nobody's really fixing it.
i want to, #Linux enthusiasts, I really, really do. But it's exactly this kind of thing that make me entirely unable to consider any Linux flavor as an OS I could be productive in, heck ... that I could get light usage out of. When it comes to #accessibility stuff either breaks and stays broken for years or even longer, or never worked well to begin with. I know there's efforts on their way to fix that, and all the respect, gratitude and solidarity with the people doing that no doubt thankless, against-the-current work, but as of right now there's just not enough here for me to warrant the gigantic effort and investment to get anything usable out of it that actually stays usable longterm.

@zersiax what exactly is wrong and where? You are declaring generalities where specifics are required to help correct.

I have 3 hours after work. I can fix one thing today. What one thing do you want fixed?

@ghostrunner I couldn't really begin to tell you. What I know is that several webkitGTK apps, when ran in conjunction with the Orca screen reader, misbehave, or crash outright. This is particularly prevalent in apps using Tauri as their runtime. I don't know why this happens, I myself don't have debug logs or crash dumps, I just know that users, like myself, were trying to run an app they made only to have it either crash the app, the screen reader, or both.
I am generalizing because in my 25+ years of being a computer user, this kind of thing is not anomalous. We're seeing it in Calamares installer accessibility issues that remained open for almost a decade, we're seeing it in the Wayland adoption where accessibility was clearly an afterthought some very talented people are now saddled with fixing, and that's just the examples I can think of by thinking for 10 seconds.
Like I said, I know people are fixing things, I just think right now, there's more people that aren't

@zersiax I feel for you. One trick I have seen in the industry is to have docker images of hundreds of installation 'profiles' which are then tested using generalized testing tools like selenium as run through cucumber.

The problem is that with cucumber, you are either verifying a location, which is buggy and hard to maintain, or you are verifying a 'rendered object name' which sometimes isnt even visible. its... better? but not ideal.

Anyway, we could create a generalized accessibility profile that can be applied and extended to various docker profiles of people's installations. it is probably better than nothing. then folks can submit to the test suite to get a badge or some silly gamification method to ensure actual use and adoption.