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

Hi Jon;

Inline, see the EJ's.

On Mon, Sep 15, 2008 at 1:47 PM, Jon Gunderson <jongund@illinois.edu> wrote:

>
> 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.
>
EJ    This occurs when the TABPANEL contains text also so more generically,
input focus always lands in the TABPANEL -except- when the the tab has input
focus. The styleguide doesn't appear to handle the later situation yet.

>
> So the best practices document is not in line with either of these models.
>
EJ   Agreed. The style guide [best practices doc?] should explicitly state
where input focus goes when a TAB is first visited. The same should hold
true on subsequent visits, if TABPANEL component is expected to place focus
on the last form element that had input focus.

        Something else missing for TABPANEL is how to get input focus from
the TABPANEL to the TAB and vice versa. Cntrl+up/down does this in Windows.
Right now there appears to be no way to give focus to the TAB so the result
is the arrow keys always work as expected [e.g. it likely fails if input
focus in a TABPANEL is on a text area or field]


>
> 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/
>
>
>
>


-- 
Earl
http://www.linkedin.com/in/earljohnson1
earlj.biker@gmail.com