Hi,
Sorry for the late reply; I was afk for a week.
On 31.05.2011 08:25, Robert Ancell wrote:
On 05/27/2011 07:18 AM, Francesco Fumanti wrote:
Hello Robert,
You might remember that I already opened a thread about onscreen
keyboards, dwelling and display manager shortly before UDS-O. LightDM
being the default display manager for Ubuntu 11.10, I would like to
ask whether there is already a plan about integrating accessibility
features into LightDM?
A frequently asked question! Yes, we plan for the Ubuntu greeter to be
as accessible as possible.
...
As pointer-only users cannot use a hardware keyboard, they need a way
to access the onscreen keyboard by using only the pointer. Moreover,
there are pointer-only users that are not able to click with a
hardware device. These users need a way to activate automatic click,
also known as dwell click or hover click, by only moving the pointer
to a determined area/spot of the screen and resting there for a little
time.
For users able to click, the solution is straightforward: simply add
an item to the options/accessibility gui that the user can click to
open the onscreen keyboard.
For users not able to click, a dwellable spot, that enables dwelling
is needed. What about using the options/accessibility item itself as
the dwellable spot. It could for example work like this: The user
moves the pointer to the options/accessibility item and some sort of
bubble or notification area with a countdown appears. The bubble
informs the user that if he moves the pointer to a specific area of
the bubble, automatic clicking will be enabled. Advantages of this
approach:
- no additional exclusive dwellable spot is necessary
- if the user does not react to the bubble, nothing happens
- only one item has to be made dwellable in order to enable dwelling (*)
Or course, it should remain possible to open the options/accessibility
item as usual by a mouseclick.
Ubuntu is shipping an onscreen keyboard and dwelling software since
several releases with their default installation. Their names are
onboard and mousetweaks and both of them do NOT require at-spi to run.
So they can be started and used also when at-spi is not running.
(*) Another approach would be to open the options/accessibility item
after the timeout and add another dwellable item in the
options/accessibility menu/dialog to start dwelling. Meanwhile, I
think that marmuta's idea with the "activation area in the bubble" is
superior, as it only needs one dwellable spot instead of two. (marmuta
is part of the onboard devel team, Gerd is the coder of mousetweaks;
both are getting a copy of this email.)
My preference is actually to implement it this way. It would certainly
be simpler than providing the dialog.
So, if I get you write, you prefer to do it with two dwellable items: the
options menu itself and another item to enable dwelling in the options menu.
When doing it this way, I wonder whether the options menu should not popup
immediately when the pointer gets over it and close again when the pointer
leaves the popup area. In case it does not popup immediately, there should be
some feedback showing the passing dwell time.
Whether to open the options menu immediately or after a delay is a question
probably best solved with the ui design team.
The dwell item in the options menu should however only be enabled after a dwell
time has past (of course with a feedback while the pointer is resting on the
item waiting for the dwell time to pass). I suppose that this way it is less
disturbing for users that do not need the dwell feature.
I'm assuming this would only need to be done once, and as this setting
would be persistent between logins the cost of the double dwell would
only occur once. Do you think this is correct?
Yes, I think that it is correct.
The alternative with a single dwell was mainly to avoid having the developer
implement two items that are dwellable by themselves; it was not to save the
user from having to perform two dwell operations instead of one in order to
enable the dwelling feature.
The options/accessibility interface should not only provide a way to
start the accessibility tools, but also to quit them. Regarding this,
if I remember correctly, mousetweaks has a --login option; Gerd,
please correct me if I am wrong.
I'm not sure what you mean by this. The design will probably just have
a drop down list of accessibility options (much like GNOME shell) and
these could be toggled on and off.
Yes, that is what I meant: it should be possible to toggle the accessibility
options on and off.
Moreover, I wanted to let you know that mousetweaks has a --login command line
parameter for this. If I remember correctly, mousetweaks forks and goes to the
background if the --login parameter is not used; thus the pid returned when it
was started is not the final pid of the daemon making it more difficult to kill
by pid. Gerd (=mousetweaks developer), please correct me if I am wrong.
As far as I could read, LightDM aims to become a cross desktop display
manager; thus, I suppose that it should also provide a way for
distributions (and users) to replace an accessibility tool that
provides a specific feature with another providing that feature; for
example some distributions might want to replace the onscreen keyboard
named onboard with the onscreen keyboard caribou or florence or even
another one.
Finally, I suppose that the options/accessibility part of LightDM is
also a component of the greeter. Consequently, I wonder whether the
persons designing the greeter for Ubuntu are in part the persons
responsible for the addition of the options/accessibility items to the
display manager? Is there anybody in particular that should also be
contacted?
Actually the accessibility is entirely the responsibility of the greeter
(so each greeter will have varying levels of a11y). The Canonical
design team is designing the greeter for Ubuntu, and I will implement
it. I'm collecting requirements for a11y from discussions like this.
LightDM landed yesterday in oneiric. Could you please tell me whether the
greeter it is currently using already is the Ubuntu Unity greeter?
How you can help:
1. Open bugs for these requirements on this project
https://launchpad.net/unity-greeter
2. As soon as we have the Unity greeter first version, review it for
a11y and file bugs/send email.
The launchpad Unity greeter page you linked here above does not allow to file
bugs against it. I wonder whether this is because there is no package
associated to it yet. Could you please have a look?
Cheers,
Francesco
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
