• HTML
• SummaryForTABLE

Mechanism to Summarize a Table

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

Issue

Vision impaired screen reader users listen to outputted information, without any visual cues, and HTML 5 currently lacks a programmatically-determined mechanism that gives an overview of complex tabular data or a brief explanation of that data. In HTML 4 this often much needed information is provided via the summary attribute.

HTML 5 lacks a specific explicitly associated, programmatic mechanism to provide a table with a summary. This feature is required in order to provide an overview of tabular data or a brief explanation of how to navigate a data table for Blind/Non-Visual Users 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. A summary mechanism 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. Rows contain destinations, traveling dates, and grand total. Columns contain expense category and total. The first column contains merged table cells.">
<!-- Remainder of table -->

A survey of existing web content showed that this attribute was rarely used, and, when it was, it was frequently misused, leading to the conclusion that it should be removed from HTML 5.

On the other hand, the attribute has been in HTML since HTML 4, there are sites that use it correctly, and the WAI community has provided advice in support of inclusion. Some proposed long term solutions have been offered for growth to better practice.

Latest Published Draft

The latest published draft does not incorporate a summary attribute or element. Instead it uses the caption element. It says:

"The caption element should be included for any table where the reader might have difficulty understanding the content or where the table's structure would not be obvious to the user of a screen reader. The element's contents should describe what the purpose of the table is, along with any information that could be useful for understanding and using the table."

• This draft text applies table summary functionality universally, and in a such way that it is not possible to distinguish the summary from the caption.
• Most of the debate around providing a summary mechanism has been about misunderstanding its purpose, so trying to merge its purpose with another element's purpose may be problematic leading to more confusion.

• The purpose of the caption element and the summary attribute historically have been completely different (caption titles the table, summary describes how the table should be read by people who cannot see how the table has been rendered).

  • HTML 4 states: "Each table may have an associated caption (see the CAPTION element) that 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."

  • WCAG2's H73 Technique states: that a summary provides "a brief overview of how data has been organized into a table or a brief explanation of how to navigate the table."

• Providing summary information visually by default would be extra verbiage that most authors/designers would be reluctant to include visually on a page because of redundancy. (For more info see sighted use case).

Status

Open Issue not yet decided:

• 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

• Action 76: Chris Wilson to Create poll on issue-32, based on Joshue's page from action-66

• Action 104: Chris Wilson to Inquire about table summary and headers status at PFWG caucus on 2009-02-06

• Action 111: Sam Ruby to Send call to working group on summary to update wiki in preparation for vote

• Action 126: Sam Ruby to Send a call to the WG to update the Wiki page to adequately reflect both (all) viewpoints on summary, in prep. for a vote

  • Discussion in June 4, 2009 Teleconference Issue is at an impasse.

Table of Contents:

Use Cases

Blind/Non-Visual Users

A programmatically-determined summary mechanism serves a very specific and most critical use for blind and non-visual users. It provides an affordance equivalent to the visual user scanning a table for spatial structure, orientation, and relevance. A summary mechanism provides a reasonable accommodation. It enables a person with a visual disability to have an equal opportunity.

A textual summary enables this user group to get an overview of a table without seeing the relationships between the rows and columns implied by its spatial structure. It is an essential aid to comprehension for the visually impaired. It provides the AT user a way to easily form a mental image of a table's contents in order to better understand its structure, or semantic relationships. When a screen-reader user in JAWS navigates in table mode, he can hear the summary of each table in a document with one key press.

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. This is a very tedious and time consuming process.

Sighted Users

For the majority of sighted users a summary is not needed. For instance:

<table summary="Rows contain destinations, traveling dates, and grand total. Columns contain expense category and total. The first column contains merged table cells.">
<!-- Remainder of table -->

A sighted person can see how the rows and columns are laid out and where the cells merge by a quick scan or glance. They typically wouldn't need an explanation. Providing it visually would be extra verbiage that most authors/designers would be reluctant to include visually on a page because of redundancy.

However, a summary could be of use to a sighted user with cognitive disabilities or lower-literacy populations. It might also aid universal design.

Rationale: Why Summary Should Be Provided

1. 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.
2. 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.
3. A sighted person can see how table rows and columns are laid out and where the cells merge by a quick scan or glance. They typically wouldn't need an explanation.
4. Providing a summary visually would be extra verbiage that most authors/designers would be reluctant to include visually on a page because of redundancy.
5. 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.
6. 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.
7. A summary provides a reasonable accommodation. It enables a person with a visual disability to have an equal opportunity. Not providing a summary mechanism excludes people solely on the basis of disability. Removing it would be discrimination.
8. 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.
9. 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.

10. If something outside the <table> is used, 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.

11. If something is intended to help non-sighted users comprehend a complex structure, it's unlikely to help anyone else. The fact it doesn't help anyone else doesn't detract from its usefulness.
12. If something useful is misused, the solution would be to take steps to ensure it is used properly, rather than removing it completely.
13. A combination of training and better tools can address poor authoring of the attributes value.
14. 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.
15. 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.

16. 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).

17. @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.
18. 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.
19. Including @summary solves a real problem.
20. Including @summary removes an obstacle to accessibility advocates promoting the use of HTML5. @summary will remain in use for accessible web pages until something better is available. Removal undercuts the HTML5 "use it now" story if what HTML5 authoring advice and the omnipresent accessible-authoring advice are in conflict. HTML5 doesn't need this bad press for a change from HTML4 that doesn't solve a real problem.
21. A table summary is only content to the blind/nonvisual use case. To everyone else it is just fluff and not needed. If others want access they can use CSS.
22. A table summary isn't of help other disability groups except the blind.

23. The attribute has been in HTML since HTML 4, there are some sites that use it correctly, and the WAI community has recommended its continued inclusion until at least a better replacement is deployed and stable. "Evolution not revolution".

24. @summary is implemented most well known authoring tools, such as Dreamweaver and Mozilla editors (SeaMonkey editor, Thunderbird, NVU). Lots of text editors with syntax coloring (VIM, TextMate, BBedit etc) will have to mark summary="" with a color that shows it as invalid - if they want to conform to HTML 5. Some of the users of those tools would complain if @summary was removed. Since the HTML5 specification currently tries it's utmost to satisfy backward compatibility with a wide range of junky web pages and vagaries of backward compatibility with old browsers, it would seem reasonable to ask that consideration also be given to users of existing authoring tools.

25. The spec should allow for explicit associations of related pieces of content if this association aids in conveying context and content relationships to users, whenever implicit associations do not provide this functionality.

26. Ian Hickson wrote: "I think it's clear that summary="" could solve the problem if used right." - February 24, 2009.

27. Applicable Design Principles (Note: These 26 November 2007 principles are only a draft. They have not gained consensus)

    • Accessibility: "Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential. This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided. The image in an img may not be visible to blind users, but that is a reason to provide alternate text, not to leave out images."

    • Media Independence: "Features should, when possible, work across different platforms, devices, and media. This should not be taken to mean that a feature should be omitted just because some media or platforms can't support it. For example, interactive features should not be omitted merely because they can not be represented in a printed document."

    • Pave the cowpaths: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."

    • Evolution Not Revolution: "Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes."

    • Solve Real Problems: "Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible."

    • Priority of Constituencies: "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity."

    • Do not Reinvent the Wheel: "If there is already a widely used and implemented technology covering particular use cases, consider specifying that technology in preference to inventing something new for the same purpose. Sometimes, though, new use cases may call for a new approach instead of more extensions on an old approach."

Rationale: Why Summary Should Not Be Provided

1. @summary was not solving a real problem. There is no browser savings from removing it. The browser still puts it in the DOM if it's there and AT takes advantage.
2. 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).
3. Summary is explicitly invisible metadata and therefore is more likely to be missing or inaccurate than data that is visible to all UAs. It is too media-specific.

4. @summary hurts users who don't have access to it, hiding information that they might find useful. A summary could be of use to a sighted user with cognitive disabilities or lower-literacy populations. Ian Hickson wrote: "It seems like it would fail to help users that don't get access to it (like users of visual browsers)." - February 24, 2009.

5. @summary attribute fails to improve accessibility in practice, despite being promising in theory.
6. 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, 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.

7. @summary is too difficult to author. PFWG charter injunction seeks technologies that are 'authorable' - conducive to getting good content within the defined markup, high usability and easy to author based on the formulation of content formats and service protocols.

8. A survey of existing web content showed that this attribute was rarely used, and, when it was, it was frequently misused, leading to the conclusion that it should be removed from HTML 5.
9. We should investigate any and all solutions that would help users (all users) understand the Web better.

10. Applicable Design Principles (Note: These 26 November 2007 principles are only a draft. They have not gained consensus)

    • Accessibility: "Design features to be accessible to users with disabilities. Access by everyone regardless of ability is essential. This does not mean that features should be omitted entirely if not all users can make full use of them, but alternate mechanisms should be provided. The image in an img may not be visible to blind users, but that is a reason to provide alternate text, not to leave out images."

    • Media Independence: "Features should, when possible, work across different platforms, devices, and media. This should not be taken to mean that a feature should be omitted just because some media or platforms can't support it. For example, interactive features should not be omitted merely because they can not be represented in a printed document."

    • Pave the cowpaths: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."

    • Evolution Not Revolution: "Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes."

    • Solve Real Problems: "Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible."

    • Priority of Constituencies: "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity."

    • Do not Reinvent the Wheel: "If there is already a widely used and implemented technology covering particular use cases, consider specifying that technology in preference to inventing something new for the same purpose. Sometimes, though, new use cases may call for a new approach instead of more extensions on an old approach."

Advice Requests 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.

• Re: Request for PFWG WAI review of summary for tabular data - Laura L. Carlson, May 4, 2009.

Advice From PFWG

August 6, 2008

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

1. @summary should stay
2. It provides a needed service.
3. Element content providing this info, *if linked by markup to the table* offers growth to even better practice.
4. Don't have the linking markup yet; is a developmental item.
5. 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.

June 4, 2009

The following consensus was reached by Protocols and Formats Working Group during its teleconference of Wednesday, 4 June 2009:

We request the table summary tag be restored in HTML 5 as per previous communications.

Rationale:

• Summary serves a need, and serves it well. It is familiar to users. It is supported in browsers. It is properly utilized on many web sites which strive to be accessible.
• If it didn't exist, we'd need to invent it. Indeed, such alternative approaches as have been proposed constitute a "reinvention" of summary. PF wishes to move on to address accessibility concerns in areas, such as canvas, where no good solution currently exists rather than reinventing summary.
• We reject the argument that summary should be removed from the HTML specification because it is not implemented on most web sites. We note that accessibility is poorly supported on most web sites. The wider web is not an example of good practice.
• We need summary for backward compatibility.
• We note that summary is often used as a technique for accessibility support where governmental regulations require governmental web sites to be accessible. An example is the U.S. Government's Social Security Administration (SSA) pages as SSA conforms to its "Section 508." mandate:

  • http://www.usdoj.gov/crt/508/web.php

  • http://www.access-board.gov/sec508/guide/1194.22.htm#(g)

• If summary is removed, U.S. Government web sites, might find it more difficult to conform to HTML 5. We further note that Section 508 regulations apply to U.S. state and local governments, and that similar accessibility requirements are emerging in Canada, the U.K., the E.U., Australia, and elsewhere.
• Restoring summary in HTML 5 would not, in our understanding, negatively impact HTML 5 in any way.

Source: PF Response: @Summary - Janina Sajka, June 3, 2009.

Steps to Implement PFWG Recommendations (Al Gilman, Nov 21, 2008)

1. Restore @summary in HTML5.

   • Update February 2008: Several versions of RFC 2119 compatible definition text for HTML 5 have been drafted by HTML WG Members. (Additional options have also been discussed on public-html.)

2. Add <summary> or equivalent in HTML5, meeting the programmatically-determined standard of WCAG (example: the proposed 'text in context' approach for providing text alternatives).

3. Once WAI-ARIA is deployed, there is an interim solution for "summary in context" markup which uses @aria-describedby linking from <table> to an element containing the summary description.

4. Once number 2 meets CR standard of two interoperable implementations, HTML5 authoring advice favors <summary> (or equivalent.) HTML5 document may mark @summary as "deprecated".

5. Once number 2 meets "accessibility supported technology" standard of WCAG2, HTML5 may remove @summary (only then).

---

Proposed Solutions to Fulfill PFWG Recommendations

Short Term Solution

Reinstate @summary Now

• Provide a summary via the @summary attribute.

  • Several versions of RFC 2119 compatible definition text for HTML 5 have been drafted.

---

Mid Term Solution

aria-descriebedby

• Provides interim solution for "summary in context" until <summary> or equivalent is in HTML5

• Does not meet the programmatically-determined standard of WCAG.

• aria-descriebedby could be used to provide a long description for the table, but that's not the purpose of the summary attribute.

---

Long Term Solution Possibilies

<summary> Element

Proposal by L. Carlson (based on Al Gilman's proposal)

• Create a new <summary> element as suggested by PFWG to provide a concise table summary. Intent is to provide a brief overview of how data has been organized into a table or a brief explanation of how to navigate the table.

• Could work alongside <tdesc> or <tdescription> or <desc> or aria-descriebedby.

• Restrict <summary> to only accept inline content such as abbreviations, emphasis, etc.

• Allow an "open" display attribute similar to the one on the <details> element that would allow it to be available not only to the vision impaired but also to the sighted on demand.

• Summary attribute and summary element could be synonymous - summary as element would be preferred, but summary as an attribute would be a backwards-compatible fall-back. 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.

• Related References:

  • summary element in XHTML2.

Outcomes

• Would address the Blind/Non-Visual Use Case.

• Because of the "open" attribute it

  • Would address a Sighted Use Case and could aid universal design. The "open" attribute would allow anyone to be able to use information.

  • Would be easier for authors (especially sighted ones) to comprehend which could lead to improved use. The "open" attribute would help authors check accuracy visually in browser (like a built in table inspector).
  • Would be less likely to be inaccurate than data that is invisible to some UAs.
  • Could be set false, which means that AT users who usually get that information by default would have to opt-in to it for each table.
  • Potential for visual designers to provide null summaries, so that page appearance is not "ruined" by information being displayed. Result would be fewer tables would have needed summaries.

• Would solve the caption/summary confusion that the current draft introduces.

• Would allow richer information.
  • The downside of that is that what was meant to be a concise overview of how the data has been organized may not remain a summary.
• Would provide an i18n advantage. Language or text directionality can be supported in an element that allows in-line content.

• Would meet the programmatically-determined standard of WCAG.

• Could break existing content that uses the summary attribute unless summary attribute and summary element were synonymous.

• Moving from an attribute to an element for a summary type mechanism would evolve an existing design rather than throwing it away. (Evolution Not Revolution design principle.)

• Would address the other relevant design principles.

---

<summary> proposal Variation

• <summary> proposal by Leif Halvard Silli

---

<details> as a child of <caption> or <figure><legend>

• <details> as a child of <caption> or <figure><legend> Proposal by James Graham

---

Summary Automatically Generated by User Agent

HTML 5 defines which headers apply to which cells, and obviously a user-agent knows which cells are merged, so possibly there could be an algorithmic way of generating descriptions of table structures for any (or at least a large proportion of) data tables. A user-agent could have a 'describe table structure' feature which is independent of an author providing a good (or indeed any) summary.

• Smylers and Simon Pieters brainstorming a solution

Outcomes

• In terms of getting the information to those users who need it, this may have more success than engaging authors to write good summaries: user-agent developers seem on average more likely to follow the HTML 5 spec than most authors, and there are fewer of them.
• If this were possible it would reduce the number of tables which require a handwritten summary, reducing the burden on authors.

---

Related Ideas to Increase Accessibility

<tdesc> or <tdescription> or <desc>

• Create a new <tdesc> or <tdescription> or <desc> child element of <table> to provide a full description to work alongside <summary>. It would be the element version of aria-describedby.

• Would serve a different purpose than <summary>. <summary> would provide a concise description of the table's structure. <tdesc> or <tdescription> or <desc> would provide a long description.

• Allow it to be a block-level element that allows block-level content.

• Allow an "open" display attribute similar to the one on the <details> element that would allow it to be available not only to the vision impaired but also to the sighted on demand.

• Related References:

  • <desc> has been proposed as A Unified Approach to HTML5's Media Specific Elements - By Gregory J. Rosmaita.

Outcomes

• A <desc> element could be extended beyond simply <table> and be repurposed where needed. (perhaps help with <canvas> or <longdesc> or <audio> or <video>).

• Authors would understand a description element's purpose, increasing usability and authorability.

• Would address the Blind/Non-Visual Use Case.

• Because of the "open" attribute it

  • Would address a Sighted Use Case and could aid universal design.

  • Would be easy for authors (especially sighted ones) to comprehend which would lead to improved use.
  • Would be less likely to be inaccurate than data that is invisible to some UAs.

• Would solve the caption/summary confusion that the current draft introduces.

• Would meet the programmatically-determined standard of WCAG.

• Would address the relevant design principles.

<details> as Child of a <table>

• Allow <details> as a child of a <table> to provide a full description to work alongside <summary>.

• Would serve a differnt purpose than <summary> and @summary. <summary> and @summary would provide a concise description of the table's structure. <details> would provide a long description.

• Allow "open" display attribute making content available not only to the vision impaired, but also the sighted and people with cognitive disabilities.
• Related References:

  • details explanation from IBM

    • Each <details> element can have an "open" attribute. If it has this attribute, then the details will be initially shown to the reader. If it doesn't have such an attribute, then they will be hidden until the user asks for them. In either case, the user can click an icon or other indicator to show or hide the details. If <summary> and <desc> had something like that it could help sighted people with cognitive impairments and lower-literacy populations.

    • Explain how UAs are to update the <details> element in response to request - commit-watchers-whatwg.

Outcomes

• <details> already has a legend so it could be confused with caption.

• Would address the Blind/Non-Visual Use Case.

  • Because of the "open" attribute it

    • Would address a Sighted Use Case and could aid universal design.

    • Would be easier for authors (especially sighted ones) to comprehend which would lead to improved use.
    • Would be less likely to be inaccurate than data that is invisible to some UAs.

• Would solve the caption/summary confusion that the current draft introduces.

• Would meet the programmatically-determined standard of WCAG.

• Is not backwards compatible. Does not work in current AT.
• Could be capable of handling structured content (block and inline text structure, such as abbreviations, emphasis, headings, etc.)

• Would address the relevant design principles.

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 and Blog posts

• 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

• HTML 5, politics and me - Bruce Lawson

• Day 20: Providing a summary for tables - Mark Pilgrim

• The longdesc lottery - Mark Pilgrim, Google.

• Help screen reader users by giving data tables a summary - Roger Johansson

• Purpose of the summary Attribute - Gez Lemon

• Alternate text in HTML 5 By Bruce Lawson

*Comic Update: HTML5 Stubborness and Snogging By Kyle Weems

Research and User Testing

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

• When does non-visual User Agents announce table summaries and captions? - leif halvard silli..

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.

• summary attribute usage data - Steve Faulkner

• @summary study - Philip Taylor

• Opera MAMA - a sneak peek at headings, images and summary

• This table lists the usage of <table summary> in a selection of ~425K pages from Dotbot

Sites "In the Wild" Which Use Summary

• Sortable headings for search bookshare results tables.

  1. summary="Search results sorted by title, ascending"

• 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.)

• University 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."

• Old W3C Site Used

  • summary="Layout table: The first cell contains a navigation bar of W3C technologies, the second contains news, and the third another navigation bar of W3C pages."

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

• Rationale for removing the summary and headers attributes from tables?

• <table summary> and <td headers> (was: Re: <font> (was Support Existing Content

• Use of headers and summary attributes

June 2007

• HTML5 Retention of summary attribute for TABLE

• fear of invisible metadata

• danger of null value for summary attribute

• html 5 and accessibility issue

August 2007

• Baby Steps or Backwards Steps?

September 2007

• User Testing footage of header/id combinations, @summary and @longdesc for HTML5 WG

February 2008

• Retention of @summary for Table Element

March 2008

• Re: several messages about tables and related subjects

April 2008

• Re: summary issue closed

June 2008

• mechanism to provide a summary of high density information easily discernible from a cursory visual glance

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

August 2008

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

December 2008

• Table feedback - Ian Hickson (Saturday, 20 December)

February 2009

• Draft text for summary attribute definition

• Caption and summary survey

• Summary="" in HTML5

• Re: summary="" in HTML5 ISSUE-32

• Use and abuse of @summary

• Caption@title instead of table@summary?

• table caption as a short description, @summary as a long description

March 2009

• Re: Draft text for summary attribute definition

• Re: summary="" in HTML5 ISSUE-32

• Summary attribute: attention and focus

April 2009

• Table summaries - data on using <caption title="">

May 2009

• Re: Request for PFWG WAI review of summary for tabular data

• Re: minutes: HTML WG Weekly 21 May 2009 (draft)

• Re: minutes: HTML WG Weekly 21 May 2009 (draft)

June 2009

• table summary

• PF Response: @Summary Janina Sajka

• Discussion in June 4, 2009 Teleconference Issue is at an impasse. Message to be sent to working group on summary to update wiki in preparation for vote.

• Summary of Thursday's IRC conversation about @summary

• What makes a failure? (@summary, et al)

• font color="blue"

• What makes a failure? @summary, et al

• A generalized <summary> element

• Re: Opportunity costs ... Re: Summary of Thursday's IRC conversation about @summary

• Disambiguating @summary from a long descriptor

• Issues of @summary and use of data for "decisions"

• evidence of harm

• Re: Request to Strengthen the HTML5 Accessibility Design Principle

• Re: Example of Good Summary

• Why I don't attend the weekly teleconference (Was: Input on the agenda)

• Re: use of data for "decisions" (Was: Issues of @summary and use of data for "decisions")

• Re: Scientific Studies of the Summary Attribute (was: Why I don't attend the weekly teleconference)

July 2009

• Re: Issues of @summary and use of data for "decisions"

• Nothing is really hidden

Search on Markmail for Related E-mail

• "summary attribute" search

• "table summary" search