- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 24 Feb 2009 02:54:32 +0000 (UTC)
- To: "Gregory J. Rosmaita" <oedipus@hicom.net>, Leif Halvard Silli <lhs@malform.no>, Maciej Stachowiak <mjs@apple.com>, James Graham <jgraham@opera.com>, Joshue O Connor <joshue.oconnor@cfit.ie>, Steve Axthelm <steveax@pobox.com>, Steven Faulkner <faulkner.steve@gmail.com>, Simon Pieters <simonp@opera.com>
- Cc: HTMLWG <public-html@w3.org>, wai-xtech@w3.org, wai-liaison@w3.org, janina@rednote.net, Dan Connolly <connolly@w3.org>, Matt Morgan-May <mattmay@adobe.com>, Julian Reschke <julian.reschke@gmx.de>, W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>
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