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.

[pvagner@fedi.ml]

@zersiax It looks as compared to firefox or chromium webkit gtk has some issues when it comes to screen reader accessibility.
Sometimes the focus is trapped in some unlabelled object, accessible labels from multiline children only take first line into account.
In v 2.50.6 an important issue related to incorrect role types being reported has been fixed.

For example all the tauri based apps are suffering from webkitgtk issues no matter how much great screen reader accessibility has been put into their design.

[zersiax@cupoftea.social]

@pvagner yep, this is a Tauri app. Is specifically that issue currently being worked on, that you know of?

[pvagner@fedi.ml]

@zersiax I'm afraid no ongoing accessibility related work for webkitgtk is in in progress currently.

That being said I am not involved I'm just a linux user watching some email lists and people on mastodon and these are my guesses.

[tamasg@mindly.social]

@pvagner @zersiax oh boy I really hope that's not true but with how slow Webkit bugs get resolved I wouldn't be surprised. VoiceOver is always the hardest one to rangle into submission for me especially where elements with complex parent-child relationships are involved and specific widget rules it just doesn't honor the same.

[zersiax@cupoftea.social]

@pvagner unfortunately about what I expected, thanks for responding

[zersiax@cupoftea.social]

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.

[ghostrunner@hachyderm.io]

@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?

[jstark@caneandable.social]

@zersiax true that

[zersiax@cupoftea.social]

@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

[ghostrunner@hachyderm.io]

@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.

[pvagner@fedi.ml]

@ghostrunner I don't have enough knowledge on what exactly has to be done in order to fix it as a whole, however one long standing webkit issue that would be helpfull to move forward is: bugs.webkit.org/show_bug.cgi?i…

@zersiax It would be nice to get more details about crashes you are experiencing.
Is orca crashing in a way so it's no longer running after performing certain steps?
Or is it running and no longer reporting what's happening?

Could you either file an issue or try to describe on how I might be able to reproduce that orca crashing and file it on your behalf?

Orca issues are best filed at: gitlab.gnome.org/GNOME/orca/-/…

[zersiax@cupoftea.social]

@pvagner @ghostrunner Unfortunately I don't have a setup to test it reliably. From what I heard, it's not so much Orca that crashes but rather tauri-based web apps themselves

[pvagner@fedi.ml]

@zersiax If you are working with someone else on this, can you please ask them to comment if it's an orca crashing or a different issue?

As I have said I have experienced when keyboard navigation has stuck in some unlabelled control and the only way to get the keyboard focus handling to work again is to restart the app either gnome web aka epiphany or any other tauri app such as deltachat-tauri. However during this orca is still running and switching into different windows it's responsive.

Severe orca issues like a crash are usually addressed in a timely manner so if we can find a reliable reproducer for an orca crash we can ask politely to get it fixed.

[zersiax@cupoftea.social]

@pvagner They're telling me essentially the entire UI of the application disappears and only the application background remains visible when scertain parts of the app are interacted with. I passed on that link you gave me asking if they can comment on their experience

[pepperthevixen@meow.social]

@ghostrunner @zersiax This is a deficiency in linux desktops as a whole. It would take months of work to fix. It's not just one problem, it's a whole series of problems split across different packages born out of neglect for accessibility

[pepperthevixen@meow.social]

@zersiax This is part of the reason that I main Gentoo. I don't want Linux on hard mode, but it's the only way I can make it work how I want it to work

[ghostrunner@hachyderm.io]

@PepperTheVixen @zersiax yeah, im seeing this.

if we built a service folks could submit their builds to which will test the matrix of setups, we could start building bulwarks against the neglect.

definitely not a 'ill fix this in 3 hours' and more a 'ill think about this nastiness for 3 hours and feel real bad'

[esoteric_programmer@social.stealthy.club]

@zersiax the screenreader doesn't exactly crash when working with webkit-gtk or qtwebengine, but instead, browse mode doesn't work properly because the accessibility code doesn't have support for the object replacement character, which would tell orca where in a given piece of text it should insert a link

[zersiax@cupoftea.social]

@esoteric_programmer would that also cause the underlying application to crash/stop rendering? Thats one of the things we're seeing

[esoteric_programmer@social.stealthy.club]

@zersiax nope, I've never seen that failure mode. Is this packaged as a flatpak with the gnome runtime or something like that, so I can possibly do debugging? what distro? what orca version? did you change anything from the orca config?