Thin Client Networks was [gdm-list] Bringing back a11y

["Ian Pascoe" <ianpascoe btinternet com>]

Following on from Steve's point 3 below.

With the higher availability of interconnects and CPU performance, more and
more corporate organisations are moving to a thinner client infrastructure.
In addition, the cost benefits are also making the thin client ideal more
attractive to educational establishments.

With this in mind, what potential problems would this type of network
present to a user requiring AT style applications?

I know that Speech Despatcher works quite happily over this infrastructure ,
but what about the other AT applications?

Using LTSP as an example for Thin Client networks, they appear to offer a
number of different ways of logging into the network - would any development
as a result of discussions here be useable in a similar thin client network
setup?

Ian

-----Original Message-----
From: gnome-accessibility-list-bounces gnome org
[mailto:gnome-accessibility-list-bounces gnome org]On Behalf Of Steve
Lee
Sent: 08 February 2008 10:50
To: Brian Cameron
Cc: Matthias Clasen; gnome-accessibility-list gnome org;
gdm-list gnome org
Subject: Re: [gdm-list] Bringing back a11y


This is a fantastic discussion and many of my thoughts have been
covered already. Perhaps it is worth getting a bit more abstract and
thinking of a few scenarios so as to cover all uses.

1) Single user: They want their AT/a11y config(s) remembered at login
and beyond. Arguably some may  don't even want to login but I think
that would not be a good idea.

2) multi user: Each user will need a unique AT/a11y config for login
but don't know AT requirements until user is identified and at the
moment this means logged in.

3) clinical/education/corporate: support staff will want to configure
AT for individual users and ideally deploy remotely. Note here the
user is not directly responsible for selecting their AT/a11y.

Once better ways of identifying people arrive (biometrics, Near Field
Computing, RFID etc. etc.). then the problem gets simplified as a
users custom AT config could be automatically selected before
authentication (login).

'Till then the solution has to be to provide sets of configs that can
be easily selected before login, as discussed. Some predefined common
cases and the ability add more should cover the scenarios. A simple
list of named configs should be the simplest UI, with various gestures
to access.

As a bit of blueskying a 2 level system might work but it does seem
more complex and may be unworkable. I'm thinking of a course selection
for vis/mobil with simple gestures or selection by device used,  that
load ATs for selection of individual config using richer gestures.

It occurs to me that we really want a extra layer of gesture
abstraction where gestures on various devices (possibly more than one)
get mapped to actions in the OS and applications. Failing that we have
to map the gestures to standard input (key and pointer). The trouble
is input and output are never quite so decoupled, as in the case of
screen readers.

--
Steve Lee
--
Jambu - Alternative Access to Computers
www.fullmeasure.co.uk
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list