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. Our preference is that @summary is retained as a fully conforming attribute. 


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. 

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 first couple of examples are fine, and can be considered to be accessible ( example as it is nested within the table, with <caption> in <details> element) as they are also nested within the table. 

Note that in the example, Table Caption, in a details element  the content of the <caption> including the <detail> 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 <caption> 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.[1] 

This 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>/<figcaption> may be missed by the screen reader user, as in the following example from the HTML 5 spec. 

Whereas many of the examples 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). 

The use of the <figure> element does not currently provide the same level of accessibility in current User Agents. 

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. 

<pre>
<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>
</pre>

The same issues arises with the next example Next to the table, in a figuress figcaption'. 

For example: 
<pre>
<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>
</pre>
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: This testing was done with new browsers and AT. The mark up examples in the spec would not work with older browsers and AT. 

Recommendation

While the above examples are to be considered conformant HTML5 there are accessibility issues with them. The above examples for attaching longer descriptions to tables also may illustrate why there is the need for @summary to be reinstated. The @summary attribute contents are read out by a screen reader as soon as the <table> element receives focus. The scope of what @summary is for may be changed in a suitable Change Proposal but its support in existing user agents, its ease of use and the fact it is announced as soon as the table element receives focus shows it would be unwise to maintain its onsolete but conforming status  especially when we consider that some of the above examples are not suitable nor particularly accessible to the latest in screen reading technology 

A screen reader user can often navigate HTML content via explicit elements allowing the user to navigate quickly so explicit programmatic determination such as the current use of @summary is very useful as existing UAs can easily use this data to give the user a quick overview within the context of the current element focus. 


Therefore the summary attribute should be reinstated as a full feature of HTML 5 or a more suitable summary mechanism defined in a CP. 


[1] http://www.w3.org/TR/2011/WD-html5-20110525/tabular-data.html#table-descriptions-techniques