Re: [DHTML Style Guide] Tablist: Revision of Tab proposal

I'm changing my mind. If the user typically arrows among headers, and
then hits tab to enter a panel, then I can live with that expanding the
corresponding panel if it is currently collapsed.

cheers,
David
James Nurthen wrote:
> So where does this leave us regarding "merging" accordion and tab panel into a 
> single ARIA role? If there is a different method required to open the panel in 
> the accordion case vs the tab panel case then we will need AT to announce 
> something different when focus reaches this item or users will not be able to 
> operate the control.
> The current proposal does not give AT this opportunity as the single select 
> Accordion case does not have any properties which differ from the tab panel case.
>
> If we don't include the auto-expand capability we will also need to consider 
> what happens if the focus is on an unexpanded accordion header but there are 
> subsequent accordions already expanded in the accordion.
>
> regards,
> James
>
> David Bolter wrote:
> > Joseph Scheuhammer wrote:
> >   
> >>>>     * *Tab*
> >>>>           o When on an Accordion Header / Tab, each press of the tab key will
> >>>>             move the input focus in the following manner:
> >>>>                1. ...
> >>>>                2. Focus moves to the first interactive element in the Tab page
> >>>>                   or accordion panel. If the accordion panel for the currently
> >>>>                   selected accordion header is not visible pressing Tab will
> >>>>                   cause the accordion panel to expand.
> >>>>                3. ...
> >>>>
> >>>>         
> >>> Specifically, if focus is on an accordion header, and the associated tabpanel is 
> >>> not shown (aria-expanded = false), a Tab keystroke will open the associated 
> >>> tabpanel, and move focus to the first focusable item therein.
> >>>
> >>> Note on terminology:  "accordion" is a multi-selectable tablist; "tabbed pane" 
> >>> is a single-selectable tablist.
> >>>
> >>> After thinking about it, I don't think (2) above is right.  When a sighted user 
> >>> hits Tab, they usually have some idea of where they are going to end up.  They 
> >>> can see the next thing in the tab order.  If the accordion tabpanel is closed, 
> >>> the expectation would be to navigate to the next focusable visible item in the 
> >>> tab order.  Moving focus to something that is invisible would be jarring (even 
> >>> if it's made visible in the process).
> >>>     
> >>>       
> >
> > I agree on this point. If the user hits space and expands the panel
> > first, fine, tab can then move to/within the panel, but not otherwise.
> >
> > cheers,
> > David
> >
> >   
> h
>
> -- 
> Oracle <http://www.oracle.com>
> James Nurthen | Project Lead, Accessibility
> Phone: +1 650 506 6781 | Mobile: +1 415 987 1918
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood City, CA 94065
> Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed to 
> developing practices and products that help protect the environment
>
>

Received on Monday, 10 November 2008 20:21:01 UTC