- From: James Craig <jcraig@apple.com>
- Date: Thu, 6 Nov 2008 11:08:30 -0800
- To: David Bolter <david.bolter@utoronto.ca>
- Cc: wai-xtech@w3.org
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