Re: Issue #134 Tab states updated proposal

Hi Tab,

you wrote:

"Presenting something as a tabbed interface rather than as an ordinary
headers+sections document is a visual design choice.  You do interact
with it somewhat differently, but that can be handled from CSS and
magic as easily as it can from HTML and magic.  This proposal prevents
me from transforming a headers+sections document into a tabbed display
- I'm forced to choose the tabbed display up front."

Having a look under the hood of some tab widgets shows that they are coded
with the 'tabs' grouped separately from the panel contents. The use of a
list structure to group the tabs is also evident. Which is different from
the 'headers+sections' model you propose.

code examples
https://docs.google.com/document/d/1w1Q-oJlQwMcWmNrTelN32CA6WqxIzDSdDGAvximdBuU/edit

The issue is that a tabbed interface is not just a visual design choice, it
is also a semantic and interaction design choice and CSS does not provide
the means to meaningfully convey those choices to all users.

Instead of the current proposal what do you think of this

attribute example:

<article panel>
<header tab>
tab label
</header>
content
</article>

or this

element example:

<tabpanel>
<article>
<header>
<tab> tab label </tab>
</header>
content
</article>
</tabpanel>


regards
Stevef

On 16 November 2011 15:18, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Nov 16, 2011 at 3:53 AM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
> > Hi Tab, rereading your CP:
> >
> > you state
> >
> > "This is fundamentally a CSS issue."
> >
> > "The stated problem should probably be solved with CSS, as it is an
> > issue of presentation."
> >
> > From an accessibility perspective this does not seem to be the case [1]
> >
> > Most accessibility APIs have distinct roles for tab, tabpanel and tablist
> > and most platforms have distinct display features associated with
> > tab/tabpanel/tablists and also distinct keyboard interactions.
> >
> > Can you put a little more 'meat on the bone' as to why a fairly
> ubiquitous
> > interface design pattern with established semantics and interaction
> > behaviours should not be considered as something worthy of supporting as
> a
> > HTML feature?
> >
> >
> > [1] http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table
>
> Presenting something as a tabbed interface rather than as an ordinary
> headers+sections document is a visual design choice.  You do interact
> with it somewhat differently, but that can be handled from CSS and
> magic as easily as it can from HTML and magic.  This proposal prevents
> me from transforming a headers+sections document into a tabbed display
> - I'm forced to choose the tabbed display up front.
>
> There are further issues with this specific proposal (that may not be
> present in other proposals of this type):
>
> 1. Reusing <menu> and <command> is probably a bad idea.  We shouldn't
> be trying to duplicate the <input type> debacle - new types of things
> should get new elements.  The current types of <menu> all represent
> approximately the same thing, and are essentially just instructions to
> the UA about how it should be displayed or interacted with.
>
> 2. It's not clear what the meaning of non-tab commands are in a
> tablist menu, or how they can have a reasonable default presentation,
> or what tab commands mean in a non-tablist menu.  The fact that *none*
> of the existing command types are compatible with tablist menus is a
> strong indicator that you should not be reusing <menu>/<command> here.
>
> 3. Tabs are associated with their panels by id.  This makes it more
> difficult than necessary to have large numbers of tab stacks on a
> page.  A solution that embraced the possibility of a tabbed interface
> being a display choice over headers+sections interface could instead
> associate tabs implicitly, making this easier for authors and harder
> to accidentally misuse.
>
> 4. The change proposal still has the weird detail that UAs should
> "ensure that only the currently selected tab control is focusable",
> which doesn't make any sense to me.
>
> ~TJ
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html