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 <[EMAIL PROTECTED]> 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 > _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
