NVDA’s Upcoming Remote Access

Respected visiters,
Today I’d like to talk about a new thing of NVDA (Non Visual Desktop Access).
Writing a remote access solution isn’t easy as we may think it is. Based on
my experiments, reading MSDN (Microsoft Developer Network) articles and from
discussions with other NVDA developers, a good remote access solution will
require some significant investment from users, developers and third
parties.
As of now, the best remote access solution is to let remote NVDA tell local
NVDA what to say. This doesn’t require access to audio services and routing
audio from the remote end to the local user, useful in enterprise server
environments (I’ll go over technical material later). Here’s how it’ll work:
1. NVDA is installed on a remote computer.
2. The local user will start NVDA on his or her computer.
3. The local user will log onto the remote computer, and the remote NVDA
will try to establish connection with the local NVDA.
4. The local NVDA will send keyboard commands and other commands to the
remote NVDA, and remote NVDA will send messages (not audio) to be spoken by
local NVDA.
This is what the aforementioned add-on is trying to do (in essence). This
solution does not require audio to be routed and opens the door for
enhancements such as a local braille display being used to control remote
NVDA.
Now for our resident developers: Remote Desktop Protocol, being a derivative
of Citrix protocol, supports what’s called “virtual channels”. A local
application will communicate with a remote application via virtual channels,
sending data back and forth between them. This may include text (strings),
keyboard commands, audio, video and clipboard content.
In order for this to work with NVDA, the following must be done:
1. As mentioned above, NVDA must be installed on the remote computer (yes,
that is a must). We’ll call this “server” or remote NVDA.
2. The user must be running local NVDA as an installed copy (yes, that is a
must) since registry modification must take place. We’ll call this version
“client” or local NVDA.
3. A mechanism to send string messages back and forth between client and
server NVDA via virtual channels. There is a function in Windows API that
allows any program to detect that it is running under Terminal Services
session.
4. The new remote protocol for NVDA must be defined – its format, how
commands will be encoded, strings that server NVDA will send (speech
commands for now) and so forth). The remote NVDA must be able to “survive”
User Account Control (UAC) prompts and will need to work in secure screens.
Please let me know if anything is not clear in this article.
With regards from Inamuddin Secretary General Amigos Welfare Trust For The Blind Persons.

109 comments

Leave a Reply

Your email address will not be published.