Warning:
This wiki has been archived and is now read-only.

ChangeProposals/ReinstateTableSummary

From HTML WG Wiki

Jump to: navigation, search

Change Proposal: Reinstate the table summary attribute as a fully conforming part of HTML 5

Authors: Joshue O Connor, Léonie Watson, Laura Carlson
Date: July 2011, Last updated on September 6, 2011.

Summary

The current editor's draft lacks a conforming way to provide a non-visual, accessible table summary mechanism for non sighted users of Assistive Technology. The status of the summary attribute in HTML 5 is that it is obsolete. [1]

In order to support the many users of older Assistive Technology, as well as current user agent support for @summary this change proposal:

Makes the summary attribute fully conforming and not obsolete in HTML 5.

What the summary attribute does has been well documented elsewhere, it is supported by many browsers and Assistive Technologies, and is announced on table element focus after the caption element (if present) without any further user interaction or keypress. [2]

@summary has often been critised by the HTML 5 working group as for being ‘hidden meta data’ or simply prone to misuse as well as actively harming accessibility because it is not available to all users. [3]

None of these reasons are definitive, and @summary’s current status as obsolete is against the advice of the PFWG who officially lobbied for its retention requesting review and debate. [4] [5]

There have been several change proposals drafted for either extending the functionality of @summary or replacing it. This CP is asking that it simply be reinstated.

Rationale

Identification of Use Cases

The chairs stated that the issue could be re-opened with the:

"identification of specific use cases, along with a number of specific
examples from real-world sites, where a separate table summary would be useful either instead of or in addition to a caption element or an aria-describedby attribute. Ideally such use cases would explain why this is needed only for tables but not also for images or canvas elements which could express the same information using a different mechanism." [10]

Several new use cases from the wild have been added to the "examples of @summary in the wild" section of the wiki for the attention of the chairs. These are real world examples that provide evidence of use.

@summary in use

The @summary attribute contents are read out by a screen reader as soon as the focused table element receives focus. A screen reader user can navigate HTML content by selecting elements directly using their AT, therefore allowing the user to navigate quickly. Therefore explicit programmatic determination such as the current use of @summary that is understood by existing AT, is very useful as existing UAs can easily use this data to give the user a quick overview of a data table structure within the context of the current element focus.

HTML5 and @summary

In section 4.9.1 the spec states:

"If a table element has a summary attribute, and the user agent has not classified the table as a layout table, the user agent may report the contents of that attribute to the user.”

The link that describes @summary then advises the author to use one of the ‘techniques for describing tables’ instead. This advice is contradictory for several reasons. The spec currenly re-enforces the idea that the "description" is a replacement for visually obtained information.

In section 4.9.1.1 the spec states:

"For tables that consist of more than just a grid of cells with headers in
the first row and headers in the first column, and for any table in general where the reader might have difficulty understanding the content, authors should include explanatory information introducing the table. This information is useful for all users, but is especially useful for users who
cannot see the table, e.g. users of screen readers."

The spec then provides an example table, and follows it up with the following suggestion:

"...might benefit from a description explaining the way the table is laid
out, something like "Characteristics are given in the second column, with the negative side in the left column and the positive side in the right
column."

This description is clearly an alternative for visually obtained information. However, does it add any benefit to sighted users or is it of any benefit to people with learning disabilities?

There is undoubtedly a use case for some explanatory information being made available to all users. That use case is quite distinct from the need for an alternative that describes the visual structure of the table, for the benefit only of people unable to see it in the first place.

Secondly, there are also some problems with the accessibility of the current examples and how they are supported in current screen readers and browsers. Also the impact this may have on older legacy user agents needs to be considered.

Let us examine some of the examples for data table descriptions in the spec:

The first example has no programmatic connection between the table and the paragraph that it provides the summary of. So if the screen reader user focuses on the table by using the navigation features available within their screen reader, they will miss this information contained within the p element. If they read the content in a linear way, then they will discover the paragraph before the table, but as outlined this very well may not happen.

The second technique suggests using the caption element to provide the summary information, and the third technique suggests using the caption

element inside the details element. These techniques can be considered to be accessible as they both place the summary within the table itself. That said, the second technique also potentially creates a degree of semantic confusion. The purpose of a table summary and a table caption are quite distinct.

The third technique is also problematic for screen reader users, as no current versions support the details element. The information within the details element is simply announced as a string in VoiceOver, Jaws, Window Eyes and NVDA.

The fourth and fifth techniques suggest using the figure and figcaption elements to provide summary information. As with the first technique, these techniques open up the possibility that a screen reader user may never be aware of the available summary information.

Screen reader test details: VoiceOver tested on Mac OS X 10.6.7 with Safari 5.0.5, and Jaws 12, Window Eyes 7.5 and NVDA 2011.1 tested on Windows with Internet Explorer 8, Internet Explorer 9, Firefox 4 and Firefox 5, all fail to announce information within the figure or figcaption elements when the table is focused on directly using the screen reader's navigation commands. Note: Whilst testing was carried out with current browsers and screen readers (with a reasonable chance of UA support), these techniques would not work at all in older Uas. Also t he use of the figure element does not currently provide the same level of accessibility in current User Agents (screen readers).

Where as many of the techniques also work well as an aid to comprehension for sighted people, they are not actually suitable for blind people using the above mentioned assistive technology. The option to use @summary as a valid attribute within HTML 5 fulfills a specific use case where access to visually obtained data is imperitive as an aid to comprehension to blind users, but of little assistance to sighted users who can access it in the original.

Note: that in the example, ‘Table Caption, in a details element’ – the content of the caption including the details element are announced on focus using a screen reader. However, the use of the details element is currently unannounced in JAWS 12 and in VoiceOver so the text string is read out. Note that using HTML 4 and adding a caption with a suitable @summary would retain the visual presentation of the contents within the browser but hide the @summary from non users of AT. This is a desirable option to have as the @summary content may not be useful to sighted people in every instance so retaining the option to do this in a valid conforming way in HTML 5 would make sense. [6]

Being able to easily access the kind of information that can be added to a data table via the @summary is important functionality for a blind person, as they do not have to try to ‘discover’ any extra/supplementary information that could provide useful descriptions of the tables purpose – using @summary does this already. Additional information that is provided in another element such as in the figure or figcaptionmay be missed by the screen reader user, as in the following example from the HTML 5 spec.

Whereas many of the examples in the spec are good for sighted users as an aid to comprehension, they are often not suitable for non-sighted users, so the option to use the @summary as a valid attribute in HTML5 is a common sense solution.

While the descriptions may be hidden by CSS etc this defeats the purpose of the current specs stance of having the ability to display them for everyone. However, it is best to support both use cases where a description may not need to be visually displayed (of which there may be many use cases).

When testing the example ‘Next to the table, in the same figure’ using JAWS 12 and VoiceOver none of the figure or figcaption contents were announced when the table received focus using the navigation functions of the screen reader. When a containing element first receives focus and the following figure content is read in a linear fashion then it is announced. However, this may not be the way a screen reader user will encounter the table.


<figure>

 <figcaption>Characteristics with positive and negative sides</figcaption>

 <p>Characteristics are given in the second column, with the

 negative side in the left column and the positive side in the right

 column.</p>

 <table>

  <thead>

   <tr>

    <th id="n"> Negative

    <th> Characteristic

    <th> Positive

  <tbody>

   <tr>

    <td headers="n r1"> Sad

    <th id="r1"> Mood

    <td> Happy

   <tr>

    <td headers="n r2"> Failing

    <th id="r2"> Grade

    <td> Passing

 </table>

</figure>

The same issues arises with the next example ‘Next to the table, in a figures’s figcaption'.

For example:


<figure>

 <figcaption>

  <strong>Characteristics with positive and negative sides</strong>

  <p>Characteristics are given in the second column, with the

  negative side in the left column and the positive side in the right

  column.</p>

 </figcaption>

 <table>

  <thead>

   <tr>

    <th id="n"> Negative

    <th> Characteristic

    <th> Positive

  <tbody>

   <tr>

    <td headers="n r1"> Sad

    <th id="r1"> Mood

    <td> Happy

   <tr>

    <td headers="n r2"> Failing

    <th id="r2"> Grade

    <td> Passing

 </table>

</figure>

In current screen readers (tested using the latest version of VoiceOver on Mac OSX 10.6.7 and Safari 5.0.5 and JAWS 12 in IE 8 and IE 9 none of the figure or figcaption data was announced on focus.

Note: While this testing was done with new browsers and AT (as of time of writing) with some chance of UA support being present, these mark up example would not work at all in older UAs.

ARIA and @summary

The Chairs' stated in the decision for new information to reopen the issue that the issue could be reopened with:

"Identification of specific operational problems with the aria-describedby attribute that make it not able to be programmatically determined or suitable for use as a table summary." [10]

There is some evidence to suggest that aria-describedby does not negate the need for table summary and this is further evidence of why @summary should not be dropped in favor of the aria-describedby attribute.

Gez Lemon also suggested that that using ARIA, as a workaround for a table summary would be way too cumbersome for authors. No one would want the text on the screen, as it would state what is visually evident. So to use ARIA, a person would have to write the content, hide it with CSS, an then reference the hidden text with aria-labelledby. That's so cumbersome that surely even the most enthusiastic ARIA supporter should realize that the summary attribute is far more efficient and already well supported.

Comparison of AT support for table@aria-label/labelledby/describedby

Leif Halvard Silli created a test page in order to check AT support for table@summary versus AT support for table@aria-label/labelledby/describedby.

The findings were that support for @aria-label/-labelledby/-describedby were only universally implemented for the IMG element - for the table element and most other non-IMG elements, the support was very bad if present at all. For @summary, in contrast, the support was much better.

Leif discovered that NVDA+Firefox where the only AT/UA combination which announced ARIA labels and descriptions for non-IMG elements. Whereas the great majority of AT combinations did announce @summary. NVDA (while it is a fine product) is a screen reader that doesn't have substantial market share in terms of usage by blind users.

Thus, at the current stage, removing support for @summary from HTML5 means that - for the broad range of ATs - there is nothing that can functionally replace it (aside from heuristic methods which are out of scope for consideration in this CP). [9]

Details

Replace the Current Text:

"The attribute on table elements was suggested in earlier versions of the language as a technique for providing explanatory text for complex tables for users of screen readers. One of the techniques described above should be used instead."

With Suggested Text:

The summary attribute represents a prose summary of the table's structure, primarily for user agents rendering to non-visual media such as speech and Braille. The value is text.

The primary purpose of the summary attribute is to provide concise guidance to people with vision impairments on how to read a table, where the structure and reading order is visually evident, but not available to some assistive technology users. The summary attribute is not intended to provide a long description of a data table.

The summary attribute may be set on the table element if the data it contains is of sufficient complexity that users of non-visual user agents would benefit from a prose description of the table's structure. If the table contains data considered to only require a short description, use the caption element. Do not repeat the content of the caption element as content in the summary attribute.

The attribute may only be set on tables that contain tabular data. The attribute must not be set on tables used for layout purposes. The attribute should not be set to the empty string.

Any user agent may provide a mechanism to access the summary attribute content. If the mechanism provides the summary content as conditional content it must be input device independent.

The summary DOM attribute must reflect the summary content attribute.

Summary Example
<table summary="This table lists the 32 most significant floods of the 20th Century grouped into 6 types of floods: Regional, flash, ice-jam, storm-surge, dam-failure, and mudflow. The majority of the floods (20) are listed as Regional floods. There are between one and four floods in each of the other 5 categories."> 
(Source: Significant Floods of the 20th Century)

Impact

Positive Effects

While the above examples from the specification are to be considered conformant HTML5 there are genuine accessibility issues with them. The above examples for attaching longer descriptions to tables also may illustrate why there is a genuine need for @summary to be reinstated, which will help to make some of the examples accessible to existing AT, as well providing a degree of backwards compatibility that is a legitimate use of HTML 5.

Other positive aspects of retaining @summary would also be:

Authors have an established way of describing tables to non-visual users, without having to learn any new markup or development technique.

Authors who are trying to create accessible content will not get validator warnings. These warnings can make a developer hesitant to use a feature of HTML 5, even if its status is technically ‘obsolete but conforming’ – and still a valid part of creating accessible web content.

HTML and WCAG will not be giving contradictory advice.

@Summary is well supported by many User Agents.

The use of @Summary is an established part of development practice, while it’s use in the wild is small – the audience it serves (blind and vision impaired users) are served well by it.

Negative Effects

None.

Rebuttals

The following are my responses to the “Working Group Decision on ISSUE-32 table-summary” [7]

Hidden Meta Data

1) 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;

Response: @summary is by design ‘hidden’ from sighted people, but as the current spec has examples of where more verbose descriptors can be used to explain table structure and other relationships this is less of an issue as the author has the choice of deciding which authoring method suits their content. Is ARIA still not hidden relationship data? Does this mean that ARIA isn’t a universally designed or accessible solution. No, of course not. Also, alternate text can also be considered hidden but many authors are familiar with how to use it. It was observed that "Browser vendors are free to provide the information of the summary attribute in a way that benefits other users than those with AT" – this is true.

2) Risk that AT vendors will not improve the user experience; risk that DOM and accessibility APIs, will not be adopted

Response: This doesn’t make sense. AT vendors are constantly trying to improve the user experience, and take advantage of developing/expanding APIs and the enhanced user functionality this can bring. Without this kind of forward motion the web would be static.

Objections on Syntax

1) “Summary as an attribute is insufficient because it does not support structured content, such as for bi-lingual tables, as well as indicating to the user that the table uses structured markup and a guide to that structured markup.”

Response: Yes, this is an interesting observation. @summary is limited in that it cannot support structured content. Other elements that can refer to a URI may be preferable but this has to be weighted against existing UA support vs, ‘Blue Sky’ thinking. By all means I support developing methods of being able to support semantically rich structures but until this is the case – the retention of @summary as a full citizen of HTML 5 is desirable for backwards compatibility – as well as maintaining current authoring practices.

Another argument is that “[..] either would be "encouraging a redundant feature". The assertion is that aria-describedby "solves the same use cases, but does it in a better way." aria-describedby(indeed ARIA in toto) is an excellent toolkit to help developers to create accessible Web Applications. It has helped to bridge the ‘semantic divide’ while HTML 5 was in a rapid state of flux. Currently aria-describedbyand @summary do not have to be mutually exclusive solutions. In fact, maintaining @summary as a full member of HTML 5 (not as an obsolete attribute) would enhance the developers toolkit giving greater scope for authors to build applications that suit their target audience due to the excellent support @summary has in screen reading technology.

There are no examples of accessible tables in the HTML 5 specification that currently use ARIA and that can therefore be considered to be more accessible as a result of the use of ARIA markup. It is not sufficient to suggest that the use of ARIA elements/attributes are sufficient or normative and then not provide examples of how to do this. There is also a bug for this issue [Bug 13137]. [8]

As this CP indicates, the valid use of @summary and also the ability to use aria-describedby would mean that authors would have the choice of when they wish to define a programmatic relationship between a table element and an identifier or to indeed have a ‘hidden’ descriptor for users of Assistive Technology.

Objections on the basis of Need

Response: Many of the comments from the survey quoted in the WG decision are spurious at best. Lest we forget we are discussing an attribute designed to make content perceivable to people without sight. To intimate that the the net result was “summary="" has been amply demonstrated (one might even say _proved_) to not help improve accessibility in concrete ways.” Is very misleading. This is as loaded as saying (note this following comments is not includeded in the WG descision policy but is merely illustrative) ‘@summary is saving the web”. Neither positions are tenable nor reasonable. What I attempt to do here is provide a balanced view (in as much as this can be done when assessing extremes). However, in adopting the maxim that the truth occupies the median - comments like the previous one which was followed with “ encouraging authors from spending time on something other than improving accessibility *even after we are lucky enough to have found an author who cares about accessibility*. This is a net harm to the accessibility of the Web.” – are not enlightened and only obfuscate the issue. The accessibility of the web is not based on luck but on design, the mark up language should support this need for the creation of accessible content and often this is done in small ways, and not realised in broad strokes but in accruing details that enhance the greater picture.

Also found the in the "RISKS" section of one of the Change Proposals:

“There may be cases where there is some tabular data of a nature
complicated enough to warrant a table explanation for screen reader users (and presumably for other users also), but for which the author will refuse to include visible explanatory text yet is amenable to including hidden explanatory text. It seems highly unlikely that such a case exists, and indeed no examples of such a case have ever been put forward, but if such a case exists then there could be an
argument for leaving the summary="" attribute.”

A simple use case is where an author wishes to describe a tabular structure to a blind user. They may not wish to describe the tabular structure to the sighted user as the level of complexity may not be so great as to warrant it, however, it may be so complex as to require a hidden overview for those who cannot see. This is a reasonable use case to me.

Refering to the "Make the summary attribute fully conforming and allow visual UAs to optionally expose it" Change Proposal, the WG decision states that “we do see a list of use cases. We also have a list of sites that make use of a summary (in the form of the current attribute for this purpose). These use cases are not specifically addressed by any objection or counter proposal.”

Regarding a “study from a few years ago that indicates that the summary attribute is often misused” there was “No claim was made as to whether such a finding would apply to a separate summary element or the usage of an aria-describedby attribute.” This is an interesting issue as only time will tell. What we can state with some degree of confidence is however, the advantage of having a verbose descriptor as a part of the mark up language, and while it is difficult to predict future use the current level of User Agent support and relative ease of authoring does logically lean towards the ability to use these functions over being preferable to not having them at all. All markup has the potential for misuse, and if every infringement was to be be looked at in the cold light of day – all markup may be banned in the light of its application in the wild. How are we to measure the degree of severity of these infringements? Shall we penalise certain user groups because someone, somewhere used a brick as a weapon and not to build a house? Do we stop building? No, semantic legislation is only a part of the picture – we do not stop building stairs for fear that someone may fall down them.

Objections to 'Drop the summary="" attribute'

In this section the verbiage “This presumes that the summary attribute is the most appropriate way to express this information.” appears 5 times in response to the assertions that:

1) Authors who are trying to optimize for accessibility will not get validator warnings for doing so.
2) (@summary) Provides users of screen readers an equal opportunity to hear concise table summary information for a complex table that is visually apparent to sighted users.
3) Provides authors a mechanism for providing non-visual users summary information in a non-visual way.
4) summary is an essential tool for non-visual and limited visual access to data contained in TABLE
5) Obsolescing summary breaks the web for numerous sites doing the right thing.

At least two of these assertions #2 and #3 are correct and the response seems inappropriate as it doesn’t factor how @summary works, or indeed that it even does at all. Working examples of @summary are very easy to author (a text string is added to the attribute embedded within a table element, the HTML page is loaded and with a screen reader when pressing the key ‘T’ (using JAWS for example) the @summary text will be announced on focus after a caption if there is one present. Very simple and effective. Whether it is “most appropriate” is neither here nor there – in fact this WG response is difficult to parse as a more binary “does it work or does it not” approach to assessing the usefulness of the @summary would to be more fitting. The answer being “Yes, it does”.

Examples of @summary in the wild

@summary examples in the wild as of July 2011

Extending @summary?

As an addendum, another possibility is to extend the purpose of @summary. Whereas it is currently meant to just described the relationship between tabular data in a complex table, it could be extended to providing a more verbose prose overview of a tables purpose (as either a terse or more verbose descriptor). It would still have the same architecture, would not need any new implementation and it still just parsed as plain text but its scope would be enhanced which would be good for table accessibility.