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

[guenther <guenther rudersport de>]

> > Everything inside the formatting toolbar is accessible via the menu and
> > its shortcuts, most of them even have an accelerator. That formatting
> > toolbar never should get focus by tab cycling, IMHO.
> >
> >
> > While you are typing a mail (let's assume HTML) and want to bold some
> > part, just use Alt-M S B, or even simpler Ctrl-B. (Well, or use the
> > mouse, which likely was used anyway to select the part that's going to
> > be formatted.)
> >
> > Now imagine the formatting toolbar would be accessible using the Tab
> > key. That would be like 10 (ten!) times hitting Shift-Tab, then Space to
> > toglle it, and 10 times hitting Tab to get back to the body. Would
> > anyone seriously even consider this?
> 
> This isn't how toolbar keynav is supposed to work.  It's designed to  
> work like panel keynav, in that the toolbar itself is in the Tab  
> chain, not every control on the toolbar.  Once a toolbar has focus,  
> you use the arrow keys to focus items on the toolbar, space to select/ 
> activate them, and [Shift]-Tab to move focus out of the toolbar again.

That makes Shift-Tab, Right, Right, Right, Space, Tab for the above
example of Bold. As opposed to Ctrl-B or Alt-M S B.


> This is standard gtk behaviour these days AFAIK (see http:// 
> bugzilla.gnome.org/show_bug.cgi?id=54047), so if Evo isn't doing it,  
> we're delivering an inconsistent desktop experience wrt accessibility.

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?

Interesting side questions:

* Why are we now jumping on this poor formatting toolbar? The Main menu
isn't reachable by Tab as well, neither in the main Evo window, nor the
Composer. So Toolbar navigation is supposed to work just like menu
navigation, eh? ;-)

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

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?


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.

...guenther


-- 
char *t="\10pse\0r\0dtu\0  ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}