Re: Widgets within widgets

That would probably be easiest to implement as the browser is just 
jumping tab stops in order. That said, what if I happen to use some 
other navigation such as jumping between headers or the like and end up 
on widget D. If I then shift tab should I end up in a widget nested two 
layers down inside widget A, which I've not even looked at before? I 
think that would be non-intuitive as I'd end up focused on some detailed 
control that is part of the larger A widget. My sense of place would 
probably get lost.

To contrive an example, what if widget A was some kind of calendar with 
a slider to zoom from year level down to hours level. So I shift tab 
from widget D and land on the zoom slider instead of the calendar 
widget. Will I have enough context to realize this? If we assume this is 
not ideal behavior, how could the browser figure out that we want 
macro-level tabbing vs. jumping to every sub-widget? I suspect this is 
going to be a case where the widget author is going to have to capture 
the tab key and move focus to sub widgets when present or take its sub 
widgets in and out of the tab order. Only the widget would have enough 
knowledge about its contents to give this kind of user experience, 
assuming this experience really is desirable.

CB

Joseph Scheuhammer wrote:
>
>> Chris gives an example of A(C(D))B having TAB order: A, C, D, B
>>
>> What should the Shift-TAB behavior be when B is selected?
>>
>>  (a) the reverse of the TAB order: B, D, C, A.
>>  (b) or depth first traversal from the end: B, A, C, D
> My intuition says (a).  If you have tabbed from A to C to D and 
> finally to B, and you "want to go back one tab stop", "D" is where you 
> just came from, so "D" is where you go back to.  Two Shift-TABs in a 
> row take you two tab stops back to C, and so on.
>
> Is this issue that Shift-TAB takes you back one step vs. that it 
> completely rewinds to the beginning?
>

Received on Wednesday, 2 July 2008 20:10:54 UTC