summary="" in HTML5

This is a bulk reply to a variety of messages sent in the past few weeks 
on the topic of the summary="" attribute. I have tried to focus on 
messages that introduce new information and research.

Before I jump in to the e-mails themselves, I want to make sure we all 
agree on the underlying goals that we are trying to accomplish.

Problem statement: some users find navigating tables complicated, and 
would like a description of the table so that they can make better use of 
the table. Such users might be blind, using an accessibility tool, or 
might have cognitive difficulties, or might just be unfamiliar with the 
structure of particularly complicated tables.

There are several things to consider when evaluating possible solutions:

 1. Whether the solution would actually solve the problem if used right.

 2. Whether the solution hurts any users, or fails to help users that 
    should be helped.

 3. Whether the solution would be used correctly enough for users to 
    actually pay attention to it. A feature that is rarely used in 
    practice is better than a feature that is used wrongly, since the 
    latter will cause users to ignore the feature even when it is used 
    correctly.

I think it's clear that summary="" could solve the problem if used right. 
It seems like it would fail to help users that don't get access to it 
(like users of visual browsers). Whether it would be used correctly is a 
question we can in fact answer, since we have ten years' worth of 
experience with sites using summary="", with ample accessibility advocacy, 
education, and law (!) to support it. I'll discuss this further below.


On Tue, 17 Feb 2009, Leif Halvard Silli wrote:
> 
> Following Ian's advice to give feedback in the form "as defined, I can't 
> do this with HTML5"[3]:
> 
> Both <caption> and @summary provide metadata. But currently, in HTML 5, 
> one cannot author the table metadata with both screen readers and visual 
> media in mind, simply because, in visual medias, a long and wordy 
> caption would not work or serve its purpose as caption. Such <caption>s 
> would not even work for screen readers, since those readers too need 
> short, clue giving captions. (As soon as one learns what a particular 
> table is about, the @summary looses more if its purpose, while the short 
> <caption> increases its usefullness.)

I am concerned here over the media-specific aspect of this problem 
statement. What about other media, such as braille? If something is 
media-specific, then it should be handled by the styling layer. Much as 
how people hide links to skip navigation from the visual rendering when it 
only applies to screen readers, navigation information that the author 
thinks would only apply to users of screen readers should be hidden from 
other media. (Screen readers properly supporting the 'speech' media would 
significantly aid in making pages written by caring authors more 
accessible, since hacks like 'text-indent' would not be needed.)

Looking past the media-specific nature of this argument, I don't actually 
understand what is being described. It appears that what is being stated 
is that long captions are problematic in all media (much like any long 
prose, it would seem to me), and furthermore that with a caption, a 
summary is less useful (which makes sense as far as I can tell).


> Thus, HTML 5 as defined does not let us provide users with fast accessed 
> and fast read summaries of tables for the situations when the <caption> 
> does not give the reader enough clue about what the table is about, when 
> starting to wade through the table itself to find this out, would be 
> considerably more timeconsuming than reading a such description.

If the caption doesn't help the user, why would summary=""?

How is summary="" supposed to be exposed to users of visual browsers? 
After all, it's not just users who don't have a screen who need to 
understand complex tables. Wouldn't it be better for the information to be 
available to everyone? (Isn't that the whole point of accessibility?)


> HTML 5, as defined, also does not ofer any way for providing any such 
> table spesific metatada *without* also adding a <caption>. (Authors may 
> feel that not all tables *needs* a any <caption>. However, non-visual 
> media users could benefit from a summary function even in those cases.) 
> Strictly speaking, a summary feature could be useful for all media 
> types, if there were a cross-media method for providing it. Perhaps as a 
> <summary> child element of <caption>? However, then one would need tom 
> make <caption> a required element.

This assums that there is a need for tables to have both captions and 
summaries, which is unclear to me.


On Wed, 18 Feb 2009, Leif Halvard Silli wrote:
>
> This message investigate the option of replacing table@summary with 
> caption@title.

That doesn't really seem to change anything, does it? Why would the latter 
be better than the former?


>    * Avoids the problems of the (claimed) misused @summary

How so? Surely it would just move the problems from one attribute to 
another.


On Wed, 18 Feb 2009, Joshue O Connor wrote:
> 
> The difference is between some thing that facilitates comprehension for 
> a user that /needs/ this information and something that is optional for 
> a user who can already comprenend it. For example, a sighted user can 
> quickly glance at a table and understand the relationships between 
> various headers and row and column relationships. A non sighted user, 
> has to interogate the table. @summary is useful as it does some of this 
> work for the user because the user is informed in advance of what the 
> table contains. It could be compared to a look ahead.

I think you underestimate the number of people who have problems reading 
complicated tables. Some of the tables I've seen discussed in this thread 
are tables for which I really wish I had access to real summaries.


On Fri, 20 Feb 2009, Steve Axthelm wrote:
> 
> Indeed, let me provide a real world example:
> 
> <http://www.bookshare.org/search?resultsView=TABLE&search=Search&keyword=king>
> 
> We implemented sortable headings for these search results tables. A 
> sighted user gets visual cues about the sorting via the heading colors 
> and sort direction icon. We felt like this was important information to 
> all users and chose to expose that through @summary:
> 
> summary="Search results sorted by title, ascending"

This is by far the best use of the attribute I've ever seen.

I notice, though, that the arrow showing which direction the table is 
sorted in is included only in the CSS. When I turn off the CSS (e.g. 
because I'm viewing the page in Links, or in Firefox with "No Style" 
selected), there is no indication of the sort order.

Effectively this table is _more_ accessible for non-visual users than 
visual users without CSS!

This, to me, argues that the summary information shouldn't be hidden in 
the summary="", but should be somewhere in flow, like the <caption>. 
Instead of:

   summary="Search results sorted by title, ascending">

...it would be better to have:

   <caption>Search results sorted by title, ascending</caption>

The CSS could then be used to hide this information, e.g.:

   caption { height: 0; overflow: hidden; }

...without hiding it from users who need it.


On Sat, 21 Feb 2009, Leif Halvard Silli wrote:
> 
> What HTML 5 says about <caption> is, in my view, not enough, regardless. 
> HTML 5 should recognise the problem that @summary is supposed to solve 
> and prescribe ways to solve it.

I've added text to address this.


> It is when one has allread used <caption> for something else, or when 
> the summary info is longer than what is fit for a caption, that one 
> really needs @summary.

Could you give an example of this from a real Web page? Is this common 
enough that it matters enough that we should handle it? (How often are 
they used together today?)


On Wed, 18 Feb 2009, Steven Faulkner wrote:
>
> Ian hickson wrote:
> "It is encouraging that certain users are in fact able to navigate the
> Web without coming across the overwhelmingly bad uses of summary=""." [1]
> 
> "In fact, the main argument against keeping <table summary=""> is that
> legacy content has abused it so badly that it is unusable. " [2]
> 
> Can you clarify what the basis for these claims of "overwhelmingly bad uses
> of summary=""" are?

There have been a number of studies, by Philip, yourself, myself, and 
others. They all end up showing mostly the same thing. (I look at your 
data below.)


> After last weeks html working group teleconference I undertook a small 
> study myself: summary attribute usage data. I am not making any wild 
> claims about this study, but do suggest that from this sample, for the 
> large majority of cases where @summary was used, it was used on data 
> tables in way that may be useful to the users its intended for.
>
> http://www.paciellogroup.com/blog/misc/summary.html

Thank you! Real data always helps us make better decisions.

Let us examine these tables. First, it's worth noting that this data 
represents the best of the best that we might expect from Web authors -- 
the authors of these tables were legally bound to make them as accessible 
as possible, so it's unlikely that we will see any better results 
anywhere.

http://www.fbi.gov/ucr/cius2007/data/table_01.html

   The summary="" value would be useful to all users, yet users that don't 
   see the attribute's value have no way to find out the information.

http://www.cdc.gov/asthma/nhis/04/table1-1.htm

   The summary="" value duplicates information in the page header and the 
   page title, and could without harming visual users have been put in the 
   caption. In addition, again, the summary="" has information that is not
   available anywhere else, leaving non-AT users out in the cold.

http://www.eia.doe.gov/cneaf/electricity/epm/table1_13_a.html

   This entire table is non-conforming (it's a layout table), so it 
   doesn't matter if we allow summary="" for it or not. The table 
   shouldn't exist. No summary required. (This summary="" is inserted by 
   script, no less.)

http://www.vrg.org/journal/vj2006issue2/vj2006issue2mealplans.htm

   There are a number of tables here, and none of them have useful 
   summary="" attributes. A number of them duplicate existing captions, 
   leading to a suboptimal experience for users of AT products. Several of 
   them have one-word summaries that are more vague than the first cell of 
   the table, and therefore do nothing to help the user. The remainder are
   layout tables that would be better done using <dl>, and the summary="" 
   attributes would be better as captions if they are needed at all.

http://www.irs.gov/formspubs/article/0,,id=164272,00.html

   These summary="" attributes once again give information that I would 
   find useful as a non-AT user. They also duplicate some of the 
   information in the headers before the table. Would be better as a 
   caption.

http://www.hrsa.gov/vaccinecompensation/table.htm

   The summary says something that is not about the table that isn't 
   provided anywhere else, and it repeats information in the caption. 
   (The summary is "National Childhood Vaccine Injury Act Vaccine
   Injury Table", whereas the page is titled "National Vaccine Injury
   Compensation Program" and the table is captioned "Vaccine Injury 
   Table".) I can't tell if this is because the summary is out of date, or 
   because the page header is out of date, but in either case, _someone_ 
   would be better off if the summary hadn't been there, and the AT user 
   would not have been worse off.

http://www.cslib.org/finespenalt.htm

   The summary is a word-for-word repeat of the first row's table header 
   cells, which doesn't seem helpful since the user would get the same 
   information either way.

http://aspe.hhs.gov/poverty/faq.shtml

   Both tables are non-conforming. The AT user would be better off with 
   neither table nor summary.

http://www.ssa.gov/OACT/STATS/table4c6.html

   The table with the summary="" is non-conforming; the AT user would 
   again be better off without either it or its summary.

http://www.nhlbi.nih.gov/guidelines/obesity/bmi_tbl.htm

   The summary is a useless repetition of the header before it, and it is 
   the caption that includes information on how to use the table!

The conclusion I draw from this data is that summary="" hurts users who 
don't have access to it, hiding information that they could use, hurts 
users who DO have access to it, encouraging people to consider layout 
tables acceptable; and hurts the authors writing these tables, wasting 
their time writing summaries when their time would be better spent making 
pages accessible to _everyone_.

It's worth noting again that this data is representative of the very best 
that we can expect from Web authors.

I think this answers all three questions posed above (1, 2, and 3 
regarding how to evaluate solutions). The summary="" attribute fails to 
improve accessibility in practice, despite being promising in theory. It 
does cause some users to get a suboptimal experience (sometimes the AT 
user, via bogus data, others the non-AT user, via missing data).


On Thu, 19 Feb 2009, Steven Faulkner wrote:
> 
> The question at hand is whether the use of the summary "in the wild" 
> helps or hinders screen reader users.

No. The question at hand is whether the use of summary in the wild helps 
or hinders _all_ users. Accessibility is about making content _uniformly_ 
accessible, not only accessible to those with disabilities.


> At this point I have a very limited objective, that is I am working to 
> get @summary into HTML5, not because i do not consider that improvements 
> can be made as you have been investigating, but think that @summary 
> inclusion has the most chance of getting in the HTMl5 spec of the 
> options for data table descriptions.

Surely you would agree that we should not include features that are 
actively harmful for accessibility?


On Fri, 20 Feb 2009, Leif Halvard Silli wrote:
>
> Perhaps Ian, Sam or Chris could shed some light on this? Are we doomed 
> to discuss @summary only? Or can we discuss how tables could be improved 
> e.g. with new table meta data elements?

I can't speak for Sam and Chris, but personally I'm looking at the long 
term, and so I certainly wouldn't limit us to discussing summary="" only. 
We should investigate any and all solutions that would help users (all 
users) understand the Web better.


> As long as <caption> is strictly intended as a <table> title, there is 
> need for another place to place other metadata that is directly linked 
> to the table. Well, one method is perhaps to place <table>s in <figure>.

I've clarified that the <caption> is not limited to the title, and 
included an example of this.


On Thu, 12 Feb 2009, Gregory J. Rosmaita wrote:
> 
> in accordance with DanC's request that i send details to the WG's 
> emailing list with details about the report i made on PFWG's processing 
> of HTML5 issues, i am sending this summary -- although i am confident 
> that it accurately reflects the state of the situation and the stance of 
> WAI/PF, this is not a formal report, but an informational report 
> compiled at the request of the chairs
> 
> 2. @summary:
> 
>    PF WG already made an official announcement on this issue and 
>    requested the attribute be re-instated, consult: 
>    http://lists.w3.org/Archives/Public/public-html/2008Aug/0213.html

This topic was last covered in:

   http://lists.w3.org/Archives/Public/public-html/2008Dec/0175.html

...which took into account the e-mail cited above. (The e-mail itself 
didn't get a direct reply because it did not include any arguments or 
research to support its statements.)


>    PF WG's position from the outset has been that there is a need to
>    restore @summary for TABLE in the draft specification BEFORE the 
>    next public working draft is issued -- janina sajka, chair of PFWG
>    will probably say so formally in the near future in a post to 
>    public-html

While I understand that that is the position of the PF working group, the 
reasoning behind this position hasn't really been explained.



CONCLUSION:

Data collected continues to show that summary="" does not provide benefits 
beyond those that could be provided by <caption>. Indeed, while previous 
data showed merely that many authors misunderstand summary="" and misuse 
it to the detriment of AT users, new data (quoted above) shows that 
authors who _do_ understand summary="", and are compelled (by law!) to use 
it, end up actually removing information that would be useful to users who 
don't have access to summary="" attributes!

I have updated the spec to include advice on using the <caption> element 
to include information regarding how to use the element to benefit all 
users, including AT users.

I have not added the summary="" attribute to HTML5, because evidence 
suggests that it is not the way to improve accessibility. I have, however, 
added a clause to the spec that allows browsers to use the attribute if it 
is present, and I have made the presence of the attribute a downplayed 
error. These two points should help with migration.

I understand that this does not satisfy the desire for us to simply 
support the attribute, but based on the data presented, I do not believe 
that simply supporting the attribute is a net benefit to accessibility, 
which at the end of the day is what matters.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 24 February 2009 02:55:12 UTC