GNOME.org
 

Re: [g-a-devel] Slow keys dialog

Hi Chris,

One more thing.  You write:


Using the system wide sticky keys means I need to have at least one
dialog box when my keyboard starts and is therefore completely
unacceptable.
Have you filed an RFE on this issue (seeking a way to invoke the system-wide Sticky-Keys functionality programatically without the user dialog box), or are you simply trying to "work around it"? I would hope that part of a SoC project is to at least file bugs/RFEs for things you want, even if you "work around them" for the purposes of meeting a project deadline. I would hope that filing bugs/RFEs is part of the purview of SoC projects. 

Regards,


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


Hi Chris,

I think there are two issues here.  Well, three:
1. Can an on-screen keyboard implement "sticky" modifiers without using the system support for sticky modifiers? 2. Can an on-screen keyboard circumvent/disable the system support for sticky modifiers (and slow keys, and...)? 3. Is the right way to "fix" what is "broken" in GOK doing another project rather than working with the existing GOK code to "fix" those "broken" things?
I suggest that #3 may be somewhat religious at this point; I'm personally saddened that we aren't at least looking seriously at GOK improvements, but fundamentally a goal of UNIX accessibility is to foster the development of a rich accessibility ecosystem - and a rich ecosystem has room for multiple approaches to similar problems (cf. Orca and Gnopernicus and LSR).
I have no issues with #1 - I see no reason why an on-screen keyboard cannot have its own way of making certain modifiers sticky on its own user interface *without* doing so through the system-wide setting mechanisms. Such a decision is I think a valid user-interface policy decision of an individual application.
However, it is a direct Section 508 violation for an application to override or ignore system-wide accessibility settings. It is even more egregious for an application that claims to be at least in part for people with disabilities (and thus an 'enlightened' application) to do so.
So, my suggestion is that if you simply cannot possible use the system-settings for sticky keys as part of your own UI, that you make things sticky your own way; however that if the system-wide settings are on that you use and respect those (complete with the dialog box that you seem to dislike). 


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


But this very same thing makes it very awkward who want sticky keys on
the keyboard and non-sticky on a physical.  Which would be true for
all non-a11y users and some a11y users.

In the end though the only manner it interferes with my keyboard is
the annoying dialogue that pops up, and the average  gnome-ally user
will probably be plenty used to seeing annoying dialogs anyway.

The slow keys dialogue however is another matter though.  Normal
operations are not resumed until it is dismissed.  Which in itself
incredibly annoying.

When planning the SOK I wanted to stay away from the three odd dialogs
that GOK pops up when it is started.  The plain fact is I don't want
any dialogs when starting SOK.  At all.

Using the system wide sticky keys means I need to have at least one
dialog box when my keyboard starts and is therefore completely
unacceptable.

On 26/06/06, Bill Haneman <Bill Haneman sun com> wrote:

On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote:

Chris Jones wrote:

...

In other words I cannot spend the summer making gnome-a11y suitable
for my needs.  What I need is a temporary work around until after the
SoC when I could find time to work on this aspect of gnome-a11y and
fix my program so it is not an "accessibility violation".

Chris,

Can you not simply make SOK remember that shift was pressed and keep the
state internally in SOK? IOW:

We tried this with GOK at an early stage and it was not satisfactory.
It also clashed badly with StickyKeys.  It doesn't make sense to build
an onscreen keyboard and then not expect disabled users to try and use
it, and they will rightly complain if it conflicts with StickyKeys.

If you really are unwilling to turn on the global StickyKeys gconf key
while the onscreen keyboard is posted, or at least when the pointer is
inside it... (and I really do not understand why this would be a
problem) there is XKB ABI which you can use to change the latch/lock
status of individual modifier keys.  This should do exactly what you
want without making StickyKeys active for the physical keyboard.

google for XKBlib.pdf to find the XKB client manual, I believe it's
section 10.6 that has the relevant client APIs.

regards

Bill


1. when the user clicks shift you set a flag. When a letter is clicked
SOK sends shift+<letter>+unshift to X and removes the flag.

2. When shift is clicked twice you set a sticky flag. Again, each time
the user clicks a letter, SOK sends shift+<letter>+unshift. When shift
is clicked again you unset the flag.

That way you avoid triggering slow keys and avoid making an
'accessibility violation'.

Bill, is it an accessibility violation to have unusable accessibility tools?

- Henrik

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list


_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]