Re: multiselectable tablist meets activedescendant

A related implementation problem just occurred to me. Prior to this  
change, tab sets could have only one active tab panel at a time, so  
navigation from the tablist to the open tabpanel could be achieved  
with one stroke of the TAB key. Likewise, navigation back to the  
tablist could be achieved with a single SHIFT-TAB.

With a multi-selectable tab set (like an accordian), multiple panels  
can be open at once, so how does/should the user navigate from the  
tablist to the last open panel? Would they TAB past the list, and then  
have to cycle through all the potentially-open panels? For example, in  
case 4 below, if the user selected tab-b (opening panel-b and leaving  
panel-a open) then the user would have to TAB from the tablist, past  
panel-a, to reach panel-b. Depending on how many panels were open,  
that could mean a different number of keystrokes each time you moved  
to the last open panel.

In your conclusion you mentioned that "the activedescendant of a  
tablist should point to the id of … the corresponding tab of the panel  
with focus." In case 4 below, if panel-b were opened and the user  
navigated to it, the activedescendant should be tab-b. Agreed.  
However, in order to get back to the tablist, the user would have to  
SHIFT-TAB past panel-a, which would change the tablist's  
activedescendant to tab-a, so that when you got back to the tablist,  
tab-b would no longer be fudge-focused, correct?

Seem like there ought to be a consistent way to navigation from a tab  
directly to its panel, and from a panel directly to its tab. Perhaps  
selecting a tab should cause focus to jump directly from the tab to  
the tab panel? Perhaps we should place all tab panels in an element  
with role="group" that maintains a single fudged-focused tab panel via  
activedescendant on the group? So, navigation between tab panels  
should always happen via the tablist.

James


On Nov 6, 2008, at 6:57 AM, David Bolter wrote:

> I'm looking for feedback. I have a PFWG action to look at
> multiselectable tablists and related issues associated with
> activedescendant. This is my own fault :)
>
> Background: rather than have a new role of 'accordion', we are going
> heading in the direction of expressing typical accordion-like behavior
> by adding a multiselectable boolean state to nodes with role  
> 'tablist'.
> Let's now consider how the optional state 'activedescendant' might be
> used in this situation. Since activedescendant typically allows one to
> fudge the appearance of focus, I will call this kind of focus,  
> fudged-focus.
>
> Given a tablist with tab-a, tab-b, tab-c, panel-a, panel-b, panel-c I
> explore a few cases and propose what activedescendant would be in  
> each case.
>
> case 1: fudged-focus appears on tab-b, and panel-b is shown
> proposal: activedescendant='tab-b'
>
> case 2: fudged-focus appears on tab-b and panel-b is not shown  
> (perhaps
> showing the panel requires an activation via enter or space key on  
> the tab)
> proposal: activedescendant='tab-b'
>
> case 3: focus (or fudged-focus) is in panel-b, but panel-a is also  
> open.
> proposal: activedescendant='tab-b'
>
> case 4: fudged focus appears on tab-b, but only panel a is open.
> proposal: activedescedant='tab-b'
>
> So, in any event, the activedescendant of a tablist should point to  
> the
> id of either: the tab with fudge-focus, or the corresponding tab of  
> the
> panel with focus. I think this covers all cases pretty well.
>
> For those following along closely... what I'm not sure about is case  
> 3,
> and whether a focus event for the fudge-focused tab should get fired.
> For example, if real focus was in panel-a, and then somehow moved
> directly to panel-b, we, the DHTML authoer would update the
> activedescendant for the tablist to 'tab-b', but would we the browser
> developer want to fire a focus event for this?  If yes, then perhaps  
> we
> should fire it before the focus event for the panel...
>
> Thoughts?
>
> cheers,
> David
>
>

Received on Thursday, 6 November 2008 19:09:11 UTC