Re: [Usability] Re: Keyboard navigation- outstanding issues
- From: Calum Benson <calum benson sun com>
- To: usability gnome org
- Cc: gnome-accessibility-list gnome org, gtk-devel-list gnome org
- Subject: Re: [Usability] Re: Keyboard navigation- outstanding issues
- Date: Mon, 01 Oct 2001 13:19:42 +0100
Matthew Thomas wrote:
> 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.
Well, not exactly-- none of those characters affect the horizontal
formatting of a line of text, whereas a tab obviously does. (Which
isn't to say it's likely to be frequently useful, but I can think of at
least one common Windoze app that will remain nameless that requires
copious entry of "\t" in single-line text fields, where it would be much
nicer just to be able to press Tab).
> 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.)
This is already in the proposal. However, there are one or two
situations where Tab has to be used for other things, and in those
situations, Ctrl+Tab is designated (as it is in Java) as the "get me out
of this control" combination.
> 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.
Whether they cause "tab damage" or not, I can guarantee people would get
rather annoyed if pressing Tab while writing an email didn't insert a
tab and/or some white space. (Especially HTML emails, where tabs can
potentially be handled with a bit more sanity). Also, in an email
composition window, the address and subject fields also have mnemonic
access, so with the suggested proposal, people who didn't know they had
to use Ctrl+Tab instead of Tab to get out could do so that way 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.
But if you're on the last text field, the default button is almost
certainly never going to be disabled when you press Enter, since at that
point you'll have entered all the information required. You're right,
though, in that there would indeed have to be a mechanism in place to
ensure that you never hit the Cancel button this way.
> 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
Actually, you could equally argue it would re-inforce it-- what's so
"obvious" about OK being activated by Enter, and Cancel by Escape? Or
Tab moving between controls? They're just conventions that you have to
learn. At least by providing mnemonics, you remain consistent with the
rest of the interface (although pressing Alt+letter is another
less-than-obvious convention in itself).
> 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.
This is true. But again, Enter would still work, so you'd still have
consistency that way.
> And third, giving the buttons access keys would prevent any other
> control in the dialog from using that access key, making things quite
> awkward
Hardly "awkward", you just need to work a little harder. Vowels should
be your last choice for most regular controls anyway (other than those
where it's the first letter), as they're not really very, well,
mnemonic. So losing "O" to the OK button wouldn't be a disaster. ("C"
might be something to grieve about a little more strongly.)
> for example, if a preferences dialog had a couple of dozen
> different panels
If any dialog had a couple of dozen different panels, I would personally
shoot the person who wrote it :o)
Just to be clear then, could you briefly sum up what your solutions to
the two issues would be?
Thanks,
Calum.
--
CALUM BENSON, Usability Engineer Sun Microsystems Ireland
mailto:calum benson ireland sun com Desktop Engineering Group
http://www.sun.ie +353 1 819 9771
Any opinions are personal and not necessarily those of Sun Microsystems
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]