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

[Calum Benson <Calum Benson Sun COM>]

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
> Composer.

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:
http://www.gnome.org/learn/access-guide/2.10/ch03.html#keynav-1

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

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            Java Desktop System Team
http://blogs.sun.com/calum             +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems