I (a sighted person) have often tried to figure out when buses start/stop running. If that 4 to midnight is true, then I want it not only visible, but emphasized. More likely, it is true for some routes, but midnight will be long past the last departure for other routes, or at least some stops… and so the information misleads.

I would hope that the fact that the bus stops are along the top row would be available from column headers; I realize that they might not be. (But this isn’t obvious to a sighted reader either — I usually figure it out from the contents of the cells.)

I could see some value in saying “buses run less frequently after 7pm”, but that is again something I don’t take in visually. On *some* schedules, I notice the change because the color changes, and then I try to figure out why, but I would still be happier if they just told me.

-jJ

However some tables are so simple that a summary might not be required: remember @summary is an optional attribute – the ‘heads up’ I speak of would not always require additional action: the advisory however would ask you – content author- if there “might” be a need to do so.

The caption however is different, and is usually displayed on screen: it should describe the “what” of the table, and is useful for all users: an example of caption would be "Schedule for Bus Route 7"

But that again brings up the problem of needing more good examples. My tables almost always have a single row of th cells along the top. The first column may be (but isn’t always) entirely th cells. There are no other th cells.

Should I really add a caption that is just a repeated (and therefore error-prone in case of revisions) version of the table headers?

If so, that is so unexpected that it needs to be said explicitly.

-jJ

As for having the UA auto-summarize a table and convey that information to users who cannot see (and thus discern) the totality of a complex table is a great idea; unfortunately at this time that is a fantasy wish – I am unaware of a User Agent today that can deliver on that ideal. Do you have proof-of-concept that illustrates how that might be achieved? Hopefully one day that will emerge, and that will be a great day, but that day is not upon us yet.

More importantly however, I think you missed the first paragraph of my blog post – @summary is and was simply a Talisman for a larger issue that needed to be addressed: the process by which the HTML5 specification is crafted. The input of all parties must be judged by the community, and not entrusted to one person to act as the gatekeeper. W3C process requires consensus (which often requires some compromise) and that was not happening. It is starting to happen now, and I believe that HTML5 will be that much better for it.

There’s definitely a lesson to be learned about compromise in here. The key difference between Maciej’s text and Hixie’s previous draft, is that Maciej’s text is couched in positive rather than negative terms. Instead of saying “don’t do X, do Y or Z”, it says “you can do X, but hey, look at great solutions Y and Z, which if you can use, do so because that will be better for everybody”

Saying “don’t do X” is confrontational and naturally puts people’s backs up. It’s much harder to object to positive language that simply points out the merits of alternatives to X.

This is important because since the two sides have fought so aggressively over the issue, and having now reached a compromise, there is a significant risk that the text in the draft will be set in stone, in fear of reopening old wounds. That would be bad since there is certainly room for improvement over the guidance that HTML gives to authors in this area. So long as the draft retains the positive language it should be possible to augment the existing wording without violating the compromise.

Lets hope HTML 5 can now move on, and get to work on delivering an accessibility solution for Canvas.

It seems like getting some of these arguments out of the way during the Working Draft phase will make life easier come Candidate phase and Last Call, especially if the “belligerents” were to get satisfactory resolution to their issues and then become advocates for HTML5. I think there’s been a lot of bad faith on all sides, and the quoting of tweets for derision in public forums and the writing of counterproductive doggerel has made things worse, not better.

Meanwhile, us “lurkers” just want an HTML5 standard in hand already.

So, good luck. But let’s hope there’s no need for a vote between the Editor’s Drafts, and let’s hope you and the group can come to some simple compromise. We need resolution, not more pointless rock hucking that wastes the world’s time.