EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Rationale: Tabs are a presentational effect that can (and in a number of cases is) be done in such a way as to be AT friendly. If standardised this could be better handled through CSS.

(In reply to comment #1)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the Editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the Tracker Issue; or you may create a Tracker Issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> Status: Rejected
> Rationale: Tabs are a presentational effect that can (and in a number of cases
> is) be done in such a way as to be AT friendly. If standardised this could be
> better handled through CSS.

I do not understand your rationale and basis for rejection. The intent is to create a semantic equivalent of this presentational effect and its state (e.g., active) that you refer to. Please clarify why it cannot be done.

(In reply to comment #1)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the Editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the Tracker Issue; or you may create a Tracker Issue
> yourself, if you are able to do so. For more details, see this document:
> 
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Rationale: Tabs are a presentational effect that can (and in a number of cases
> is) be done in such a way as to be AT friendly. If standardised this could be
> better handled through CSS.

Hi Robin, claiming it is a presentational effect appears to be at odds with every accessibility API which provide distinct roles to identify the semantic structures of tabs [1](tab, tablist, tabpanels) which are implemented across OS's and platforms. They are provided because almost all UI languages have tab widgets. tabs are not merely presentational they are UI controls and have a role and states and properties that cannot be handled by CSS. 

[1] http://www.w3.org/WAI/PF/aria-implementation/#mapping_role

(In reply to comment #1)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the Editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the Tracker Issue; or you may create a Tracker Issue
> yourself, if you are able to do so. For more details, see this document:
> 
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Rationale: Tabs are a presentational effect that can (and in a number of cases
> is) be done in such a way as to be AT friendly. If standardised this could be
> better handled through CSS.

Hi Robin, claiming it is a presentational effect appears to be at odds with every accessibility API which provide distinct roles to identify the semantic structures of tabs [1](tab, tablist, tabpanels) which are implemented across OS's and platforms. They are provided because almost all UI languages have tab widgets. tabs are not merely presentational they are UI controls and have a role and states and properties that cannot be handled by CSS. 

[1] http://www.w3.org/WAI/PF/aria-implementation/#mapping_role

For a CSS approach see:

http://lists.w3.org/Archives/Public/www-style/2009Apr/0298.html

(In reply to comment #5)
> For a CSS approach see:
> 
> http://lists.w3.org/Archives/Public/www-style/2009Apr/0298.html

doesn't ppaear to provide any info about how the semantics/states and properties of the tabs are to be conveyed or am I missing something?

(In reply to comment #6)
> (In reply to comment #5)
> > For a CSS approach see:
> > 
> > http://lists.w3.org/Archives/Public/www-style/2009Apr/0298.html
> 
> doesn't ppaear to provide any info about how the semantics/states and
> properties of the tabs are to be conveyed or am I missing something?

Don't think you are.

It's just an example of what a tabbing mechanism might look like in CSS. If this was added, mappings to accessibility API roles, states, and properties would have to be derived. If we also added markup for tab views that could use the CSS mechanism.

Not sure of the merits of tab views being expressed as part of the structure of the document/application rather than presentation.

Steve's concern is that semantics are needed for the controlling elements (e.g. tabs and tablist) versus the controlled elements (e.g. tabpanel). 

While I don't agree with Robin's statement that tabs are a presentational effect, the semantics mentioned in the CSS card-stack example are for the content sections (similar to ARIA's tabpanel role or a generic hidden/shown div) and may therefore only need to be marked as shown or hidden in the accessibility APIs rather than to have semantic roles or properties applied. 

Perhaps the confusion is that Robin should have said "card-stacks" rather than "tabs" are a presentational effect that can be used for semantic controls like tab panels, but in cases where the controlling elements indicate some additional functionality, it's the page authors responsibility to convey semantics through use of appropriate HTML elements or ARIA roles.

<with chair hat off>
I personally disagree that tabs are purely presentational.  While a set of panels where you show one at a time is a generic idea that could in principle be done with @hidden or with pure CSS, the tab strip and its relation to the set of views is clearly semantic, at least as much as a push button.

<with chair hat on>
Given where we are in the process with HTML5, and given that this is a new feature request, I recommend deferring this request to a future version of HTML.

(In reply to comment #9)
> <with chair hat off>
> I personally disagree that tabs are purely presentational.  While a set of
> panels where you show one at a time is a generic idea that could in principle
> be done with @hidden or with pure CSS, the tab strip and its relation to the
> set of views is clearly semantic, at least as much as a push button.
> 
> <with chair hat on>
> Given where we are in the process with HTML5, and given that this is a new
> feature request, I recommend deferring this request to a future version of
> HTML.

Hi Maciej, 

I was acting under the assumption that this was something being disucussed for html.next. Would be good if we could define a keyword that flags bugs for html.next. I realise we have a sperate product for it, but if bugs get filed or re-opened against the html spec then it would be helpful to be able to flag as html.next rather having to refile.

note this issue has been previously raised: http://www.w3.org/html/wg/tracker/issues/134 and marked as postponed.

(In reply to comment #10)

> 
> I was acting under the assumption that this was something being disucussed for
> html.next. Would be good if we could define a keyword that flags bugs for
> html.next. I realise we have a sperate product for it, but if bugs get filed or
> re-opened against the html spec then it would be helpful to be able to flag as
> html.next rather having to refile.
> 
> note this issue has been previously raised:
> http://www.w3.org/html/wg/tracker/issues/134 and marked as postponed.

You can just change the product to HTML.next. You can even do that right when reopening.

> You can just change the product to HTML.next. You can even do that right when
> reopening.

It is already categorized as HTML.next.

Mass move to "HTML WG"

Mass move to "HTML WG"

there's actually no css/html additons needed for that:

You can already do it by adding a (visually hidden) <input type="radio" aria-controls="tabpanelid"> to store the tabstate (along with the appriate role attributes)

An example page showing this approach can be found at http://freemen.be/examples/tabs_example.html

Tested to work in the current incarnation of all 4 major browsers.

A form field list (Ins + F5 in JAWS 13 / IE8 / Win 7) shows radio button controls as 'Tab 1 Tab' 'Tab 2 Tab' etc. A radio button control list (Ins + Ctrl + r) gives a list of radio buttons as 'Tab 1 radio button checked' 'Tab 2 radio button not checked' etc.
Where is the semantic equivalent for the active tab, unless the key word here is 'radio button checked'?
-Devarshi

(In reply to comment #15)
> there's actually no css/html additons needed for that:

You can already do
> it by adding a (visually hidden) <input type="radio"
> aria-controls="tabpanelid"> to store the tabstate (along with the appriate
> role attributes)

An example page showing this approach can be found at
> http://freemen.be/examples/tabs_example.html

Tested to work in the current
> incarnation of all 4 major browsers.

This draft extension proposes a number of elements and attributes for implementing tabs and other similar constructs:
http://bkardell.github.io/common-panel/

In WICG: http://bkardell.github.io/common-panel/