Goodbye table summary attribute

[Stomme poes]

This one caught me off-guard.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the 'drop the summary="" attribute' Change Proposal for ISSUE-32. Of the Change Proposals before us, this one has drawn the weaker objections.

Source

I know I've struggled making my summaries correct in the past. Now that I know how to do it correctly, it's gone. Bleh.

(Since they removed the "5" I get more easily confused, but I believe they mean this is gone from the HTML5 spec. Which should mean, browsers/UAs will continue to support summary simply to remain backwards-compatible.)

Another thing that keeps confusing me is constant mention of using ARIA attributes to replace things like summary (and it's also been proposed as an idea to replace longdesc). One of the (important) objections to both longdesc and table summaries is that it's "hidden metadata": that is, unless you view the source, or have some extra software like a screen reader, you (either as a sighted graphical-browser-using visitor or as a document author) don't know that information is available...
but aria-describedby and other ARIA attributes have the same problem!! They're meant primarily for screen reader users, and so far I haven't seen any browsers showing ARIA attributes to me on my screen (tho Bruce might've written a plugin for Opera; wouldn't surprise me). Still "hidden metadata" isn't it?

The argument that complex tables or large tables showing specific patterns should have a "summary" out in the open (in plain text on the page) is also a good one. If users can't tell at a quick glance what's going on, you need to summarise how that table is set up and what it's saying right on the page, for all users.

But I use summary primarily for "simple" tables, as do many of us. So now what?

[xhtmlcoder]

I'd assume it was with reference to HTML5 and yes both technologies were primarily for assistive devices anyway.

[felgall]

Just another example of the difference between the people working on the new standard and those who worked on HTML4 who actually knew what standards are about.

[rguy84]

I agree with Stephen. I saw this happening on Twitter, it is a shame...

[deathshadow60]

Part of me says "great, next they'll axe TH, THEAD and CAPTION" -- but at the same time I've NEVER seen anyone actually USE them since as an attribute, it's not actually SHOWN and NOTHING actually seems to use them. NEVER seen a single user agent that did ANYTHING with them, so why keep them in the specification?

... and so far as REMOVING tags and attributes from HTML 5, I'm all for it -- but I'm in favor of dropping somewhere around 98% of the new tags and attributes they want to introduce anyways as being needlessly complex, undoing the progress of STRICT, or just plain being outright redundant to existing tags/attributes...

Hell, with the way people vomit up pointless crap I'm in favor of completely dropping META and maybe we should swing an axe at using REL inside BODY?

[Stomme poes]

NOTHING actually seems to use them. NEVER seen a single user agent that did ANYTHING with them, so why keep them in the specification?

Uh, screen readers. Most or all of them. Since summary was primarily aimed at those who didn't get a visual representation of a table, it was added pretty much just for them.

Lynx displays tables. Elinks does too (basic rows and columns, tfoot before tbody... but no summary in either). So I'm not sure if it was also meant for text browsers.

If you want an answer to WHY keep it, it's in the WCAG. The question is, though: is there research to support that? Do users find it useful/necessary? (This is something WebAIM could add to their next survey!)

WCAG1 had like two examples of summary, one for a simple table that frankly I think could/should have been a caption, and another example using the complex table from the HTML4 specs (the costs of travel between various cities) which possibly is a complex-enough table that it needs explanation out in the open for everyone...
WCAG2 states "The summary is useful when the table has a complex structure..." which might mean all my summaries for simple tables was just a waste of everyone's time, I dunno.

[deathshadow60]

Uh, screen readers. Most or all of them. Since summary was primarily aimed at those who didn't get a visual representation of a table, it was added pretty much just for them.

Huh, I've used them, never seen it actually work... Including Jaws. It was something Dan and I used to make fun of that it exists for that reason, and even JAWS ignored it.

If you want an answer to WHY keep it, it's in the WCAG. The question is, though: is there research to support that? Do users find it useful/necessary? (This is something WebAIM could add to their next survey!)

Well remember, HTML 5 is designed by/for the HTML 3.2 weenies who try to pass off their manure as HTML 4 or XHTML by slapping a tranny doctype on it, and as such we're talking the same crowd who either goes "WCAG, what's that?" or the people who are completely unqualified to say anything about it, but go ahead and try to pass off some half-assed poorly laid out unofficial "addendum" to 1.0 as the be-all end-all when it's the biggest steaming pile this side of a site made if Frontpage.

HTML5 CERTAINLY doesn't appear to be made for anyone who embraced strict, separation of presentation from content, reduction/removal of redundant tags/attributes, etc, etc...

[Stomme poes]

Bruce Lawson promises a bloggitty about this tomorrow.

Including Jaws. It was something Dan and I used to make fun of that it exists for that reason, and even JAWS ignored it.

I'd have to drag out version 7 to see if that was the case, tho I'm pretty sure it did (that's the one I have to use IE6 with, ug). 10, fine. As soon as I get to the table, after announcing the rows and cols, it goes to the summary.

[ralph.m]

Just checked VoiceOver, and it doesn't seem to read out the table summary, unless I'm missing something.

Poes, did Lawson make that post you mentioned?

[Stomme poes]

Just checked VoiceOver, and it doesn't seem to read out the table summary, unless I'm missing something.

You didn't T over to the table right?

My very first introduction to summary actually was someone blogging/posting about a "neat trick" to make the "computer" (a mac) say things the user couldn't see, I guess as a gag... and they were using table summary with VO to do that.

(why I need to get a mac... arg)

Poes, did Lawson make that post you mentioned?

He reneged!

[ralph.m]

You didn't T over to the table right?

I'm not sure how. Still finding it tricky to use VO effectively, but all I've found so far is that I can use the arrow keys to navigate a table. It reads column headers but seems to ignore things like summary and row headers.

He reneged!

Ah, OK, thanks.

[cydewaze]

In our office we're required to use summary and scope, but caption is curiously optional. I'm sure whoever wrote our standards meant well, regardless of how little sense they make.

[Stomme poes]

Often a header ends up being the same text as caption. Depending.

People seem to go from "caption is like a title for the table" to "caption should explain the entire table in intimate detail"

I prefer the former myself

[deathshadow60]

I'm with you on the former of those two approaches -- though I prefer to think of CAPTION as being the same thing as a numbered heading tag -- just specific to the contents of the table only. I take the same approach with LEGEND in relation to FIELDSET.

But I've always liked the WDG's decade old explanation of caption:

A good caption should provide a short heading for the table. For simple tables, the caption can also act as an adequate summary, but for more complex tables, authors should supplement the CAPTION with a full summary, either through TABLE's SUMMARY attribute or within a paragraph outside of the TABLE.

But then if you look at what they say about summary:

The TABLE element takes an optional SUMMARY attribute to describe the purpose and/or structure of the table. The overview provided by the SUMMARY attribute is particularly helpful to users of non-visual browsers. With simple tables, a good CAPTION is usually a sufficient summary, but complex tables may benefit from a more detailed overview via the SUMMARY attribute. The following example uses SUMMARY to describe a table. Note that the summary could also be included in a paragraph before the table, which is helpful since few browsers support SUMMARY.

Even though it's an EXTREMELY old online reference (the information itself hasn't really changed since 1998 and it's STILL not rotting), I still consider the WDG HTML 4 reference's explanations of the elements to be one of the best sources out there...

[Stomme poes]

The explanation of a "summary" in the caption conflicts with the instructions for summary attribute. (design by committee I guess...)

A summary isn't, despite its name, a summary of the data in the table... rather, a summary of HOW the information has been put into the table.

[deathshadow60]

The explanation of a "summary" in the caption conflicts with the instructions for summary attribute

How so?!? Not seeing that at all.

[Stomme poes]

For simple tables, the caption can also act as an adequate summary, but for more complex tables, authors should supplement the CAPTION with a full summary, either through TABLE's SUMMARY attribute or within a paragraph outside of the TABLE.

Caption doesn't say "rows are made up of X and columns are made up of y", caption says "overview of which senators add amphetamines and other goodies to their morning coffee". <--this does not belong in summary.

The TABLE element takes an optional SUMMARY attribute to describe the purpose and/or structure of the table. The overview provided by the SUMMARY attribute is particularly helpful to users of non-visual browsers.

Over time opinion has focussed more strongly on describing the structure of the table, because that's what non-visual agents don't have. If you need to describe the purpose, topic, or (a real, English) summary of the table, then you need to do it for everyone. So you don't hide it in a summary attribute.

[deathshadow60]

How are those in conflict -- they don't contradict each-other at all?

Though I thought describing rows and columns was th/tbody/thead/scope's job...

[Stomme poes]

Though I thought describing rows and columns was th/tbody/thead/scope's job...

Also, except you only get the gist of it that way after wading through several rows or cols.