Change Proposal for Table Summary and related accessibility features

Summary

The <table> element in HTML 4 supported an attribute, @summary, which was intended to provide high-level information about the table to users who could not see it. It was intended to hold the sort of information that is recommended by the The National Braille Association's Tape Recording Manual, 3rd edition (originally copyrighted in 1971) "Describe the physical structure of the table. The names of the parts of a table are shown in this example (graphic of a table). Include the number of columns, the headings of each column and any associated subcolumns, reading from left to right."

On the web, if a table is marked up correctly (with th, td, caption, etc), when a screen reader encounters a table it will announce how many rows and columns are contained within the table.

The manual goes on to suggest, "Explain whether the table will be read by rows (horizontally) or by columns (vertically). The horizontal reading is usual but, in some cases, the vertical reading better conveys the content. On rare occasions it is necessary to read a table both ways." This is the type of information an author might put in the summary attribute.

Additionally, an author could suggest other overview information that might be immediately obvious to someone looking at the table but would take time to draw the same conclusions when accessing the table aurally. This would include highlighting trends, the largest or smallest values, etc., and describing the purpose of the table. It could also summarize the purpose of the table, that is, what the author wants the reader to draw from the inclusion of the table.

The current editor's draft of the HTML 5 spec documents alternative mechanisms for providing a visible caption of the table, recommends against using @summary, and treats it as an obsolete attribute. The reasoning for this is that @summary, because it is not visible to all users, is frequently incorrectly used. However, many members of the working group feel that the information provided by summary would often be redundant for sighted users, and would therefore be left out. Some of the proposed alternatives also don't link the describing information via markup to the table, so a user who cannot see the table might not know it is there or that it relates to the table.

This proposal attempts to separate out the parts that can reasonable to derived from markup, to add a separate attribute for reading direction, and to reserve the summary attribute for summarizing the purpose of the table and any trends that might be obvious from viewing the table visually, as a whole, but not from navigating the table cell-by-cell.

note: much of the text above came from a private email exchange I had with Wendy Chisholm, co-author of Universal Design for Web Applications.

Rationale

The text in the current editors draft does not provide a good way to supply information about the table that is only needed by users who are not looking at the visual rendering of the table. While this information can be provided in visible text, such as in a caption or in a paragraph near the table, it is unlikely that authors would generally provide information in those places that would be obvious by looking at the table.

Details

1. Add to the DOM Interface, n Section 4.9.1 The Table Element,

   attribute DOMString summary;

2. Move the summary attribute to just after the paragraph that reads

   Tables have rows and columns given by their descendants. A table must not have an empty row or column, as described in the description of the table model.

3. Use the following text for the summary attribute

   The summary attribute provides a summary of the table's purpose for user agents rendering to non-visual media such as speech and Braille.

   Earlier versions of HTML suggested using summary to provide structural information about the table. This version instead recommends using summary only for information about the table which cannot be derived from the markup. [NOTE: additional related proposals are being developed to improve the table markup to make this feasible]

   The information provided by the summary is needed by users who cannot see the table, but would usually be redundant for those who can. Authors SHOULD use either @summary or <caption><details> to provide information that is obvious to visual users of the table, but would be difficult to determine by navigating the table cell by cell in an auditory user agent, and which cannot be derived by the user agent from the markup. Because it can be quite time-consuming to explore a table with a non-visual user agent, authors SHOULD use summary or <caption><details> to give enough information for users to decide if they need to explore the table further, highlighting the general idea that is to be drawn from the table, describing trends, high and low points, and the like. Authors SHOULD use <caption><details> where a visible, expandable caption is acceptable, but MAY use @summary where business, usability, aesthetic, or other considerations do not allow a visible caption.

   For tables where the relationships are not obvious to users who can see the layout, or in other situations where text describing the structure of the table might be useful to sighted users as well as users of screen-readers and Braille devices, authors SHOULD describe the table using the a caption, legend, or surrounding text instead of, or in addition to, summary. Authors MUST do this in a way that is associated with the table via markup, such that user agents and assistive technology can programmatically determine the relationship. When using @summary or >caption<>details< in combination with another technique, authors MUST NOT duplicate the text, but instead use @summary or >caption<>details< for the parts of the description that are only useful to users who cannot see the table.

   User agents MUST expose summary text in the accessibility API on their platform as specified in the Mappings from HTML to Platform APIs document [note: This document is still under development and does not yet have a stable URL. It will have one before last call]. Non-visual user agents MUST render summary. Visual user agents SHOULD NOT render summary visually by default in non-editing scenarios. Visual user agents SHOULD provide a User Interface mechanism to toggle display of @summary and <details>[NOTE: Explore (at a near future date) what, if any, other hidden human-readable metadata should be covered by that UI], and MAY render these features by default in editing scenarios.

   Authoring tools MUST make it possible for authors to add and edit @summary. WSYIWYG authoring tools SHOULD render @summary visually.

4. add examples from this file [1]
5. Add a sub-section of 4.9 with the following text

   Guidance for Conformance Checkers

   A table which includes a @summary attribute or a <caption> element with a child <details> element. the advisory may explain that summary is to be used for spatial information that will be obvious and redundant to a visual user, or where visible text would cause usability or design issues. One of the other techniques should be used when visible information would be useful to all users, and would not interfere with the usability, design, understandability or function of the page.

   
   

6. remove summary from the obsolete but conforming section

Impact

Positive Effects

• Authors would have a mechanism for providing to non-visual users the information that is difficult for them to glean by navigating around the table.
• Authors who are trying to optimize for accessibility will not get validator warnings for doing so.
• Table structure and directionality are separated from summary, and left to browsers and AT to manage for users. This should mean that fewer tables require summary.
• HTML and WCAG will not be giving contradictory advice.

Negative Effects

• Summary is still "hidden metadata." Because authors and testers don't encounter it in their daily activities, hidden metadata has the risk of being incorrect or getting out of date. However, this can be mitigated by designing authoring tools to expose it. There is text to that effect in the proposal.

Conformance Classes Changes

None

Risks

• Some have expressed a concern that any human-readable content which is not visible to authors in mainstream browsers with default settings will frequently not be added or kept up to date by authors. Summary falls into this category. The risk of leaving it in is small, namely that the status quo remains, and some summaries are incorrect. This proposal includes several mitigations for this risk: Authoring tools are recommended to render summary by default, user agents are recommended to provide a user interface mechanism to toggle visibility of summary, and the goals of summary are clarified to a high-level description of the table, leaving out parts that can be derived by AT from the structure of the table.

• The risk of obsoleting summary, as in proposed in the current HTML 5 draft, is larger namely that there would be no mechanism for authors to provide information about the table which can't be derived from the markup, and which would interfere with the design or function of the page were it visible.

• There is a risk that AT vendors will not improve the user experience of structure-based AT description to a point that describing it in summary is no longer necessary. However, this risk is more pronounced if this proposal is not accepted.

• There is a risk that proposals related to this one, dealing with table orientation and better access to the layout and structure of the table from the DOM and accessibility APIs, will not be adopted. This risk is also somewhat mitigated by keeping the summary attribute, as it provides a mechanism for authors to work around these shortcomings.

References

• The National Braille Association's Tape Recording Manual, 3rd edition (originally copyrighted in 1971). Excerpts available from the w3c at[2]]
• [3]
• Mechanism to Summarize a Table [[4]]
• Earlier drafts and discussion of this proposal
  • On public-html-a11y [5]
  • On public-html [6]
• Earlier draft of changes to Section 4.9 Table

Use one of the following ways to provide the specifics of your proposal:

1. Edit the table section according the linked HTML document [7]. Changes include
   1. adding orientation attribute and descriptive text
   2. adding summary attribute and descriptive text
   3. minor edits in the descriptions of the alternative mechanisms to summary
   4. Adding methods to the cell API for retrieving headings for the current cell
   5. Add guidance for conformance checkers
   6. Add guidance for authoring tools
2. remove summary from the obsolete but conforming section