Re: Tables and the Summary attribute

Larry G. Hull said:
> If someone replies to you personally with a good reason for using the
> summary attribute to provide a descriptive narrative, I (and probably
> others) would like to hear it.

A quick aside: it wasn't clear but my question was concerned with complex
financial tables and not simple/layout tables.

My belief is that the summary attribute should contain information on how
to use the table, and not commentary on the data itself. I have quoted
some feedback from others on the list that supports this belief at the end
of this email.

Some of the constraints with summarizing the table(s), in my circumstance,
are these:

1) I am not an accountant or economist, so I don't fully understand
financial reporting, and getting summaries from the content owners is not
an option.

2) The content owners and I are, in many instances, legally obligated to
*not* lead any conclusions that may be drawn from interpreting the data
(e.g. by describing trends).

3) Preferably the summary is generated programmatically and is reusable.

So that leave me with discriptive narrative. To illustrate what I meant by
descriptive narrative of table structure, consider the following:

caption: Tax and Levies Collected through the Crown's Sovereign Power (Cash).

summary:
There are 5 columns. Columns 1 and 2 show forcasted results for 2006.
Column 1 is the original budget. Column 2 is the estimated actual results.
Column 3 is the descriptive label for each row. Column 4 and 5 show
historical results. Column 4 contains the actual results for the year
ended 30 June 2005. Column 5 contains the actual results for the year
ended 30 June 2004. The rows show the Income Tax reciepts by sector. Each
sector is summarized for Individuals, Corporate Tax, Other Income Tax,
Other Indirect Tax, and Other Sovereign Recipts. Summary rows begin with
the word 'Total'.

Here is some feedback that supports my POV:

Sailesh Panchang said:
> In my opinion the summary should be used only on complex data tables
> firstly to convey the structure of the table... describe col. and row
> spanning etc. The essence of the data in the table may also be included
> in the summary if it is not already part of the page's visible text
> content.
> By "essence" I refer to things that would stand out to a sighted user
> instantly like trend, relationships, range, high and low points.

Jamal Mazrui said:
> Although my screen reader, JAWS, tells me something at the outset about
> the table structure, it is only the number of rows and columns, which is
> insufficient conceptually for all but small, simple tables.  More
> structural information would include the row and column headings, if
> any, and information about additional logical levels to be aware of in a
> complex table.

> A summary attribute may be useful for both structual and content
> information, though if the information is of significant length, a
> usability problem results.  There is not an easy, well-understood way of
> skipping a long summary description if it is too verbose at that time.

Jim Thatcher said:
> Since a screen reader will be announcing row and column headers as they
> change when the user navigates the (data) table, I think the summary
> should alert the user about what to expect in that regard by providing a
> brief description of the (data) table structure.


kind regards

Terrence Wood

Received on Tuesday, 27 September 2005 22:28:43 UTC