> On 26 Jul 2009, at 23:54, Romulo wrote:
>
> > Hi there Gnome Usability people!
> >
> > My name is Romulo and im actually a gnome lover and a developer.
> > Some
> > days ago i decided to gave Empathy a try, because i was tired of
> > pidgin.
> > During the initial hours of use i noticed that when i pressed the
> > Next Tab
> > shortcut with the last tab selected it didnt cycled to the first
> > tab, same
> > issue hapenned with the first tab selected (pressing previous tab
> > shortcut).
> > Since nautilus, gnome-terminal, gvim and gedit (at least in my
> > Ubuntu 9.04)
> > do that (cycling), i though about the possibility to make it real in
> > empathy
> > too. It took me some mins to write a patch and attach it to the bug
> >
http://bugzilla.gnome.org/show_bug.cgi?id=589263 . Unfortunately it
> > didnt
> > get a commit because it doesnt look the "standard" or "expected" way
> > of
> > behavior. After some discussions with dino on #usability we though
> > that the
> > best way of knowing how to handle it would be asking the usability
> > people,
> > so here i am. Hope i didnt bothered and im looking forward to have
> > an answer
> > from you guys. Thanks!
>
> The HIG's guidance here is that keyboard focus should not generally
> wrap around any list of objects, whether that's tabs, icons, or items
> in a treeview, but should instead stop with a warning beep. This
> guidance originated from the accessibility team, as wrapping around is
> a potential source of confusion for assistive technology users who
> can't necessarily see that any wraparound has occurred.
>
> Unfortunately, as you've noticed, in practice there's a great deal of
> inconsistency in what apps actually do. One option would be to
> implement the stop-with-beep behaviour only when accessibility is
> turned on, and just wrap around when it is turned off. Another would
> be to always have the stop-with-beep behaviour, but allow it to be
> overridden with a second keypress in the same direction.
