Much like with the headers="" attribute, this was intentional, based on research into what tables on the Web actually looked like and what the expected UI of scope currently is and ideally should be.

Basically, it turns out that while one would intuitively think that hierarchical headers are a good design, they end up being more of a pain than a gain. By forcing a two-level structure, we make authors who are using scope="" think more carefully about what they want each cell to do and be in the table.

(In reply to comment #1)
> Much like with the headers="" attribute, this was intentional, based on
> research into what tables on the Web actually looked like and what the expected
> UI of scope currently is and ideally should be.
> 
> Basically, it turns out that while one would intuitively think that
> hierarchical headers are a good design, they end up being more of a pain than a
> gain. By forcing a two-level structure, we make authors who are using scope=""
> think more carefully about what they want each cell to do and be in the table.
> 

Here too Ian you demonstrate a severe lack of understanding of this issue. It does not matter whether the author thinks more carefully about what they want each cell to do, there are many times where data cells serve visually as headings for other data cells. This happens whatever HTML5 or any HTML says about tables. However, HTML 4.01 recognized that these tables exist and for the sake of the visually impaired it allowed the scope attribute to be placed on these data cells as well. Is HTML5 going to insist that authors place data in TH cells so that they can be associated with the scope attribute? All this does is reverse the previous advice of HTML4 that: when in doubt use a TD cell. Now we're saying when in doubt use a TH cell. To what end would we make such a change that would potentially confuse authors? What use cases are you trying to address in introducing this confusion? What problem statements have you contemplated that leads you to want to introduce this confusion? Can you point to a specific table where the data cells serving as headers cells are better marked up as TH cells than TD cells. To me it makes no difference, but why change it arbitrarily?

I don't this issue has been adequately dealt with and the resolution is unsatisfactory. The use of semantics has little to do with visual presentation of tabular data and it is vital that the working group seriously  considers the needs of non-visual users and that HTML 5 has sufficient semantics to make progamatic associations that help non-sighted users easily infer the correct relationships between content/table data.

Joshue, arguing that this bug should not be closed because it is tantamount to ignoring an accessibility need is missing the point somewhat. Hixie's statement in comment #1 is basically an assertion that there doesn't exist (a significant population of) tables that meet the criteria:
1) Use mixed header/data cells
2) Cannot be cast into an equivalent, but simpler, form that does not have mixed header/data cells

This bug is only an accessibility issue (or an issue at all) if those two statements are actually true. In particular 1) alone is not sufficient since a table that met 1) alone could be recast into a form that didn't used mixed header/data cells which would presumably be more accessible (since, per 2) it would be simpler and hence easier to understand for more people including those without visual access to the table).

Therefore if you want this bug or bug 5822 reopened, I suggest that you present real-life examples of tables that meet the criteria 1) and 2) above. 

(In reply to comment #4)
> Joshue, arguing that this bug should not be closed because it is tantamount to
> ignoring an accessibility need is missing the point somewhat. Hixie's statement
> in comment #1 is basically an assertion that there doesn't exist (a significant
> population of) tables that meet the criteria:
> 1) Use mixed header/data cells
> 2) Cannot be cast into an equivalent, but simpler, form that does not have
> mixed header/data cells

There is need for HTML 5 to have mechanisms to make complex data tables that are 1) accessible  2) conform to HTML 5. I think this issue is worthy of more consideration than seems to have been given here - seeing that it was open for all of 10 minutes. 

> Therefore if you want this bug or bug 5822 reopened, I suggest that you present
> real-life examples of tables that meet the criteria 1) and 2) above. 

Coming up with examples that meet the first criteria is easy. The second is completely subjective and therefore very hard to quantify. The argument could continue ad nauseum about whether the table /could/ be made more simple. Most can but thats not the issue really.

(In reply to comment #5) 
> There is need for HTML 5 to have mechanisms to make complex data tables that
> are 1) accessible  2) conform to HTML 5. I think this issue is worthy of more
> consideration than seems to have been given here - seeing that it was open for
> all of 10 minutes. 

The issue had been considered before the bug was opened when the data tables section was last updated, so the 10 minutes number is deeply misleading.

> 
> > Therefore if you want this bug or bug 5822 reopened, I suggest that you present
> > real-life examples of tables that meet the criteria 1) and 2) above. 
> 
> Coming up with examples that meet the first criteria is easy. The second is
> completely subjective and therefore very hard to quantify. The argument could
> continue ad nauseum about whether the table /could/ be made more simple. Most
> can but thats not the issue really.

From a purely accessibility point of view it very much is the issue because simpler presentations of the same data will be easier for more people to understand  particularly including those who can only interrogate the table one cell at a time  than a more complex presentation of the data. Therefore, for authors who care about accessibility the best possible advice is to make the table as simple and well structured as possible (authors who don't care about accessibility won't use anything as complex as the mechanisms described here anyway). 

I am very sympathetic to the idea that mixed header/data cells might be a necessary evil in some cases but until someone puts some work in to demonstrate that they are actually needed in some real life, there's no chance that the spec will be updated to allow for them. I'm sorry I can't offer the time to do the work but I'm already swamped with more pressing non-HTML5-related things at the moment. Having said that Ben Millard has probably done most of the hard graft here already with his "Collection of Interesting Data Tables". Fobbing off the need to do work with an argument that amounts to "even if I did the work, it would only cause debate about whether the feature I want is actually needed so instead we should just declare that it is needed" is pretty unlikely to be productive.

(In reply to comment #6)
> (In reply to comment #5) 
> > There is need for HTML 5 to have mechanisms to make complex data tables that
> > are 1) accessible  2) conform to HTML 5. I think this issue is worthy of more
> > consideration than seems to have been given here - seeing that it was open for
> > all of 10 minutes. 
> 
> The issue had been considered before the bug was opened when the data tables
> section was last updated, so the 10 minutes number is deeply misleading.

How is it misleading even slightly, never mind deeply? Come on. To mislead there must be intent. I am responding to an issue that needs a response. My intent is to further the discussion.

The issue I am sure has been discussed more thoroughly elsewhere (refs please) but the closing of the bug is not the end of it. As I said, I don't think it has reached a satisfactory conclusion and it seems to have been dismissed prematurely, without discussion.

> From a purely accessibility point of view it very much is the issue because
> simpler presentations of the same data will be easier for more people to
> understand  particularly including those who can only interrogate the table
> one cell at a time  than a more complex presentation of the data. Therefore,
> for authors who care about accessibility the best possible advice is to make
> the table as simple and well structured as possible (authors who don't care
> about accessibility won't use anything as complex as the mechanisms described
> here anyway). 

Yes, I wholeheartedly agree with you. However, we still need accessible mechanisms to deal with complex tables. It could be argued that much of the tabular data available in the wild goes not even need to be in a table at all.

>Fobbing off the need to do work with an argument that amounts to "even if I did >the work, it would only cause debate about whether the feature I want is >actually needed so instead we should just declare that it is needed" is pretty unlikely to be productive.

Neither is that comment. Its not like that, thats not the way I operate.

(In reply to comment #5)
> The argument could
> continue ad nauseum about whether the table /could/ be made more simple. Most
> can but thats not the issue really.

It seems to me that most accessibility arguments revolve around "could". And different people have a different view of what parts are constant and what "could" vary.

For example, Hixie *seems* to assume that when making a table more accessible, the choice of td vs. th for a given cell is variable, and that the overall structure of the table "could" be simplified to make it more accessible. You *seem* to be saying that the overall table complexity is not a part that "could" change, but then people "could" make adjustments to the scope and headers attributes.

Personally, I care more about "would" that "could". That is, having a means for marking up really complex relationships doesn't help much if the kind of people who make complex tables to begin with won't end up using the mechanism. I'm very skeptical of solutions that require an accessibility-specific layer of annotation compared to solutions that let accessibility come as a side effect of more general-purpose semantics. Intuitively, I'd go for a message of "make tables simpler and use <th> for headers" than for a message "make tables as complex as you like and then annotate them with headers/scope".

I've included an example of a data table from one of our clients (changing the names and using dummy values) [1]. The fields under the "Child Investment" header cell contain data. In HTLM 4.01, these should be marked up as a td, as although they are header cells for the row, they contain data.

With HTML 4.01, this is resolved by allowing the scope attribute on a td. How should this be done in HTML5?

[1] http://juicystudio.com/wcag/tables/complexdatatable.html

(response in bug 5822.)

I'm marking this as a dupe of 5822 since now that I understand the actual request it seems that they're basically just different manifestations of the same underlying purported problem.

*** This bug has been marked as a duplicate of bug 5822 ***

Per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html, the HTML A11Y TF does not plan to formally work on this issue at this time. This does not mean the TF has no interest in it, but does not have immediate plans to work on it. The TF may review the issue in the future.

This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, 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

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.