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

Hi James,

Great question. To be clear, I don't think the method of opening a panel
should be different and didn't mean to imply that.

I think something lacking in all this discussion is an authority on what
an accordion is.  In various channels I've heard it described as one or
more of:

1. a vertical tab container
2. a tab container that allows multiple panels to be open
3. a tab container where the 'tab' is very married to the corresponding
'panel'
4. a musical instrument of questionable value

Unfortunately I think we'll have as much chance of agreeing on 1-3, as
we do on 4.  This makes discussion difficult and I think people are on
different pages. I think even if the W3C and xtech agreed on a
definition, we're still left wanting to provide semantics for all kinds
of these beasts.  I think we can go a long way with the roles 'tablist',
'tab', and 'tabpanel'... but we need to nail down the one or two blessed
keyboard interactions that can be used with either a "tabcontainer" or
an "accordion".  If we add a multiselectable property, well that will
allow us to express those tabcontainer/accordion-like widgets that allow
multiple open panels. If we want sighted and non-sighted collaboration,
well then we may to express things like the visual orientation...
perhaps an aria-alignment or something.

Also, what's happening with James Craig's proposal, and what is his
proposal?  see http://dev.aol.com/dhtml_style_guide#agenda

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 18:01:56 UTC