control flow in tab collections, for example when changing tabs

References:
http://www.w3.org/WAI/PF/aria/#tab
http://dev.aol.com/dhtml_style_guide#tabpanel

Both the spec and the style guide say that the tab-list is single- 
selection:
one and only one tab is 'active' at a time.

The style guide says focus goes to the tab.

The spec says that the browser manages the identification of the  
active tab.
But that "There is no property in the taxonomy for this."  I  
interpret this
as saying "No, @aria-selected is not used on element.role='aria-tab' to
indicate this."  But one is left to wonder why.

Do we have different theories about where the focus goes?

I asked a moment ago how the user (from the keyboard)
gets the focus off the tab and into the tabpanel, should there be a
focusable item in there.

But I have to ask of the spec:  If the browser controls which tab is  
active,
and the active tab is supposed to control show/hide of the tabs and  
tabpanels,
but the script is responsible for the show/hide behavior; how does  
the CSS
or script know what the browser has identified as the active tab?  Or  
how
does the browser change show/hide directly as a function of the  
active tab
without violating our non-interference principle, roughly that ARIA  
processing
does not change the browser processing of the DIV?

http://www.w3.org/WAI/PF/aria/#ua_noninterference

If we follow the behavior stated in the style guide, then the script can
manipulate the tabbing sequence (in HTML, @tabindex) so that one and  
only
one of the tabs has a non-negative @tabindex.  Then the script and  
CSS can
key show/hide off the @tabindex, directly or indirectly.

But if the focus moves directly into the tabpanel somewhere, and the  
browser
chases up the ancestor chain to find an element.role='aria-tabpanel'  
and then
follows @aria-labelledby to find the associated tab, how does the  
browser
then indicate that this tab is the active tab?  Whether it manipulates
@aria-selected or @tabindex, in either case the browser will be changing
the DOM based on WAI-ARIA side-effect (behavior) rules.

I don't think we can entirely eliminate such 'managed properties'  
within the
DOM definition of the document and have a healthy universal-access  
design.

So this relates to ISSUE-47 on "who sets what properties when."

Al

Received on Thursday, 14 August 2008 14:25:34 UTC