Re: [Evolution-hackers] About mail-composer's keyborad navigation

On 3 Apr 2006, at 15:02, guenther wrote:

Well, I don't know much about accessibility, especially what it is like to use a computer and being handicapped. But what is the big difference
between Ctrl-B and Shift-Tab? Or is there something like a dedicated
single key for Shift-Tab as well?

No, but also remember that Shift-Tab is only for cycling backwards... Tab should normally work for cycling forwards. Evo (and any other app where the main pane of the window is for text entry) is just a bit of a special case, where the text area consumes Tab for itself (in which case, Ctrl-Tab should work instead of Tab).

Interesting side questions:

* Why are we now jumping on this poor formatting toolbar?

FWIW, I'm not, personally :) I was just explaining how toolbar keynav is supposed to work, in general.

The Main menu
isn't reachable by Tab as well, neither in the main Evo window, nor the

No, at the moment we don't have any need to have menubars in the Tab chain, as they already have direct keyboard access in a cross- platform standard way (either by pressing F10, or Alt-<mnemonic>).

One of the options proposed for cycling through menus and toolbars was actually repeated pressing of F10-- I forget off-hand why we preferred just to have toolbars in the regular Tab sequence instead. (I think it may have been for consistency with Java/Swing, which was about the only other toolkit that offered keyboard access to toolbars at the time.)

So Toolbar navigation is supposed to work just like menu
navigation, eh? ;-)

No, I said it was supposed to work just like panel navigation, not menu navigation :)

* Shift-Tab gets you out of the mail body in the Composer, cycling
focus. But Tab does not. So Tab shall not be a valid char inside any
text field, just for the sake of focus cycling?

No, as I said above, Ctrl-Tab is supposed to work for focus shifting instead of Tab in that situation.

The GNOME Accessibility guide has a great chapter that explains all this, all widget developers should really be familiar with it:

I believe, there needs to be more research done. Is it really worth it
implementing this half-assed and working in a one-way direction now,
before a consistent way to do this is found?

Believe me, we've spent many, *many* hours in coming up with the current GNOME keynav recommendations, based on studying other toolkits, talking to users, and throwing in a bit of our own skill and judgement. I actually believe we have the most complete and consistent keyboard navigation story of any platform out there today. (Note I'm talking about widget level keynav here, not the Ctrl-X/C/V type stuff, about which there is always going to be arguments.)

Calum, please don't get me wrong. A11y is a good thing. Supporting
handicapped people is a good thing. But IMHO, Evo isn't particularly
good WRT keyboard-only usage currently anyway -- even from my POV.

I don't disagree there. But the good news is that for pretty much any given situation, we have a keynav specificaton in place that can be used to solve it pretty easily :) The standard gtk widgets already implement all this stuff by default; custom widget writers just need to (a) not break what they're getting for free, and (b) extend the existing keynav model consistently as necessary.


CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            Java Desktop System Team             +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]