- From: James Graham <jgraham@opera.com>
- Date: Tue, 24 Feb 2009 18:01:06 +0100
- To: Steven Faulkner <faulkner.steve@gmail.com>
- CC: Ian Hickson <ian@hixie.ch>, "Gregory J. Rosmaita" <oedipus@hicom.net>, HTMLWG <public-html@w3.org>, wai-xtech@w3.org, wai-liaison@w3.org, janina@rednote.net, w3c-wai-pf@w3.org
Steven Faulkner wrote: > Hi Ian, > >> 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. > > I don't agree with the underlying goals in relation to @summary, the > use of @summary has been discussed in terms of its scope as set out > in HTML 4.01 > > "This attribute provides a summary of the table's purpose and > structure for user agents rendering to non-visual media such as speech > and Braille."[1] > > It is and does try to solve a subset of your problem statement, the > other aspects of your problem statement can be handled by providing, > for example, a paragraph before the table with content that describes > the table. > > What @summary does, but HTML5 omission of it does not is provide an > explicitly associated container for text that can be unambiguously > identifed as a summary of a data table. There are at least three mechanisms in HTML 5 for doing something very similar to this: <table><caption> <figure><table></table><legend> <table aria-describedby="idref"> (integration of this is waiting on the aria integration TF) This suggests that @summary is not needed to fulfill your use case as stated. I agree that _in principle_ there are minor semantic differences between @summary and some of those constructs; in practice the data doesn't support the idea there is a difference in practice. This suggests that there must be some additional, unstated, component of your use case. It would be helpful to identify that because at the moment the fact that @summary fails to fulfill the wider use case that Hixie set out (that is: making tables understandable to all users, not just users of a particular class of AT), suggests that it is not a very helpful attribute to introduce. (As an aside, to continue my earlier theme, the last of these can currently be used in combination with <details> to provide a short description and a longer one for those who need a longer summary. I believe it could also be used in the other two cases, if the content model in the spec were updated to allow it. This idea of a brief summary followed by more information for those who need it matches the WCAG2 technique for the use of @summary, which may or may not represent actual user needs. It is possible that use of <details> may be hindered by UA adoption and the (in)ability of authors to customise it to their display preferences.)
Received on Tuesday, 24 February 2009 17:01:56 UTC