Hi Florian, We actually use Guacamole under the hood at Assistiv Labs, so have given this a lot of thought. The limitations at https://assistivlabs.com/accessibility should translate to Guacamole.
At a high level, Guacamole is very good at streaming remote audio. For connections to Windows over RDP, it mostly works out of the box. Audio is also supported on Linux or VNC connections (and even macOS with some hacking), but requires some setup on the remote machine with pulseaudio https://guacamole.apache.org/doc/gug/configuring-guacamole.html#audio-support-via-pulseaudio The Windows Remote Audio service is automatically created when an RDP session starts. Note that this service is disabled by default on Windows Server, it can be enabled via PowerShell. With it disabled, starting NVDA or JAWS will not result in any sound. I can't remember if starting Narrator would enable it automatically, that would be nice. Another quirk — if you happen to start NVDA before connecting via RDP (say in a startup script), audio actually won't work when you do connect (or at least this used to be the case) because the Remote Audio device wasn't present. You can fix this by installing a virtual sound card or waiting until after starting an RDP session to boot NVDA. I don't have much experience with how a local screen reader behaves with the Guacamole web interface unfortunately. The key thing once you enter a session is to make sure the input sink (captures all keyboard input) has focus. It could probably be a role=application, but I think it's either a normal textbox or perhaps aria-hidden=true today. Even though the approach of remote A/V streaming is prone to latency by nature, we had found Guacamole to be quite fast, but nowhere near as fast as a local screen reader. Best case latency might be 150-200ms between entering a keystroke and the start of audio output in response (don't quote me on that). Getting a refreshable braille display working would be an interesting challenge. I don't believe the RDP protocol has support for this kind of device passthrough. https://nvdaremote.com/ is a cool alternative to A/V streaming. It connects a local and remote NVDA instance over its own network socket, just transmitting NVDA commands and output. So it should be much, much faster and I believe supports braille displays. Hope that helps, On Tue, Apr 30, 2024 at 10:51 AM David Lomas <d...@pale-eds.co.uk.invalid> wrote: > We’re using RDP with Guacamole and bi-directional sound. I don’t think the > remote host even needs a sound card, depending on the RDP server. In MS, a > virtual audio device called Remote Audio is created and that’s what the > remote apps see as the default sound output. I’ve not tried it with screen > readers, but no reason why that wouldn’t work as far as I can tell. > > On Tue, 30 Apr 2024 at 18:13, Florian Beijers <florianbeij...@gmail.com> > wrote: > >> Hi, >> >> I had a quick browse through the manual but wasn't able to definitively >> get an answer to this question. >> I am looking into the accessibility of Guacamole-hosted virtual machines. >> These are used a lot in various IT-related training platforms (INE, THM, >> etc.) and therefore are pretty prevalent in places where people who are >> dependent on accessibilityfeatures might find them. >> For some context, screen readers (and various other assistive tech) work >> directly with the APIs of the OS that hosts them in order to work. They >> have practically zero access to screens that bypass, or ignore, these APIs, >> which is the case in almost all forms of RDP, VNC, or other mechanisms that >> provide a video feed of a remote machine. THis covers Guacamole, through no >> fault of anyone. That is just how this stuff works. >> What I am wondering about is primarily to what degree Guacamole supports >> audio throughput from a remote machine. Because a screen reader on the >> local host can't read the remote host, the only recourse is to start a >> screen reader on the remote host in order to make the remote machine >> accessible to screen reader users, at least up to a point. >> I have brought this up with some of the earlier-mentioned providers and >> got some pushback, basically expressing uncertainty if Guacamole is even >> able to reliably transfer audio from the remote host to the browser window. >> So that is essentially my question. >> Is this possible? And if so, are there any gotchas one should be aware >> of? I'm aware of things like making sure the audio service is running on >> the remote host or making sure the remote host has a soundcard configured >> to output through, but it there something that needs to be explicitly set >> up on the Guacamole end? >> >> Thanks a lot, >> Florian >> >>
