[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bugs-dist
Subject: [Bug 83053] accesskeys conflict with normal shortcuts
From: Germain Garand <germain () ebooksfrance ! com>
Date: 2004-07-12 1:07:06
Message-ID: 20040712010706.22479.qmail () ktown ! kde ! org
[Download RAW message or body]
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.kde.org/show_bug.cgi?id=83053
------- Additional Comments From germain ebooksfrance com 2004-07-12 03:07 -------
Hi Jean-baptiste,
I think your patch looks good, but that it doesn't solve the main problem : \
advertisement.
Accessibility is not an advanced feature, so people should be able to find the \
accessor intuitively.
Every HTML doc out there on the web advertise the accesskey combination as being \
Alt+<key>, so why not just use that?
If you have noticed, the normal Alt+key behaviour is very sane in case of conflict:
it simply cycle between all identical top level menu accelerators, popping them on \
the way.
So what would work nicely is as follow:
Given a keypress of Alt+Key_X
1) if no element has focus or currently focused element doesn't have a matching \
accesskey => look for the first element with access key "X"
- not found? let the event slip to the application for top level menu handling
- found ? => focus
2) else if an element has focus and has a matching accesskey,
=> look for next element with accesskey "X"
- no more? let the event slip to the application
- found ? => focus
and then you have a good, standard compliant, accessor cycling and no conflict.
What do you think?
Otherwise, your idea of popping all accessors at once is all fine, but again, people \
will have to know beforehand about the key... not sure they'll find out ;-( Anyway, \
that's rather a bonus feature for die-hard accessibility users, so that's OK if it's \
not obvious - provided it's documented somewhere.
[prev in list] [next in list] [prev in thread] [next in thread]