03:46codebam: does using a vulkan layer perform better than using egl?
11:39tkna: Hi. Is there any way by design to get a screen reader (a system that reads text information aloud) such as Gnome Orca to work on Wayland, even through root privileges? A friend of mine gave up his longtime familiar Linux desktop because of the inability to use a screen reader on Wayland and started using Windows on QEmu. https://tech.lgbt/@xogium/110507457689374019
11:39tkna: That is almost the same as not being able to see the display for those who can see. Is there anything that can be done about it?
11:46ifreund: tkna: based on my understanding, this is an issue with toolkits rather than wayland. Gnome Orca uses dbus to communicate with applications it seems, none of the data going into Gnome Orca passes through Wayland...
11:48tkna: ifreund: Does that mean, by any chance, that screen readers such as Orca could be solved in principle if they were compatible with Wayland?
11:49mclasen: orca works fine on wayland
11:49mclasen: well, 'fine'
11:49ifreund: tkna: I'm saying that as far as I know, wayland has nothing to do with the operation of Orca
11:49mclasen: it has plenty of X assumptions built in
11:49colinmarc: I've never used a screen reader, but wouldn't it have to know the position of windows in the compositor space?
11:49mclasen: but that is mostly about input handling and global coordinates
11:49mclasen: all those things are in the process of being addressed
11:52tkna: ifreund, mclasen: Oh, I see. I thought that in exchange for thorough security measures, they were designed in principle not to be able to use screen readers, but I take it that is not the case?
11:53mclasen: screen readers are privileged clients
11:53mclasen: and they will have to use some private protocols to interact with the compositor
11:54mclasen: because making some of those things impossible for ordinary clients is very much a design goal of wayland
11:55Company: this is all not a technical issue, but an issue with manpower
11:55tkna: mclasen: I don't know much about orca, etc., as I have never used them, but I wonder if they are currently available in Wayland as well.
11:55mclasen: I can turn on orca on this Wayland system today
11:55Company: the accessibility community spent its available time improving the situation on Xorg and never got around to porting to Wayland
11:55Company: and the Wayland community spent its time improving Wayland and never got around to porting accessibility
11:56Company: and now accessibility doesn't work on Wayland
11:56mclasen: improvements on X is a nice of saying "try their best to slow the decay"
11:57mclasen: there is new a11y infrastructure in development
11:57mclasen: see https://blogs.gnome.org/a11y/2023/10/27/a-new-accessibility-architecture-for-modern-free-desktops/
12:01tkna: I see, so you are saying that Wayland is possible by design and there is a vision for its realization, but that it is currently not fully usable because screen readers are not ready for Wayland due to a lack of manpower.
12:03mclasen: some of the assumptions in 20 year old a11y plumbing are no longer valid in Wayland, and some people are hard at work to replace that infrastructure with one that is built from the ground up with Wayland in mind
12:03Company: "screen readers aren't ready for" sounds like this is a screen reader problem, but it's a whole stack problem
12:04Company: compositors, screen readers and the infrastructure are all having issues
12:04Company: and probably toolkits/apps, too - because once you touch infrastructure, they also need changes
12:05mclasen: yeah, the 'new a11y infrastructure effort' includes wayland protocols, compositor support and a new gtk a11y backend
12:06tkna: So there is no problem with Wayland's specifications, and if the screen reader is developed sufficiently, the visually impaired will be able to use the Wayland desktop through that screen reader.
12:07tkna: It is the screen reader that needs to be developed, not each application that needs to support a screen reader individually, right?
12:07Company: that's the goal at least
12:08mclasen: there needs to be some client-side support. the bulk of it goes into a toolkit, so apps don't have to care
12:08mclasen: but they do need to make sure their content is properly labeled, for example
12:13tkna: mclasen: Oh I see. You mean like an appropriate label for a screen reader to read. If a developer, who relies solely on sight, puts a label like “Button12” on an invisible part, a visually impaired person will not know what button it is. So the client needs to follow certain a11y or other rules to solve that problem.
12:13mclasen: yes
12:18tkna: I see. Unfortunately, it is currently unusable, but it is possible in principle, and the methodology and vision for a solution are largely in place. I understood that the rest will be solved someday depending on manpower and time.
12:19tkna: ifreund, mclasen, colinmarc, Company: I am relieved for the moment. Thanks for your kind words.
12:33tkna: > <Company> "screen readers aren't ready for" sounds like this is a screen reader problem, but it's a whole stack problem compositors, screen readers and the infrastructure are all having issues and probably toolkits/apps, too - because once you touch infrastructure, they also need changes
12:33tkna: Ah, I see. Is it a complicated situation with each of these problems throughout the whole thing, not just the sclin reader? It may take a lot of time, so for now we need to use X11, Windows, macOS, etc. I'm just saying that it will be done someday. Thanks.
12:34mclasen: "it will be solved" is the wrong attitude though - the situation can be improved if the people most affected by it become involved and work on it
12:37tkna: mclasen: Yes, I know. Sorry. Initiative is important. If users contribute, improvements will go faster. Thanks.
13:45mclasen: Company: its easy enough to determine "only foreground" for symbolics while handling the svg, and to write it back into the symbolic.png
13:45Company: (wrong channel)
13:45mclasen: grr
15:19sewn: were the roadblocks for openbsd support only the build process? or are there other factors to make it possible?
15:47wlb: wayland-protocols Merge request !309 opened by M. Stoeckl (mstoeckl) wp-fractional-scale-v1: warn about rounding calculation errors https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/309