- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 27 Feb 2010 17:52:13 +0100
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: Gez Lemon <g.lemon@webprofession.com>, public-html-a11y@w3.org
Hi Laura and Gez, Laura Carlson, Sat, 27 Feb 2010 05:22:59 -0600: > Hi Gez, > >> I disagree with "purpose" in the definition, and believe it's one of >> the reasons the summary attribute has not been used correctly. The >> important part of the definition is to provide the structure, as >> that's what screen reader users are most likely to struggle to >> understand when encountering a data table without the benefit of >> seeing it. The HTML 4 definition of summary definitely needs to be >> improved if it's to stay in HTML5. @summary definition in HTML4 could be improved? Of course. But understanding HTML4 is usually my perspective. If we want to come with critique against it, then we must understand it first. @summary only structure descriptor? Not in HTML4. Not in WCAG20. Technique H73 in WCAG 2 0: http://www.w3.org/TR/WCAG20-TECHS/H73.html#H73-examples Example 1: @summary plays the role of a combined summary and caption. (No <caption> used.) Example 2: There is a <caption>. Only the "structure" part of the @summary in Example 1 is present. Though "structure" is definitively *not* an exact description of the content of this @summary. Should we change WCAG 2.0, in order to have @summary stay in HTML5? I agree that @summary should stay in HTML5, but I don't think we do that cause a good service by narrowing the purpose of @summary. See also <caption> description in HTML4 (emphasize is mine): http://www.w3.org/TR/html401/struct/tables#edef-CAPTION ]]Visual user agents allow sighted people to quickly grasp the structure of the table from the headings as well as the caption. A consequence of this is that captions will *OFTEN* be inadequate as a summary of the purpose and structure of the table *FROM THE PERSPECTIVE OF PEOPLE RELYING ON NON-VISUAL USER AGENTS*. [[ Inline annotation: HTML4 describes the result of the fact that most authors perceive their work from the perspective of being sighted. But the underlying thought here is clearly that the <caption>, when authored with users of non-visuall user agents in mind, *may* serve everyone. Quote continues: ]]Authors should *THEREFORE* take care to provide additional information summarizing the purpose and structure of the table using the summary attribute of the TABLE element. [[ One way to improve HTML4 is to say replace "therefore" with "in these cases" - that is: when the <caption> does not provide sufficient information for users of non-visual user agents. > This is the definition in the change proposal "Make the table summary > attribute valid, not obsolete, and conforming" [1]: I think it is essential that we agree on how to understand @summary, so I offer my comments from that perspective. A common understanding will also benefit the change proposal that I myself is working on. > <quote> > The summary attribute represents a prose summary of the table's > structure, primarily for user agents rendering to non-visual media > such as speech and Braille. The value is text. The one sided focus on "structure" is not in line with WCAG20 or HTML4. > The primary purpose of the summary attribute is to provide concise > guidance to people with vision impairments on how to read a table, > where the structure and reading order is visually evident, but not > available to some assistive technology users. +1 To talk about "guidance on how to read" is a much better than to say than "structure" and also more in line with WCAG20, in my view. But I do miss the perspective that the @summary can essentially serve as "fallback" for the lack of a caption. WCAG20 technique H73 clearly shows that it can. > The summary attribute is > not intended to provide a long description of a data table. This is simply confusing to say. You can only consult the WCAG20 technique H73, and you will see that the summary is much longer than the caption. But, OK, I admit that it could be a useful thing to say, if you somewhere would provide a definition of what "long description" meant ... And/Or if you described how one eventually *should* provide a _long_ description of the table. In other words: We need some context to understand what "long" is meant to imply ... I try to take these things up in my change proposal. A better focus would be to say that the purpose of @summary is not the length, but to offer such and such kind of description. > The summary attribute may be set on the table element if the data it > contains is of sufficient complexity that users of non-visual user > agents would benefit from a prose description of the table's > structure. WCAG20 technique H73 also mentions that it can be useful when the table is very long. (I assume, again, that *purpose* comes into play: Is it worth digging into the table? And if I do, should I be prepared for a very long table? E.g. if you find a table that essentially is the telephone directory for London, then you should know that in advance, so you are prepared for a long read etc ...) > If the table contains data considered to only require a > short description, use the caption element. Do not repeat the content > of the caption element as content in the summary attribute. My change proposal includes the option that the <caption> in these cases can be hidden for sighted users, if that is what the designer wants. (Of course, it ought not be hidden - but it is an option.) I would argue that a hidden <caption> would be more accessible than @summary is. > The attribute may only be set on tables that contain tabular data. The > attribute must not be set on tables used for layout purposes. The > attribute should not be set to the empty string. These are the same requirements that <caption> has (or should have). > Any user agent may provide a mechanism to access the summary attribute > content. If the mechanism provides the summary content as conditional > content it must be input device independent. > > The summary DOM attribute must reflect the summary content attribute. > </quote> > > Ideas for improvement are welcome. General comment: Ian/HTML5 thinks that <caption> should be allowed to contain block elements. I wonder if you have authored your proposal from the perspective that <caption> can not contain block elements. My change proposal tries to talk about this issue. > [1] > http://www.w3.org/html/wg/wiki/ChangeProposals/SummaryAttribute20100222#With_Suggested_Text: -- leif halvard silli
Received on Saturday, 27 February 2010 16:52:47 UTC