[wp-hackers] Usability problems with accesskeys

[Roy Schestowitz]

_____/ On Thu 10 Nov 2005 22:48:09 GMT, [Denis de Bernardy] wrote : \_____

>> They [accesskeys] make Web interfaces as productive as native
>> desktop software.
>
> I disagree with this statement. Unless I am mistaking, most people who
> actually use keyboard short cuts are fluent with computer programming.


I can't see the correlation. Persistence of use, not necessarily in a pro-
grammatic  context,  gives the motivation to favour keystrokes.  Have  you
seen travel agents and how they handle these repeatable queries? *grin*


> I
> meet highly educated people everyday who have 10+ years of experience using
> Word and Excel who have no clue how to copy, cut and paste using the
> keyboard.


I'd suggest a couple of possibilities:

*  Teachers or trainers should take the blame. I have seen people  copying
and pasting data using the context menus or, at worst, the main menu. This
reduces  productivity enormously if all you do is manage a spreadsheet  by
moving  elements  around and cannot drag-and-drop. In X11, you  need  only
highlight and use button2, so no need for the keyboard at all.

* (gross generalisation) People using Word and Excel have littler curiosi-
ty.  They  are less willing to *explore* a program, which refers  to  your
point above.


> Also, I personally find using Alt quite unnatural, when compared to Ctrl.
> Habit and the (un-)learning curve that comes as a result arguably are one of
> the reasons. More importantly however, the Alt key is not as conveniently
> located on the keyboard: Ctrl+X, Ctrl+S and Ctrl+Z all get pinky hits; their
> Alt+ counterparts do not. Alt+Shift combos do not either.


I  agree with you on that, but ALT (jointly with the mouse buttons) can be
used very heavily to control window position and scale. It has few reasons
to  be left untouched. CTRL+SHIFT combinations are becoming common. I have
collisions  with these (Thunderbird and XMMS). AmaroK goes as far as using
the Windows logo button.


_____/ On Thu 10 Nov 2005 23:55:02 GMT, [Mike Little] wrote : \_____

> Denis,
> You and others are missing the REAL point of access keys. They are for
> people who are using assistive technologies. For example, people who
> have shaky hands and cannot use a mouse very precisely. It is a big
> help to them if the tab order works correctly and they can use access
> keys to move around the various controls or just sections of the page.
> It is also important for people who cannot see the screen to be able
> to move around the page in a logical and convenient way. They cannot
> scan the page and click on the item they want to deal with.  They need
> to be able to jump around with the keyboard and tab from control to
> control.


These are also helpful when the mouse or motherboard go faulty. Many years
back  I was forced to tab my way around and realised that certain interac-
tions  were  not  designed properly. For example, to get  to  the  Windows
taskbar, a user needs to press the Windows logo, hit ESC, then TAB twice.


_____/ On Thu 10 Nov 2005 20:10:44 GMT, [Owen Winkler] wrote : \_____

> Andy Skelton wrote:
>
>> * Disable the accesskeys while the editor is blurred. Actually not
>> that hard to do.
>
> It's both the least difficult and the option I like best.  Fancy that.


I thought about it before, but it requires JavaScript. Then again, TinyMCE
has JavaScript as a fundamental pre-requisite.


_____/ On Thu 10 Nov 2005 19:12:43 GMT, [Andy Skelton] wrote : \_____

> Forgive me for not quoting everyone. The gist is this: I hate mousing
> the toolbar and I think you do, too. Hotkeys of one kind or another
> are just necessary. Accesskey is the easiest and lightest way to go
> but we must keep an eye out for key collision and user annoyance.


You  can never satisfy everyone. Choose keys that lead to 0 collisions and
users  will whine that they need to use two hands (e.g. CTRL+P) while bet-
ter  shortcuts  are available on their platform/browser. Choose keys  that
are  a  decent  compromise and signals will get devoured. Minutes  can  be
spent  trying to figure out why a certain function does not work. Finally,
it  turns  out that it is overridden by something obscure that  has  never
been used before and isn't conspicuous either.


>> > The browser needs some way of "capturing" special keystrokes when a
>> > textarea is selected, the users eyes are looking at the textarea, or
>> > some other magic way of knowing what the user wanted to do! heh.
>> > Donncha.
>
> This can be done by adding our own key-related event handlers to the
> ones already implemented in TinyMCE. It's several times harder to code
> but it's the most flexible method.
>
> It would be far easier to enable the existing accesskeys on editor
> focus and disable them on blur.
>
>> How   about  a  user-configurable  set  of  shortcuts?
>> Roy
>
> No. We do it right or not at all, IMO.


I suppose you are right. Yet another set of options leads to confusion.


> I think the best accesskeys are the ones already in TinyMCE core.
> There are only three and they simply focus on the three parts of the
> editor box. Our accesskeys do sometimes collide with browser shortcut
> keys. I am to blame for not knowing my own browser's shortcut keys!
> Also, I learned that Alt+p was already assigned to our Publish button.
> How about that? :-)
>
> Now, let's collect some solutions in one place:
> * Disable the accesskeys while the editor is blurred. Actually not
> that hard to do.
> * Use only upper-case accesskeys. Takes ten seconds to patch. Are
> there any collisions with Alt+Shift+<letter>?


Rarely.  None  that I am aware of, but if WayV was configured  in  certain
ways,  things  could go awry. If you chose that combination, you  probably
could not go right of the 'R', 'F' and 'V' on QWERTY.


> * Revert accesskeys and write JS to capture Ctrl+<letter> only within
> the editor. By far the most work to implement. Would there still be
> any important key collisions?
> * Develop a "safe" set of accesskeys with zero or very few important 
> collisions.
> * Code support and UI for custom accesskeys or JS-captured keys.
>
> Everyone concerned, please weigh in.


_____/ On Thu 10 Nov 2005 20:02:14 GMT, [Jason Bainbridge] wrote : \_____

> My vote would go for a combination of the first two options, disable
> the accesskeys when the editor is blurred and make them upper-case,
> I'm not aware of any existing ALT+SHIFT+<letter> shortcuts and a quick
> google didn't reveal any although interestingly it brought up Nestle's
> website (www.nestle.com) that uses ALT+SHIFT+<number> for menu
> navigation so it could already be some sort of defact standard to
> avoid collisions.

Nestle always have to be different. They actually patented coffee beer re-
cently. *smile*


Roy