Re: Issue #134 Tab states updated proposal

Hi Steve,

Interesting. How do you see the attribute or element examples for 
<article> and <header> working where, for example, we have three 
articles that we want to render as a tabbed interface? Would there be 
some element and/or attribute that serves to group them as part of the 
same tabbed interface?

Given a few of the arguments against it, it may be that extending <menu> 
and <command> may not be as flexible an approach as desired. I think 
that the main intention behind the original proposal is to have a way in 
HTML5 to natively produce the very common tabbed interface design 
pattern that, as you suggest, meaningfully conveys (visually and through 
accessibility APIs) to all users the state and functionality it 
involves. As such, if there's a more reasonable way to do this, then all 
the better.

Jason


On 19/11/11 12:00, Steve Faulkner wrote:
> 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
>>
>
>
>

-- 
Jason Kiss
Web: www.accessibleculture.org
Mobile: +64 021 929 238
Email: jason@accesscult.org
Twitter: @jkiss

Received on Tuesday, 22 November 2011 06:27:04 UTC