RE: control flow in tab collections, for example when changing tabs

Al had asked about keyboard focus in tab panels.

http://test.cita.uiuc.edu/aria/tabpanel/tabpanel1.php

A couple issues:

1. Typically focus is on a control in the tabpanel and the relationship for the TABPANEL that is visible and the TAB is the use of the "aria-labelledby" attribute.  The browser can calculate which TAB is associated with the form control with focus on the TABPANEL.

2. In my example when a form control has been selected in a panel, the panel remembers this control so if the user uses control+PageUp or Control+PageDown the focus returns to the last focused control in the TABPANEL.  

But this is not the behavior of Microsoft Windows, Windows seems to always to move keyboard focus to the first control in each TABPANEL, so focus is never really on the TAB items.

So the best practices document is not in line with either of these models.  

Jon





From: Al Gilman <Alfred.S.Gilman@IEEE.org> 
Date: Thu, 14 Aug 2008 10:24:51 -0400
Message-Id: <A6045CF9-5B68-4E92-BA28-075492B2F0CF@IEEE.org> 
To: W3C WAI-XTECH <wai-xtech@w3.org> 


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
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821

Voice: (217) 244-5870

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

Received on Monday, 15 September 2008 20:47:45 UTC