multiselectable tablist meets activedescendant

Hi all,

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 14:57:37 UTC