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
reshared this
Peter Vágner
in reply to Florian • •@Florian 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.
Florian
in reply to Peter Vágner • • •Peter Vágner
in reply to Florian • •@Florian 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.
Tamas G
in reply to Peter Vágner • • •Florian
in reply to Peter Vágner • • •Florian
in reply to Florian • • •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.
reshared this
André Polykanine and Svenja reshared this.
Ghostrunner
in reply to Florian • • •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?
Peter Vágner
in reply to Ghostrunner • •@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…
@Florian 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/-/…
Florian
in reply to Peter Vágner • • •Peter Vágner
in reply to Florian • •@Florian 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.
Florian
in reply to Peter Vágner • • •Peter Vágner likes this.
Florian
in reply to Ghostrunner • • •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
in reply to Florian • • •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.
🏳️⚧️PepperTheVixen🦯
in reply to Ghostrunner • • •Ghostrunner
in reply to 🏳️⚧️PepperTheVixen🦯 • • •@PepperTheVixen 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'
Kay Ohtie 🔜 FWA
in reply to 🏳️⚧️PepperTheVixen🦯 • • •@PepperTheVixen Even as someone who's sighted and (mostly) without disability, and technical, I was floundering on one distro just to get TTS besides espeak working. Thankfully far easier to solve elsedistro, but yeah, I keep seeing it being a problem and then people treating folks who are expressing broad frustration as "you're not being specific enough".
And I feel like half the problem is the people saying that are driven by problem solving only, and not learning about the entire puzzle to create their own problems within it to solve. Making disabled people do the lifting of clearly defining the technicals of their problems is, to me, a pretty crappy approach when the needs are well published already in numerous places and no one wants to learn them because they're not "technical problems".
Can't solve it yourself? Express empathy by doing what you can to put pressure on others to make it more accessible.
Speaking of, I still need to make that PKGBUILD for AUR so folks can install obs-localvocal to put captions on their stream (embed in video and/or standard subtitle closed captions in stream) more easily. Worked great once I built from source.
Jeffrey D. Stark
in reply to Florian • • •🏳️⚧️PepperTheVixen🦯
in reply to Florian • • •Mike Gorse
in reply to Florian • • •@pixelate I'm really sorry that you all are running into that.
A couple of questions. Which distribution/version are you running? When you say that Orca is crashing, do you mean that it aborts and needs to be restarted, or is it only failing to read your app but responding to other applications? I think the latter would probably mean that WebKit isn't able to connect to the accessibility bus, so possibly an environment variable isn't being set/transferred properly (I assume it is inside a flatpak?) The former might mean a crash in AT-SPI. gitlab.gnome.org/GNOME/at-spi2… is the one crash that I've seen reported recently, and I *think* that I fixed it in at-spi2-core 2.60.0 / 2.58.4 / 2.56.8. If you are, in fact, seeing a crash where Orca is aborting, then I would need to either be able to reproduce it or see a stack trace (if you don't know how to retrieve one, then I'll try to help).
Segmentation Fault Due to Chromium (#219) · Issues · GNOME / at-spi2-core · GitLab
GitLabPeter Vágner likes this.
Florian
in reply to Mike Gorse • • •Mike Gorse
in reply to Florian • • •@pixelate I was looking through the commit log the other day and noticed one accessibility-related crash fix post-2.52.1 [1], but I don't know if it is your crash (I know of others). You could of course try filing a bug on bugs.webkit.org if you can get a stacktrace, but I don't think that the Linux accessibility code has been getting a lot of attention lately, and I have several other things on my list of things to do and don't have a lot of time to spend on it either right now. Sorry for not being more helpful.
[1] bugs.webkit.org/show_bug.cgi?i…
310936 – AX: AccessibilityRenderObject::boundingBoxRect() is missing a null-check on a Node, causing crashes
WebKit BugzillaPeter Vágner
in reply to Mike Gorse • •@Mike Gorse @Devin Prater :blind: @Florian Although I have no compatible devices, I have built current git main version of opendeck on archlinux with gnome 49 with packages at-spi2-core-git 2.60.0.r5.g814b4d12-1 and orca-git 50.0.r137.gc96d101d4-1, webkit2gtk-4.1 2.50.6-1.
On the opendeck main window I can see these controls in the order of keyboard navigation with the tab key or the object navigation:
When using tab key to navigate the whole opendeck app freezes when trying to move from the text entry to the interactive list. Most likelly it also changes the visual appearance as described earlier but I can't verify that on my own. When navigating in a reverse direction by pressing shift+tab navigating from the silent document body element to the interactive list is working fine.
I don't think it's related to this list as I have seen interactive lists in a different apps such as deltachat-tauri which don't cause such a behaviour. However I have seen random freezes like this with the deltachat-tauri app as well and I see this occurence of this issue as a positive thing as I can reproduce such a freeze reliably all the times with opendeck app.
Peter Vágner
in reply to Mike Gorse • •@Mike Gorse @Devin Prater :blind: @Florian Oh I wanted to just cherrypick this fix on the top of the latest release and test if it fixes this particular case but it does not apply, actually there are more changes to accessibility since last release.
I will try if I can build webkit easily and verify this.
Here is history of commits inside the accessibility folder just out of curiosity: github.com/WebKit/WebKit/commi…
Mike Gorse
in reply to Peter Vágner • • •311427 – AX: Opendeck crashes webkitgtk with Orca running
WebKit BugzillaPeter Vágner likes this.
the esoteric programmer
in reply to Florian • • •Florian
in reply to the esoteric programmer • • •the esoteric programmer
in reply to Florian • • •Florian
in reply to the esoteric programmer • • •the esoteric programmer
in reply to Florian • • •