Peter Vágner

Father, geek, sysadmin from slovakia. I like to party with friends, work with new technologies, I am relying on screen reader accessibility. I prefer open-source and self-hosted apps and services.

Deltachat: [i.delta.chat/#515A3B069AC8066F…](https://i.delta.chat/#515A3B069AC8066FA960E789495C317333C1A65E&a=zs0s91y8i%40cmail.pvagner.sk&n=PVagner&i=Z73XfT-wf_CxMBLzBzxMzuJ7&s=O-SOzvfw36h2_1ZMJX5zQZF5 )
Keyoxide: [keyoxide.org/8df9b61a17bf88354…](https://keyoxide.org/8df9b61a17bf88354842ecc5144312f3eb650a2d )

Public Key

npub1qrhm25xsvhzg6vc6e332cd5r0rexmd3h4nl30k8az0gpkwr2r8dqwf3zlr

NIP-05 Address

pvagner_at_fedi.ml@momostr.pink

Profile Code

nprofile1qqsqpma42rgxt3ydxvdvcc4vx6ph3undkcm6elchmr7385qm8p4pnksprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmntqyxhwumn8ghj7mn0wvhxcmmvyv3rjv

Publishing to

relay.momostr.pink

nos.lol

nostr.wine

Author Public Key

npub1qrhm25xsvhzg6vc6e332cd5r0rexmd3h4nl30k8az0gpkwr2r8dqwf3zlr

Show more details

Last Notes

2026-07-23 12:47:36 UTC

- reply

@[url=https://ani.social/u/TheMightyCat]TheMightyCat[/url] Oh yes, thanks for your interest and a nice comment.
A somewhat simplified explanation of linux accessibility stack from an advanced user (not developer) looks like this:
Standard linux screen reader running alongside graphical desktop environments such as gnome or KDE is called orca. It uses a dependency called at-spi2-core for delivering and interpreting accessibility events from different toolkits such as GTK4, QT6 and similar.
Thus at-spi2-core has clients on both the sides. Orca usually consumes events and GUI toolkits and other standalone apps generate them.
For the full picture there are apps that communicate to at-spi2-core directly to provide its accessibility for example web browsers (Firefox, Chromium and webkit-gtk) and libreoffice are doing this.
The fact screen reader is interpreting accessibility events delivered to it through at-spi2-core is a nice thing and it's a huge part of the puzzle however screen reader has more functionality than dealing with the stream of accessibility events.
For example screen reader needs to be able to review the content by words, by lines and provide different navigation actions.
For that it needs to react to user key presses.
On wayland reacting to keypresses without having a control focused is a security risk thus a protocol extension has been developed which allows screen reader to ask at-spi2-core to coordinate grabbing the keys with the compositor. I don't fully understand this part so it may be a very rough explanation. However it's key point to understand that for touch screen operated device it's not enough to read what has happened in response to some touch screen gestures. We need an ability to review the screen content before executing actions. On different platforms such as android, IOS or Windows it's implemented in a way so touch interaction model works a bit differently when screen reader is running. This is not yet implemented for linux no matter which form factor.
Technically speaking if I would have an USB keyboard connected to the phone I would certainly be able to use parts of its graphical interface but that would not be practical enough.
Please excuse me for commenting on your announcement thread even adding such a long attempt at explaining my situation. I do really appreciate all the work and advancements you are releasing to the public.
It's just that I am partially saddened by the fact I can't experience this linux mobile movement on my own.

2026-07-23 10:42:56 UTC

- reply

@[url=https://dragonscave.space/users/menelion]André Polykanine[/url] While registering at @[url=https://social.anoxinon.de/users/Codeberg]Codeberg[/url] I've got a very friendly captcha solving registration patch / assistance in a few minutes after contacting their support. I would say they don't want to host loads of unmaintained one time generated personal projects. If a project is maintained with more contributions from humans this should not be a real problem I would say. @[url=https://swecyb.com/users/troed]Troed Sångberg[/url]

2026-07-23 10:24:34 UTC

- reply

@[url=https://ani.social/u/TheMightyCat]TheMightyCat[/url] Oh, this really sounds as a cool update.
It's a pity screen reader accessibility is not yet a thing on mobile linux at least I can't find someone making great progress with that.

2026-06-21 18:31:15 UTC

- reply

@[url=https://toot.cafe/users/matt]Matt Campbell[/url] It's still trained using the same stack like piper and runs through onnx runtime but @[url=https://grapheneos.social/users/GrapheneOS]GrapheneOS[/url] people have forked matcha TTS and even managed to write their own phonemizer for english so it no longer needs espeak. They are hoping to improve the performance of their speech services android app using it. I think it's worth looking into and taking some good use of.
[url=https://github.com/GrapheneOS/Matcha-TTS/]https://github.com/GrapheneOS/Matcha-TTS/[/url]
[url=https://github.com/GrapheneOS/SpeechServices]https://github.com/GrapheneOS/SpeechServices[/url]

2026-05-26 09:37:51 UTC

- reply

@[url=https://social.highenergymagic.net/ap/users/116201069828972775]Ra (Freyja) (it/its)𒀭𒈹𒍠𒊩[/url] I know you are trying to make the most of this for you and other power users, however I just wish to add that not all the blind users are so hooked up to eloquence TTS and only a few of them can use their TTS at such high speech rates. I have understood with this initial version of Graphene Speech services we can at least independently pass the initial setup of @[url=https://grapheneos.social/users/GrapheneOS]GrapheneOS[/url] and then we can switch to our TTS synthesizer of choice. For example I am very unlikely to stop using #[url=https://fedi.ml/search?tag=RHVoice]RHVoice[/url] and you are very unlikely to stop using #[url=https://fedi.ml/search?tag=Eloquence]Eloquence[/url] no matter what do the Graphene OS folks implement.
Having really good modern open-source natural sounding TTS for reading books is not a waste as you are pointing out especially if they are planning to make the other direction part of the app i.e. speech to text as well.
We have the same thing with #[url=https://fedi.ml/search?tag=NVDA]NVDA[/url] on windows. By default it uses natural sounding voice built into windows that has the same mistakes you are pointing out here, then it has espeak-ng included as an opensource alternative capable of running at very very high speech rates. And you are still adding eloquence into your setup eventhough you need to pass extra hoops in order to even make it run on the modern hardware and software configurations.
It's a very good thing you are advocating for all the blind users here but still if I were you I would try to calm down a bit.

2026-03-09 09:12:28 UTC

- reply

@[url=https://grapheneos.social/users/GrapheneOS]GrapheneOS[/url] I'm looking if I might be able to add support for different languages in the future. I see you've written a phonemizer doing the g2p as a part of the app. However training is done on a computer running your improved matcha TTS. While training what phonemizer were you using? Matcha's fork of Misaki or something else? I will be looking more into it, I'm also too excited about it right now.

2026-02-02 15:30:19 UTC

- reply

@[url=https://caneandable.social/users/NoahCarver]Noah Tobias Carver 👨🏼‍🦯🇺🇦[/url] @[url=https://dragonscave.space/users/pitermach]Pitermach[/url] @[url=https://infosec.exchange/users/prism]Drew Mochak[/url] I think you can install google talkback into @[url=https://grapheneos.social/users/GrapheneOS]GrapheneOS[/url] if you so wish. It's just that there is an open-source variant of talkback included from the start.
And the updates to talkback are coming in slightly slower pace, but it's not abandoned.
[url=https://github.com/GrapheneOS/talkback/pull/99]https://github.com/GrapheneOS/talkback/pull/99[/url]

2025-09-16 10:58:38 UTC

- reply

I have asked a friend and @[url=https://grapheneos.social/users/GrapheneOS]GrapheneOS[/url] community chat members for the help with initial setup and now I am fully configured with RHVoice as my current TTS of choice.
Except of one GPS navigation app I am used to everything is working fine for me including proprietary stuff for my work like Microsoft Teams, banking apps including Poštová banka, George and Revolut and the other apps I like such as Bitwarden as a password manager, Arcanechat, Conversations, ElementX, FairEmail, Open Key Chain for chatting and emailing, Antennapod, BubbleUPNP, Foobar 2000, Kore, Voice, NewPipe, ytdlnis for podcasts, music, audiobooks and videos, , Catima for lojalty cards and tickets, some other apps. For downloading apps I am mainly using F-droid and Aurora store. I am not signed into the google account but I am using play services for push notifications and other compatibility reasons for apps which need it.
Thanks for everything you are doing, it's fantastic and I like it verry much.

2025-09-12 19:49:07 UTC

Hello @[url=https://grapheneos.social/users/GrapheneOS]GrapheneOS[/url] screen-reader users and other #[url=https://fedi.ml/search?tag=a11y]a11y[/url] friends,
There was an interesting debate going on at the end of may where screen reader users were asking for #[url=https://fedi.ml/search?tag=tts]tts[/url] engine included with GrapheneOS base system.
[url=https://grapheneos.social/@GrapheneOS/114569769406507110]https://grapheneos.social/@GrapheneOS/114569769406507110[/url]
I understand this is very unlikely to change in the near future as I am not aware of a TTS system that is open-source and modern enough to be included.
@[url=https://mastodon.social/users/accessibleandroid]Accessible Android[/url] has a list of TTS engines sorted by language at this page: [url=https://accessibleandroid.com/list-of-languages-with-available-tts-engines-on-android/]https://accessibleandroid.com/list-of-languages-with-available-tts-engines-on-android/[/url]
Except of eSpeak-ng and RHVoice there is another opensource app called SherpaTTS that can use Piper TTS and Coqui based voices at: [url=https://github.com/woheller69/ttsEngine]https://github.com/woheller69/ttsEngine[/url]
Including eSpeak-ng, RHVoice, SherpaTTS and the list of TTS engines mentioned by accessible android, is there a viable TTS engine or at least one that is close enough to be viable to get included in the foreseable future?
Another approach I have been thinking about is to add / inject the TTS app or any other app I'd like as a part of the install process. It turns out I am not the only one speculating about that idea and it's not practical and feasible either as it's also breaking the security model.
It's been discussed recently at: [url=https://discuss.grapheneos.org/d/25899-ability-to-installreplace-privileged-system-apps-for-user-freedom/9]https://discuss.grapheneos.org/d/25899-ability-to-installreplace-privileged-system-apps-for-user-freedom/9[/url]
Another way on how to install an app on an android device would be using adb install from a computer. I am not definatelly sure on this but GrapheneOS does not allow enabling ADB on production builds. In order to instal a TTS app over ADB we'd need to find a way on how to install GrapheneOS with ADB preenabled on first run. This is a huge security hole as well.
There might be a way to build my own flavour of GrapheneOS, but that's too involved, I'd need very powerfull machine for the actual build process and I would again compromise security by either disabling or handling future updates on my own building each new release on my own.
So given the current state I am afraid we screen reader users are out of luck and there is no way to get this thing running on my own with no help from someone else.
The end result is that I'll either get security or I can look elsewhere to get accessibility.
Please am I getting it right or might I have overlooked something that might help me to install GrapheneOS on my own?
Thanks for reading to the end

2025-04-12 17:54:53 UTC

- reply

@[url=https://fosstodon.org/users/treefit]treefit[/url] Hmm, I can't get it to work no matter what I'm trying.
When I have started my $XDG_DATA_HOME environment variable was not set meaning it should fall back to the default ~/.local/share as per the XDG spec.
I have added it into my /etc/profile.d/0000-xdgdirs.sh file, rebooted, rebuilt delta-tauri with its dependencies but I'm still getting the same error.
Printing $XDG_DATA_HOME now gives me /home/myusername/.local/share, the directory does exist with 0755 permissions and it contains nested directories created by other apps on my system.
Is there a way to find out what the file path and the file name of the resulting log file should be?

2025-03-30 21:26:15 UTC

- reply

@[url=https://fosstodon.org/users/treefit]treefit[/url] I am using gnome 48. I guess I might be missing something as I can reproduce it with various head positions e.g. 364932abf or 76ca7442e.
I am using rustc 1.85.1 through rustup 1.28.1
I am trying to follow arch packaging guidelines.
I am exporting this variables:
[code]
export RUSTUP_TOOLCHAIN=stable
[/code]
And also I have experimented with
[code]
CFLAGS+=" -ffat-lto-objects"
[/code]

2025-03-30 20:46:49 UTC

- reply

Dear @[url=https://fosstodon.org/users/treefit]treefit[/url]
I am trying to build #[url=https://fedi.ml/search?tag=deltatauri]deltatauri[/url] on ArchLinux and I have issues running the resulting binary.
Upon launch it prints:
[code]
Failed to setup app: error encountered during setup hook: current logfile does not exist
[/code]
I am removing all the targets except of deb, then building like normal and moving files into place.
[code]
sed -i 's/"targets"\: "all"/"targets"\: ["deb"]/' packages/target-tauri/src-tauri/tauri.conf.json5
pnpm install
cd packages/target-tauri
pnpm tauri build
[/code]
Can you please think of where I am failing likelly? I can run binaries built elsewhere so I guess webkit-gtk and other dependencies are installed.

2025-01-18 20:57:20 UTC

- reply

@[url=https://mastodon.social/users/Davidsm]David[/url] @[url=https://fosstodon.org/users/treefit]treefit[/url] Looking into the #[url=https://fedi.ml/search?tag=aur]aur[/url] there's deltachat-desktop-git which I think you can edit to point to that release very easily.
[url=https://aur.archlinux.org/packages/deltachat-desktop-git]https://aur.archlinux.org/packages/deltachat-desktop-git[/url]

2025-01-08 20:59:35 UTC

Dear friends, #[url=https://fedi.ml/search?tag=screenreader]screenreader[/url] users, #[url=https://fedi.ml/search?tag=blind]blind[/url] users and #[url=https://fedi.ml/search?tag=accessibility]accessibility[/url] professionals in particular.
Are you using chat over traditional email as provided by #[url=https://fedi.ml/search?tag=DeltaChat]DeltaChat[/url] / #[url=https://fedi.ml/search?tag=DeltaLab]DeltaLab[/url] / #[url=https://fedi.ml/search?tag=ArcaneChat]ArcaneChat[/url]?
I like it uses traditional email infrastructure, is federated, supports end to end encryption, rich content including audio / voice messages. I have even recognized @[url=https://mastodon.social/users/adbenitez]adb[/url] has implemented screen reader accessibility specific features into the android app.
However I have quickly tried electron based app on linux with orca screen reader, exchanged a few messages back and fort between two of my personal accounts using the DeltaChat app and thunderbird and I haven't found the user experience verry appealing. I can't understand how to effectivelly navigate in the list of conversations and list of messages.
Therefore I would be interested to hear a few comments from people knowing this platform better. How accessible is it on different platforms?
On the desktop is the electron based app a prefered choice?
Also some other questions. For the best experience, do I need a new email address or can I use my existing self-hosted one I have already configured in thunderbird?
Ffeel free to point me to a FAQ, some up to date introductory documentation if you think my questions don't make much sense please.

2024-06-18 13:00:57 UTC

- reply

Yesterday I was running newton all day long. And all these tests were made with it. Today I am back to stable versions so far as I had to deal with inaccessible website about a hour ago.
I don't want to sound rude in any way but if I was able to do a little recap I can point out these issues related to newton prototype:<li>I am afraid there might be some invisible content present when using flat review.</li><li>Expanded or collapsed state is not passed through to orca (tested with fractal room list)</li><li>When running GTK4 from the accesskit branch, there are issues selecting GTK2 and electron based apps in the alt+tab window chooser.</li>
These are the things I am aware of.
If you need me to test something more thoroughly, please do let me know and I will try to do my best.

2024-06-17 18:46:39 UTC

- reply

I took a look at more apps that have lists as their integral part. Audio player #amberol has a playlist where its list items would benefit from calculated accessible names. gnome-podcasts looks as if it's already doing what we need the items have all the text from their children. I haven't looked how they are doing it though. Various lists within the gnome control center would also benefit from the accessible name calculation as an alternative to setting accessible manually. For example list of wifi networks is missing state information and signal strength. List of bluetooth devices is missing the state information. List of apps under notifications is missing a status information. List of keyboard shortcuts is missing assigned shortcuts, only action names are part of the accessible name. List of printers has all the details including status, location, description. Actually this might be the only list I am surprised looks about right to me. Hmm, perhaps I shal try to collect all these comments and submit it as a GTK feature request as calculating the labels might really be helpfull it seems.

2024-06-17 16:05:19 UTC

- reply

Hmmm, so it's even more complicated than I was imagining. I think what is done within the nautilus files view is not entirely right either. At the other hand projects with good a11y reputation such as thunderbird are doing it too. Thunderbird has aria-label on its message list items too. When looking at nautilus window with flat review or object navigation all the textual information is there. If using it the way it has been designed just using standard navigation keys such as arrow keys it's looking very poor.

2024-06-17 11:56:48 UTC

- reply

Yes with fractal this is the only issue that has left.
Related to the other thing that is not related to fractal Now I managed to find out downgrading GTK4 to the 4.14.4 as packaged in arch linux it helps with electron and GTK2 based apps not being focusable through the alt+tab window chooser.
Also have you noticed my post regarding nautilus and accessible name calculation I have posted to the orca list? This is not related to your work in any way so far. I am just wondering if accesskit wouldn't be able to make this part better than what we currently have while using atspi directly. In other words while calculating label of an accessible node should it walk its entire subtree?

2024-06-17 05:32:56 UTC

- reply

I managed to update. I can no longer reproduce freezes of fractal I mentioned yesterday and I can recognize the labels related change. Thank you so much.

2024-06-16 18:33:16 UTC

- reply

Thank you again, I've great news this time as well. After updating the newton_atspi_compat package the flat review with newton is working fine. With nautilus it started to work immediatelly when I've restarted orca with the updated newton_atspi_compat package in place. With fractal it started to work after restarting fractal.
Also I must say I have found my-self reporting a strange thing yesterday. I have mentioned I have tried gedit as a part of this testing however now I have realized gedit is a GTK3 app not GTK4.
When looking at gedit main window I can use orca's flat review to explore its toolbar including moving the mouse pointer and synthesizing mouse clicks. When doing the same thing with GTK4 apps such as nautilus or fractal the flat review is working great but emulating the mouse is not.
Excuse me for this mistake. I got it wrong.
And just now I have noticed another thing. I wanted to verify the mouse emulation features by running gtk-demo app which is GTK3 app too. I have tried to run gtk-demo from the gnome-terminal. As it has started I have noticed orca briefly reporting GTK demo however I can't focus its window. When holding down the alt key and pressing the tab key to cycle through the open windows, I can hear GTK Demo is part of the window switcher but when releasing both the keys that window is never brought to the foreground. When expanding activities from the gnome top pannel I can't locate GTK demo either. The very same thing has happened to me with an electron based app called losslesscut but originally I have assumed that was a momentarily thing related to electron but now when seeing it for the second time with a different toolkit I am wondering if this might be related to the mutter changes.
I am sorry for mentioning too many things. For some of these I am really unsure so if it's not relevant please ignore those parts.

2024-06-16 16:08:09 UTC

- reply

Hmmm, I can't really think of what else to try. I will also rebuild the same version of GTK4 their are shipping on arch linux out of interest just in case.

2024-06-16 15:05:40 UTC

- reply

I apologize for the delay.
Good news first:<li>text review and text selection for GTK labels is now working on both atspi and accesskit respectivelly. Huge thanks!</li><li>Restarting orca while GTK4 app such as nautilus, gnome-calculator or fractal is in the foreground is now safe. I see no more exceptions when releasing keygrabs on exit.</li><li>This is true from the moment I have started testing this yesterday I have just forgotten to mention it. When key echo is enabled in orca with newton it correctly handles accented non ascii characters while typing. I have tested web content in firefox and chromium, gnome-terminal, libreoffice, gedit, nautilus and fractal.</li>
And now the rest:<li>After todays orca update flat review now just displays window title for me for example name of the folder that is opened in nautilus. I think I have updated everything correctly but I can double check it later today.</li><li>Reporting expanded / collapsed state is really an accesskit integration issue I am afraid as switching to atspi on the same GTK4 version I am getting these reported fine.</li><li>Before starting this yesterday I was using GTK4 4.14.4 as packaged in archlinux. That version has some positive and some negative changes as well than the version you have started with while integrating accesskit. For example the thing with conversation history in fractal I have mentioned in my previous report is broken with GTK4 4.14.4 as packaged in arch linux but it's working fine with both atspi and accesskit when using your branch. Thus I think it's not related to your work. At the other hand in fractal there is a message composer which has some buttons that inwoke a popup menu such as more options. When that menu is dismissed fractal freezes with atspi and accesskit when using GTK4 built from your branch and with the arch linux packaged GTK4 version it's working fine.</li>

2024-06-16 11:02:36 UTC

- reply

Thanks for the updates. I'm rebuilding now. I'll report back soon.

2024-06-16 09:33:02 UTC

- reply

So I am back testing fractal and trying to compare how it performs with atspi and accesskit.<li>Fractal has tree of conversations on the main window. Root entries are room types such as explore, invited, favorite, low priority and similar. These items might have expanded / collapsed state. With accesskit this state is not yet reported.</li><li>When GTK4 label is focused, it's possible to use arrow keys to navigate with the caret on that label. With atspi orca is reporting caret navigation and text selection as it happens. With accesskit this is not yet working. I am not sure this might be an issue with the accesskit, newton prototype though, because with older versions of GTK4 this was not working either. Where can I put that environment variable to force atspi even with accesskit based build of GTK4? I am running this on the full gnome 46.</li><li>There is another reason why I think there might be difference with the GTK4 version I am running against atspi as compared to accesskit. Fractal has a list of room events called room history. Those are messages, files, recordings and other items found on the rooms timeline. With atspi this list is reported as room history and using up and down arrow key to navigate in this list does not cause orca to report items in this list as they are being focused. With accesskit this list is working perfectly.</li><li>With accesskit flat review is working in much more places including nautilus and fractal. With atspi orca freezes when trying to use flat review with these apps.</li><li>Flat review with accesskit feels damn snappy. Unfortunately I don't know how to prove it and make sure if it's for real or if this is a part of me being so much excited. Perhaps some control coordinates may need some refining or orca needs to be tweaked to the new way of doing things as the content now appears to be mostly presented on very long lines when using flat review. And also I think there might be some invisible content being presented as a part of flat review.</li>

2024-06-15 23:56:09 UTC

- reply

Fractal is very accessible on linux. They have specifically addressed accessibility issues in few recent releases. I think there are things to improve e.g. autocomplete of mentions, but I think the app is generally accessible and nice to use.

2024-06-15 23:34:56 UTC

- reply

Regarding windows that sounds fantastic. I imagine I might be able to recommend windows folks to run #fractal matrix client soon enough.
For building GTK with accesskit on windows do you use msis2 or gvsbuild?

2024-06-15 22:56:51 UTC

- reply

Yes, I made it work by rebuilding affected @npub13yw…77zg packages from your branches. Flat review, key echo, mouse actions are working fine with GTK4 apps such as gnome-calculator, gnome settings and similar. Even at this stage it's perfectly useable. Another bonus, The accesskit based GTK4 is also going to provide accessibility on windows. Am I understanding that right?
Things I have noticed so far:
* With at-spi2 based GTK4 GTK labels are mapped to the label role. With accesskit based implementation it's mapped to static.
* In nautilus when typing into the address bar with at-spi based implementation auto completions are reported as they are inserted. So text insertions / deletions are not yet available with accesskit I guess.
* When restarting orca and nautilus is the active window this newton based orca causes nautilus to freeze I guess.
Once again thanks for your dedication and awesome work.

2024-06-15 16:51:33 UTC

- reply

Woohoo, I have missed your instructions. I am just trying out if I can build it and play with it on my Arch linux install. Thanks for working on it.