[Bug 201561] New: KDE Accessibility is a _MAJOR_ PITA

Andreas Mohr andi at lisas.de
Sun Jul 26 13:51:02 BST 2009


https://bugs.kde.org/show_bug.cgi?id=201561

           Summary: KDE Accessibility is a _MAJOR_ PITA
           Product: kde
           Version: 4.2.4
          Platform: Debian testing
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: crash
          Priority: NOR
         Component: general
        AssignedTo: unassigned-bugs at kde.org
        ReportedBy: andi at lisas.de


Version:            (using KDE 4.2.4)
OS:                Linux
Installed from:    Debian testing/unstable Packages

keywords: keyboard input evdev hal accessibility

Hello all,

I'm sorry for this bug title, but I'm afraid I'm foaming (see below).

Mandatory WARNING: this report is not for the faint of heart, it's probably my
most aggressive one (which perhaps might not be saying much ;).

I'm writing this bug report since this is the _second_ or even _third_ time on
some machine in recent years where the keyboard was always completely acting
up, with no way in hell to figure out what to do to fix it.

The first occasion was (as I remembered just now when looking at a bug report)
due to "Slow keys" accessibility feature.
It took me ages to figure out why certain control keys were not working
properly, I even killed my live session due to this since I was unable to
figure out why certain combos were not working.
...until I finally somehow stumbled upon the activated "slow keys" setting for
being the reason of this major problem.

The second occasion was now (quite a bit more than a year later) when my
desktop started acting up few months ago. It would randomly not work with
control keys.
Symptoms would be:
- unable to click on dialog buttons (due to Control being active at the same
time)
- accidentally logging out of Shell sessions (e.g. Ctrl-D), killing whole parts
of texts in various editors and scrambling to hopefully get it back via Undo or
so
- etc. etc.pp. (many more)

Fixing that broken key state up was attempted by randomly pressing various
control keys (Ctrl, Shift, Tab, Home, etc.), and that often (not always!)
worked, depending on whether you hit the correct key or not.

Picture some weeks later when my netbook was starting to exhibit exactly the
same symptoms, with no hint as to what might have changed, leaving my puzzled
with lots of swearing and lost work due to bogus keypresses.

What was the problem? Tadaaa, KDE Accessibility, but the "Sticky keys" setting
this time.



So, what do we have?
We have a very nice "feature" to be used by a select 1.1% of the population
which can be activated randomly (e.g. by pressing keys for a very long time, or
- especially - by having small children in the house which like to pop up
dialogs randomly) and can usually NOT be deactivated equally randomly/easily,
PLUS a state or information about this heinously activated feature is NOWHERE
to be seen in the entire KDE default desktop, EVER.
This not being enough yet, this feature is also suspected in some bug reports
(and Yours Truly has experienced the same thing, too) to _suddenly_ FULLY kill
keyboard access in some occasions, too (leaving you scrambling to get keyboard
input back via systemsettings areas such as keyboard/mouse input, display
settings or accessibility reset to default or so - changing display resolution
finally got it back in my case).


Given all these issues, I'd say KILL IT, and kill it FOR GOOD (use a knife or
shotgun if need be).

OK, granted I'm not quite as uncompromising, however I definitely request it to
be carried out exactly this way (and in the next KDE update even!) unless
there's a very convincing effort to thoroughly improve status reporting of
these sufficiently disruptive accessibility ""features"".

At a MINIMUM (if no easily visible status reporting can be implemented yet) the
inadvertent activation of these features via key actions and resulting dialogs
should be fortified by asking with a _second_ dialog "are you really sure you
want this?".
And since these actively malicious settings carry on beyond single users
(logging out will keep settings, dito with users which just walk over to some
machine just to be puzzled why that machine's keyboard is acting up), it's all
the more important to make sure there's a highly visible status reporting
somewhere.



There are various existing bug reports about keyboard accessibility, too, e.g.
- " keyboard stops working in kde" https://bugs.kde.org/show_bug.cgi?id=171685
- "keyboard changing to unwanted behaviour randomly."
https://bugs.kde.org/show_bug.cgi?id=121012
- "Kaccessibility - Slow Keys actually makes keyboard unusable"
https://bugs.kde.org/show_bug.cgi?id=164570


I'd say KDE Accessibility isn't a feature, it's a misdesign, and should be
treated as such.

https://wiki.ubuntu.com/X/Troubleshooting/HalBreaksKeyboardAndMouse might be
useful, too (I'll add a hint about possible KDE Accessibility issues there,
too).


Ironically Windows has the very same issues (having global color accessibility
setting activated causes cell background colors in Excel to get lost entirely,
with no reason for this to be identified anywhere), but... I thought we were
striving to be much better than Windows!? But after KDE 4.0 (Vista II) I've
already made up my mind about this anyway. (ok, 4.2.4+ seems to be getting
really good after all...).

Thank you for listening,

Andreas Mohr

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Unassigned-bugs mailing list