Spec Review/Tables

Under review:

• Tabular data

Joshue O Connor

4.9 – Tablular Data

Issues and Concerns

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.

<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: 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 suitable summary mechanism defined in a CP.

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

Yeliz Yesilada

Yeliz was invited to provide feedback by Simon Harper of the UAWG because of his expertise in accessibility of tabular data. His email is yyeliz at metu dot edu dot tr

The specification says that the following is the content model for the table element: "In this order: optionally a caption element, followed by zero or more colgroup elements, followed optionally by a thead element, followed optionally by a tfoot element, followed by either zero or more tbody elements or one or more tr elements, followed optionally by a tfoot element (but there can only be one tfoot element child in total).". As can be seen from this specification having a caption element is *OPTIONAL*. That means one can author a table which does not have a caption. The caption element can be considered to provide a summary, a broad overview of the table (see Section 4.9.2). However, since it is an optional element that means some tables can be created without any summary or overview of the content. Furthermore, the summary attribute on table element is obsolete and should not be used by the authors. That means one can author a table without a caption and that table that will not include a summary. From an assistive technology (AT) perspective, that means the underlying code might not provide any kind of summary of the table. That means for example screen reader users will not have a broad overview/summary of the table. The best recommendation would be for them to reconsider the optionality aspect of captions (in this case they are considered to provide a broad overview) or re-introducing summary attributes.

Related to the topic above, the suggested use of the figCaption element is not currently supported by the assistive technologies, but with the future developments of assistive technologies figcaption can be very useful. Especially, the examples with the figure element and figcaption shows how the captioning can be used and interpreted by assistive technologies.

part of overall table summary discussion

In the techniques for describing the table (Section 4.9.1.1), the first example shows how a table can be described with a paragraph located outside a table tag <p></p><table>…</table>. However, this is not a good idea because the assistive technologies will not be able to automatically detect if the paragraph located outside the table element is meant to describe the following table. Therefore, the best recommendation would be for them to reconsider this example.

discuss

Bruce Bailey

I agree with Yeliz that adding @summary examples is a good idea. I can draft some if that would be helpful.

Below I describe my methodology.

I did not find any substantive accessibility related changes between the Working and Editors Draft.

To get up to speed on the most pressing background issues, I read Working Group Decision on ISSUE-31 / ISSUE-80 requirements survey and Working Group Decision on ISSUE-32 table-summary which in turn referenced HTML-A11Y Task Force Recommendation: ISSUE-32 Table-Summary.

Simon Harper

Content model

My main problem with Tables is the 'Content model: In this order: optionally a caption element, followed by zero or more colgroup elements, followed optionally by a thead element, followed optionally by a tfoot element, followed by either zero or more tbody elements or one or more tr elements, followed optionally by a tfoot element (but there can only be one tfoot element child in total).' in which a caption, column head, or the table foot elements are all optional. These provide the best way to describe a complex data structure and I am unsure as to why they are optional.

TF thinks there are valid use cases

Layout tables

If tables should not be used for layout (as stated) why are mechanisms provided to allow them to be used as layout, especially 'The use of the role attribute with the value presentation' seems to be the most pernicious as it implies layout usage is OK really.

We have a precarious balance with these features we want to maintain, backward compatibility and repair issues exist