A while ago I wrote about a somewhat complicated way to use Windows Quick Assist to connect to another computer for offering technical assistance that worked around the lack of audio redirection in the Quick Assist environment. That is, audio playing on the remote computer wasn’t heard on the local computer. I just discovered that audio redirection now appears to be supported with Quick Assist. I’m still learning what’s supported here myself so if you try any of this, be aware I’m writing from a couple of hours of trial in my personal environment.
If you are unfamiliar with Quick Assist, Microsoft has an article going over the basics of the technology and how to use it. The short version is that two parties load the Quick Assist app, one requests a code from Microsoft and provides that code to the other. The person receiving the code can then share their screen or optionally give the person who provided the code access to control their computer. This is a common solution used in technical support for example.
For the this post, consider the local machine the computer that obtained the code for sharing and where the person offering assistance is working. Consider the remote machine the computer that is sharing the screen and is being used by the individual requesting assistance.
In many support situations, the person running a screen reader on the local machine, would not have access to a third-party screen reader on the remote machine or even where they did, the audio. This is what has changed in my exploration. Yes you could use Narrator but again without audio, you obviously wouldn’t get too far.
The controls for the Quick Assist app read like a web page so for the most part using the app with a screen reader works well. There are some critical items to be aware of though.
When the code you have requested is received, it does not appear to be shown as part of the web content screen readers read when a virtual (JAWS, browse (NVDA) or scan (Narrator mode is on. There is a copy button you can use to copy the code and paste it into another application for reading. If you toggle those virtual modes off, I also found that the code was read when tabbing as part of the name of a region on the page. I’ve shared feedback to Microsoft on this.
The biggest challenge is that you are not able to request full control for the remote computer until screen sharing starts. Once it does, a button to request full control will appear on the local computer.
In my experience, this is where things get a bit complicated. Keyboard focus seems to get stuck in a window for screen sharing. You may experience this as an area named Input of some sort. So far to activate the request Full Control button, I have had to resort to using a screen reader’s optical character recognition feature to locate the text of the request button and issue a mouse click. Again, I’ve been exploring this for just a bit now, so if there is a better way to do this, I’m not aware of it as of yet.
Once you do get the Request Control button activated, the person at the remote computer needs to accept the request. From that point, focus will likely go back to this remote input area and you will be controlling the remote computer. If this doesn’t happen automatically, tab a couple times and it likely will.
At this point you are basically running under remote desktop in a non-full screen mode on the remote computer. This means that shortcuts such as alt+tab, or Windows key combinations will go to your local computer. You can bring up the start menu in this configuration by pressing Alt+home and switch between running apps with Alt+Page Up or Alt+Page Down.
Better yet, the hotkey of CTRL+Alt+Pause will toggle the remote session between full screen and not. When in full screen, the hotkeys such as Alt+Tab and Windows key combinations go to the remote computer. Just press that same combination again to allow those keys to control your local computer. I’m not sure what combination will toggle where the pause key, which is typically to the right of the scroll lock on a full-sized keyboard is not available.
I’ve used Quick Assist with audio from both Win10 and Win11 machines for both the local and remote computer. I’ve successfully been running JAWS, NVDA and Narrator on the local machine and have used all three on the remote machine, including launching. Again in many situations the remote computer is not likely to have JAWS or NVDA and you probably wouldn’t be installing it there. My personal copies of JAWS are authorized for remote access so I do not know how that comes into play with JAWS working here.
As I said, I’m still learning what works but this is a welcome discovery for me, even with these issues. It opens up more possibilities to assist others.
Hello Mickey! Great post. But I have to wonder, why go through all those contortions when RIM is available?
It is a 100% accessible solution, pricing is good, free time available, I don’t get it…
Read about all things RIM https:://pneumasolutions.com/rim