[wp-hackers] Usability problems with accesskeys

Andy Skelton skeltoac at gmail.com
Thu Nov 10 19:12:43 GMT 2005

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.

> > 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 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>?
* 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.

Andy Skelton

More information about the wp-hackers mailing list