About table summary: The HTML5 draft advises one to design a data table in a manner that it is understandable so that a summary is not needed at all. In fact most complex data tables can be broken down into simpler ones that are easier to understand. While this cannot be faulted generally, one has to admit that complex tables do have value in representing data relationships across dimensions efficiently. And complex tables are not going to go away. Sighted authors and users of tables may consider a description of the manner in which a table organizes and represents data as a waste of space and time and may choose not to have such a description. That is their prerogative. It is precisely in these circumstances that the HTML 4 summary attribute helps non-sighted users. Likewise, a summary may help non-visual users grasp the design of the 3-column simple moods-table in the HTML 5 draft. Sighted users may find the description unnecessary. A standard cannot mandate that such descriptions (or even a caption for a table) should be visible text without impinging on the author’s freedom. So what is the objection to the HTML4 summary attribute? This remains unclear. Authors even today are free to include extensive description of the table’s structure and a summary of the data (highlights / key values) within a paragraph for all to see if they choose. So I do not understand what is new in the HTML5 draft about using a p-tag to hold such text? Except that it is within the ‘caption’ element. Which I think is weird. As an author I would perhaps want the descriptive text before or after the table and not right after the title. And if a caption is meant to serve as a title or header for a table, how does a description of the table’s structure or content belong to the caption? It is not clear to me from the HTML 5 draft if the contents of the “detail” or “summary” element is visible or not. It appears someone is getting a kick out of calling the ‘summary’ attribute by another name or replacing an attribute with an element.
Priceline.com even now uses a summary attribute for the table that displays the results of a search for flights. In May 2004 that summary was much longer. It is included as one of the examples in the attached htm file. (I had suggested then to Priceline that the table is much too complex and it needs a summary). Then here are a couple of links to my posts on the topic: http://lists.w3.org/Archives/Public/w3c-wai-gl/2004AprJun/0823.html http://www.accessifyforum.com/viewtopic.php?t=4336 http://webaim.org/discussion/mail_thread?thread=3992 And here is an observation by the late John Slatin (Dec/2003) to one of my posts on table summary. I agree very strongly with Sailesh. The <caption> provides a title for the table and is available to everyone. The summary makes it possible for blind users to gain information about the table organization or content that is readily available to people who can see the table—blind users often have to listen to the table for quite a while in order to gain the same understanding. The summary would work well in the example cited—the of checkboxes by hotmail (and other Web-based mail applications like Yahoo and Webmail) to mark messages for deletion or some other operation--. It would be even better if the subject field for the message was associated with the checkbox via the <label> element. (So this example involves techniques for tables and techniques for forms.) John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sailesh Panchang Sent: Tuesday, December 02, 2003 3:43 PM To: [email protected] Subject: Caption and Summary : [techs] Latest HTML Techniques Draft Ref: http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20031104.html The tech doc has always maintained that "It is rare to use both the caption element and the summary attribute (in a table) since one or the other should be enough to provide a description." Comment: It is a good practice to have captions for all tables as it is like a table heading and is visible to all. But the summary is not displayed on screen and is especially meant to provide additional cues for orientation / navigation to non-sighted users. For complex / large tables and tables that use row/column spanning, useful info can be conveyed through the summary attribute. There are many times when both attributes are complementary to each other and the HTML tech doc should not suggest that it is rare to use both. In fact the doc should suggest that one should make the assessment for each table on a case by case basis. Take for instance even a simple table with 6 columns that lists e-mail messages by rows. Let's say the first column contains a checkbox for selecting messages. It is useful if the captionsays "Sent Messages Folder" and the summary says "Use the checkbox in the first column to select / unselect the message in the respective (or corresponding?) row". I figured this out myself on the MSN-Hotmail site that uses this design. A table caption and summary would make life simpler in this context for instance. I have pointed this out to MSN Support too. === Sailesh Panchang (MS, ASQ-CSQE), Accessibility Services Lead www.deque.com Tel 571-344-1765 (C) 703-225-0380 (ext 105) (Work)Title: Example of summary for data tables
Techniques for writing summaries for data-tables
The HTML specifications state: "Authors should provide a summary of a table's content and structure so that people using non-visual user agents may better understand it. ... CAPTION element provides a short description of the table's purpose. A longer description may also be provided (via the summary attribute) for the benefit of people using speech or Braille-based user agents.". It goes on to add:
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. 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. This is especially important for tables without captions.
Discussion
The above suggests that the summary should serve two purposes for the benefit of non visual user agents rendering speech or Braille. Note the value of the summary attribute is not visible in the browser.- summarize the contents of the table
- convey the structure of the table
In reality many user groups- not just vision impaired users, would be interested in a summary or highlights of the content in a data table. So putting this in the summary attribute is probably not the best option. Often the major highlights from a table are summarized in the main body of the document which references the data-table. This information is available to all users. Other options of allowing the author to describe the table contents without including it in the main document need to be explored.
Therefore, in my opinion, the main purpose of the summary attribute is to describe the layout or structure of the table. By adjusting the verbosity settings of some screen readers / self voicing browsers, it is possible to have the adaptive software announce the dimension of the table and attributes of a cell like column and row spanning and header association. But it takes a long time to run through a table to determine its structure and relationships between header cells and data cells. A simple table does not pose a problem if it is correctly marked up but layered and irregular tables do.
Tips for writing table summaries
The table summary should
- point out which column(s) or row(s) span how many columns or rows by using terms like: "is a common header for
columns or rows" or "has sub-columns" or the like. - not merely refer to the column# or row# that uses spanning but describe the columns, like: "Column #3 labeled Branch Locations states three sites in sub-columns under it"
- pointt out rows that are used for groupheaders and footers or at least mention that they exist. Sometimes there is no data against a row that contains a group header and this can be stated. Likewise, indicate the columns that contain sub-totals or totals or key data like averages, etc.
Examples
Example 1. Summary for Traffic cop table(layered) at
http://www.eramp.com/david/traffic_cop_prototype_staticc_no_rows.htmsummary="Every guideline listed in column 1 has multiple success criteria against it in column #2. Column #3 lists techniques against every criteria. It might help to exit table navigation mode to review the contents in column #3 in detail."
Example 2: from a irregular table from a site that offers prices from multiple airlines
Summary="This table contains nn rows and mm columns. Each set of rows contains one itinerary. The first cell has the price and a link to select that itinerary. Subsequent cells in the first row of the pair describe the outbound flight; the second row describes the return flight. One-way itineraries will only contain a single row. Multi-destination itineraries will include a row for each flight."
Example 3. For an irregular table: Travel Expenses Report under 11.4.2at
http://www.w3.org/TR/html401/struct/tables.html#adef-axis Proposed caption=Summary of travel expenses for August trips to Seattle and San JoseProposed summary=Three heads of expenses: meals, hotel and transport are in columns 2 to 4. The first column contains names of cities visited along with the dates of visit under each city. The total expenses incurred in a city is in a row following the dates of visit to the city. The last (fifth) column contains the total expenses for every city. The total for all cities is in the last row of the table.
Example 4:Layered Table using rowspan
| Zone | County | Commencement date |
|---|---|---|
| Green | Allegheney | June 2, 2004 |
| Somerset | June 7, 2004 | |
| Yellow | Washington | May 25, 2004 |
| Wellington | June 17, 2004 | |
| Laurel | May 20, 2004 |
