Re: [Usability] Re: Keyboard navigation- outstanding issues

[Matthew Thomas <mpt mailandnews com>]

Calum Benson wrote:
>...
> Issue 1: Most support was shown for the idea of allowing the developer
> to choose whether tab characters should be allowed in individual text
> entry fields or not, by means of a flag or similar.

A single-line text field which requires use of Tab characters would
generally be as silly as a single-line text field which requires use of
newline characters, or form feed characters, or beep characters.

>                                                      If they're
> allowed, Tab key inserts a tab character, and [Shift+]Ctrl+Tab
> navigates out of the field.  If they're not allowed, [Shift+]Tab and
> [Shift+]Ctrl+Tab both navigate out of the field.

Ctrl+Tab and Shift+Ctrl+Tab should cycle through tabs or panels, if such
elements exist in the current window. (Tabs should not have access keys
themselves -- see below.)

>                                                   Default should be
> 'not allowed'. (Perhaps should be 'tab characters allowed' for
> multiline fields?)
>...
>                                              This way, Tab navigation
> works everywhere except for multiline text fields, which occur
> comparatively rarely in comparison to single line fields.  (And where
> they do, you often don't have to tab out of them anyway, if at all--
> e.g. email composer window, word processor).

Usually, yes. A word processor or text editor is an example of an app
where there's no other controls to navigate to, so the Tab key can
insert tab characters in the document itself. In an e-mail composition
window, where tabs aren't useful (use of them would cause `tab damage'
on the recipient's end), Tab and Shift+Tab would cycle between the body
field and the address and subject fields.

> Issue 2: Most people seemed to prefer the current proposal, i.e. Enter
> activates the window's default button unless the focused widget makes
> use of Enter itself (e.g. a multiline text field).  A suggested
> refinement was that if the default button is currently disabled, Enter
> should move focus onto the next control instead.

Moving focus to the next element is likely to be more annoying than
useful, especially since you're likely to be on the last text field when
you press Enter, and the next element is likely to be the `Cancel' button.

>...
> Caveat: This puts the onus on programmers to disable default buttons
> when appropriate, and perhaps even not provide a default button for
> some dialogs at all.  (An idea which becomes more bearable if we
> decide to assign mnemonics to "OK" and "Cancel" buttons, another
> suggestion that's been bandied around recently).
>...

Giving access keys for `OK' and `Cancel' buttons is bad for three reasons.

First, assuming that Enter and Escape will usually be supported as well,
the `There's only one obvious way to do it' rule would be broken; people
would waste time wobbling between the usual key (e.g. Enter for `OK')
and the access key (e.g. `O'), subconsciously wondering which one to use.

Second, since in most dialogs and confirmation alerts the main action
button should be context-sensitive (`Save', `Print', etc rather than
`OK'), the access key would be inconsistent between those cases.

And third, giving the buttons access keys would prevent any other
control in the dialog from using that access key, making things quite
awkward; for example, if a preferences dialog had a couple of dozen
different panels and the `OK' button had the access key `O',
*none* of the controls in *any* of the panels could use `O' as their
access key. This is also the reason that tabs should respond to Ctrl+Tab
and Shift+Ctrl+Tab rather than having their own access keys; giving a
tab an access key not only prevents use of that access key for other
controls in that tab, it also prevents use of that access key for any
control in any other tab.

There is one exception to the above. Where the main action button in an
alert or dialog is extremely dangerous (such as `Format Disk' or `Launch
Missile'), `Cancel' may be the default button, responding to both Enter
*and* Escape. In these cases, the main action button needs its own
access key to ensure accessibility.

-- 
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>