Mechanism to Summarize a Table

This document is the deliverable for Issue Tracker ACTION 66, which is bound to ISSUE 32.

Issue

HTML 5 needs a mechanism to provide a table with a summary. An explicitly associated, programmatic feature is required in order to provide an overview of tabular data or a brief explanation of how to navigate a data table for people who use assistive technology (AT). This is because an AT user needs to easily form a mental image of a table's contents in order to better understand its structure, or semantic relationships. The mechanism needs to be explicitly associated with the table or it becomes more difficult for AT to make that association. A summary mechanism may seem irrelevant or redundant to those with good eyesight because they have access to content relationships at a glance. However for users with visual impairments, additional semantics are often needed as a vital aid to comprehension. These useful semantics, such as those supplied by @summary, are often the difference between "seeing" or "not seeing" the table as a whole. @summary therefore provides a 'quick scan' feature for non-sighted users that requires no complex user interaction beyond giving the table element focus.

Summary Example

<table summary="This table presents traveling expenses. In rows, you will find destinations and traveling dates, as well as grand total. In columns, you will discover expense categories as well as a total. Note that the first column contains merged table cells.">
<!-- Remainder of table -->

Status

Open Issue:

Issue 32: table-summary, Raised on behalf of Joshue O Connor

Actions

Action 66: Joshue to collate information on what spec status is with respect to table@summary, research background on rationale for retaining table@summary as a valid attribute

Table of Contents:

Contents

Mechanism to Summarize a Table

Proposed Solutions

Provide a summary via a "summary" attribute.
Provide a <summary> element as proposed in XHTML2.
For backwards compatibility UAs could accept either @summary or <summary>, while the spec can encourage the use of the element in place of the attribute.
The summary of a table could display visually (similar to <caption>) either underneath caption text or underneath the table itself as a footnote. (But both of these would have some backward compatibility issues associated with them).

Rationale: Why Summary Should Be Provided

Tables are an inherently visual way to display information of a fairly high density: especially with the use of borders, background colors and text/font attributes, particular relations of the data in the table can be quickly gleaned from a cursory glance at the table. For tables which possess these aspects, a summary is crucial for users who cannot visually consume the table as a 2-dimensional grid.
A disability constituency currently uses and depends on this feature: anyone offering to remove it should be expected to demonstrate that the replacement works better and is in service.
No set number of use cases proves a feature should be included or excluded from the spec. The W3C requires that technologies must be accessible. By definition, people with disabilities are a minority. Accessibility features address failure modes that are infrequent, but critical when they occur.
The @summary technique may sometimes be used incorrectly but that is true of all markup. Failure by some to implement a standard is not in itself sufficient justification for getting rid of that standard.
The @summary technique provides functionality today. If it is to be worked out of the system, it should not be an abrupt drop. Transition it out with something better in an orderly and graceful manner.
Summary is to the visual construct table as "alt" is to the image element, and title and description are to SVG - necessary and required markup, so as to indicate to the non-visual user what is subconsciously absorbed by the majority of users, for whom it is merely a question of the ability to associate data with row and column headers.
If use something outside the <table>, something other than table@summary, then that information isn't explicitly associated with the table (and it becomes more difficult for AT to make that association). This would be a problem for the many users of older legacy AT.
Summaries are especially useful for non-visual users. A summary of the relationships among cells is especially important for tables with complex relationships and may also be helpful for simple data tables that contain many columns or rows of data.
A summary makes it inexpressibly easier for someone processing a TABLE non-visually to get an over-view of a table, for what is a table, other than a visual means of displaying related data sets, and what the sighted user sees at a glance - the spatial relationships between cells, rows, and columns. In the absence of a summary, however, the aural user must investigate the table carefully and fully, merely in order to ascertain whether or not it is the correct table, what information the table contains, if the information in the table is germane, how many rows by how many columns to expect, the flow of the table, etc.
The summary attribute is essential to a non-visual end user who is interpreting the visual canvas with an aural renderer. It is to the non-visual or low vision user -- who is often forced to use a small highly magnified view port -- what the gestalt view is to a sighted user capable of making the correct spatial associations: an instant familiarity with the layout and flow of the table, which is constantly reinforced by visually interacting with the table. Obviously, this type of overview is impossible for a speech or refreshable Braille display user to obtain without entering and inspecting every table, whether or not that table contains the information for which the user is seeking. Without a summary, every table will entail extensive, tedious work on the end user's part because she: 1) has no foreknowledge of the table's layout; 2) has no foreknowledge / is unaware of the relationships conveyed by the table, for table-ized data (as well as layout tables) have meaning only insofar as one can visually and cognitively correctly correlate column and/or row headers, even if not they are incorrectly marked up (for example, indicated by a font-weight change or color change only).
@summary is very useful for inexperienced users of screen readers as it is announced as soon as the table has focus. The user therefore does not need to use complex keystrokes to interrogate the table in order to get an overview of whether it is useful or not.
Sometimes for visual effect an author wants to keep a page simple for visual users and still provide a mechanism for other non-visual users to consume content. The @summary mechanism is a simple way of achieving this.

Rationale: Why Summary Should Not Be Provided

If a table is complex enough to require a description to understand it, then that description should be available to everyone (not only screen reader users).
- This is possibly a user agent issue and not a reason to not include @summary in HTML 5. If the @summary meta data is present then any user agent could potentially render it - if needed.
Summary is explicitly invisible metadata and therefore is more likely to be missing or inaccurate than data that is visible to all UAs.
- Poor authoring practices should NOT sway or inform our decisions -- if markup is being misused, we need to be more precise in the definitions of elements and properties. This is not a solid reason to remove @summary. The summary data could be inaccurate but this is not a good enough reason to remove the mechanism entirely. Any labeled or described content could be viewed as inaccurate or needing improvement - this is not a reason to remove from HTML 5.
- This also begs the question, "invisible to whom?" It is perceptible by those for whom a summary is of essential utility, while for those who can visually process the contents of the summary attribute have the table itself to provide them with the orientation mechanisms which summary provides those who cannot see. Visual users don't need a summary, due to the constant reinforcement of the table's structure, function and contents which is a side effect of vision and the ability to associate data via spatial relationships... sure, a summary could be yanked from the table and displayed to those who want slash need it, but for those who cannot see, or have a very limited view port available at any given time, summary is necessary.
In many cases pages already include text that summarizes the contents of a table to the extent needed to identify whether the table is of interest; in order to allow non-visual browsers to easily scan a page, I would provide a mechanism to associate this text with the table. Authors wishing to provide extra information hidden from visual UAs (e.g. because it describes the table in a level of detail not required by sighted users) could use CSS to explicitly hide that information.
- The use of @summary is vital where these summaries are missing. Also older user agents may not support new associations a la ARIA, so why remove an existing mechanism that is proven to work?

Use Cases

Blind/Non-visual users

A textual summary makes it easier for to get an overview of a table without seeing the relationships between the rows and columns implied by its spatial structure. In the absence of a summary, the non-visual user must investigate the table carefully and fully, merely in order to ascertain whether or not it is the correct table, what information the table contains, if the information in the table is germane, how many rows by how many columns to expect, the flow of the table, etc.

Advice Request to PFWG

Request for PFWG WAI review of @summary for tabular data - Joshue O Connor, Laura L. Carlson, Gregory J. Rosmaita, Steve Faulkner, June 26, 2008.

Advice From PFWG

Here is a summary of how PFWG sees the situation as regards @summary on <table> in HTML:

@summary should stay
It provides a needed service
element content providing this info, *if linked by markup to the table* offers growth to even better practice
Don't have the linking markup yet; is a developmental item
evolution not revolution says: keep @summary at least until alternatives are deployed and stable

Source: RE: Request for PFWG WAI review of @summary for tabular data - Al Gilman, August 6, 2008.

Policies and Guidelines

Official United States Postal Service policy (AS-508-A Section 508 Technical Guidelines) are used in statements of work, vendor requirements, both internally and externally. - Norman B. Robinson.
University of Wisconsin Accessibility policy
California State University Policy
WCAG 1
WCAG 2
- H73: Using the summary attribute of the table element to give an overview of data tables - Techniques for WCAG 2.0
- FF46: Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables - Techniques for WCAG 2.0

References

HTML4 Tables
SUMMARY and CAPTION - doit
HTML 5 and accessibility - Roger Johansson
HTML 5, microformats and testing accessibility - Bruce Lawson
HTML 5 and summary: the feast of shrimp? - Roberto Scano

Research and User Testing

User Testing footage of header/id combinations, @summary and @longdesc for HTML5 WG - Joshue O Connor

Raw Data

Google's TABLE attribute survey - Shows the summary attribute on ~2.5% of tables. Note: The following information was collected by Google in December 2005: Some of the semantic attributes on the table elements are used. The table element sees the summary attribute quite a bit, considering (though we have not checked how many of them simply say "Layout table, two columns, menu in the first column, content in the second" or some such). Also, although it isn't shown on the graphs above, the td element sees the headers, scope and abbr attributes sometimes too (and the last two are also sometimes seen on th as well). There was no measurable use of the axis attribute, though.

Sites "In the Wild" Which Use Summary

AFB: American Foundation for the Blind
1. summary="This table holds a colored bar that separates the page content from the header."
2. summary="This table is used to contain the content of this page. The first cell will contain a photo. The second cell will contain primary information on this page. The third cell will contain links to secondary information."
3. summary="This table contains the legal notice."
Audible (USA) uses summaries on users' Wishlist, Shopping Cart, Check Out, etc.
- + Checkout Table:
  1. summary="This table lists the items in your shopping cart after applying credits and discounts. The Total price is the amount that would be charged to your credit card when you click on complete purchase"
  + Shopping Cart Table:
  1. summary="This table lists the items in your shopping cart."
Bank of America {USA}
- + Accessible Banking
  1. summary="This table holds the link to change the state setting."
  2. summary="Content Table"
  + Find ATMs and Banking Centers
  1. summary="SearchBox"
  2. summary="Table to hold Language Toggle."
Mozilla Accessibility Project
- + summary="Mozilla accessibility discussion groups"
  1. Note: the table on the Mozilla Accessibility Project front page uses scope="col"
SourceForge.net
- + examples:
  1. summary="Latest file listings for the Gaim project"
  2. summary="File listings for the Int64.org project"
Tesco {UK}
- + Tesco Access (page describing how accessibility has been built-into the latest iteration of the Tesco web site.)
Univeristy of Minnesota Duluth
- + eClasses
  1. summary="This table presents the eclass information. In rows, you will find information specific to each class. In columns, you will discover links to class descriptions, scheduled dates, times, and locations."
- + Equipment in Classooms
  1. summary="This table shows what resources are available in the general purpose classrooms. The first column lists the building name, the second column lists the room numbers, and the remainder of the columns list the technology."
  + Web Development
  1. summary="This table charts the self paced Web Development training materials available. It provides class name in the first column, a link to the materials in the second column, and the author in the third column."

User Agent support including Browsers and Assistive Technology

GwMicro: Window Eyes

19.14 in the Window Eyes Manual explains "Table Summary – This option will add the table summary (if one exists) to the announcement of the beginning of the table."

Window Eyes support for @summary dates back to version 4.5.

Freedom Scientific: JAWS

The Freedom Scientific website states:

“The most common type of table contains data, and is called a data table. JAWS announces when you enter and leave a table. A well-designed HTML table has several features. One of these is a caption, […] Another design feature is the table summary. The table summary is not visible on the screen to sighted users. Web page designers can add summaries to the HTML code specifically for screen reader users. A good table summary provides a meaningful overview of the table, giving you some idea of what the table contains before you get there. Pay particular attention to the table summaries as you read through this page.”

The following link is to test cases and summaries what browsers do today including many examples of how the @summary can be used to aid comprehension of data tables for non-sighted users..

Surf's Up! - Tables with JAWS

Related E-mail Threads:

May 2007

June 2007