This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13129 - Accessible Tables examples in HTML 5 spec
Summary: Accessible Tables examples in HTML 5 spec
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P3 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11y_table_summary
Depends on:
Blocks:
 
Reported: 2011-07-04 10:11 UTC by Joshue O Connor
Modified: 2014-04-16 17:16 UTC (History)
8 users (show)

See Also:


Attachments

Description Joshue O Connor 2011-07-04 10:11:52 UTC
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
Comment 1 Michael[tm] Smith 2011-08-04 05:02:04 UTC
mass-moved component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-12-01 00:48:29 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The argument here basically boils down to "the user might skip the text before the table by jumping straight to the table, and thus not understand what the table is about". Well yes. They might also skip past a paragraph and read the next one, and thus not know what the paragraph is about. At the end of the day, readers have to read the page to understand what it says, whether it's with a screen reader, reading directly from a screen, or any other mode. Authors aren't going to be adding markup to handle readers who aren't reading. What if the reader were to skip past the summary?
Comment 3 Joshue O Connor 2011-12-01 09:22:29 UTC
(In reply to comment #2)
Ian said:
> Rationale: The argument here basically boils down to "the user might skip the
> text before the table by jumping straight to the table, and thus not understand
> what the table is about". Well yes. They might also skip past a paragraph and
> read the next one, and thus not know what the paragraph is about. At the end of
> the day, readers have to read the page to understand what it says, whether it's
> with a screen reader, reading directly from a screen, or any other mode.

?? I don't understand this comment,  it seems like a non-sequitor. Either I wasn't clear or you don't understand the point I'm trying to make. For a start a screen reader isn't just a 'reader'. Blind people don't just sit there passively while every page is read in toto! It is primarily a 'navigation' and then a 'reading' device. Your comment indicates that you may not understand that. Apologies for being so frank.

> Authors aren't going to be adding markup to handle readers who aren't reading.
> What if the reader were to skip past the summary?

I'm sorry but again I don't really understand this comment. The point of a markup language is to create a 'programatic association' between elements and labels, and various data. Visually, you or I as sighted people can very quickly scan a document and make these connections, a non sighted person cannot. Therefore the AT, by being able to understand explicit programatic associations made within the markup can inform the user of various relationships and help them to understand the content of a web document. They cannot make the split second associations that a sighted person can from viewing a page. Yes, a screen reader user can skip over content and *may* miss certain things but thats not the point. If there aren't explicit programatic associations such as <captions> for tables, @summary info, @alt for images or whatever, they *will* miss these relationships and their view or reading (as you say) of the content will be incomplete.

I hope that you would agree this isn't desirable, and that the HTML5 markup language should endeavor to support people with disabilities using Assistive Technologies. Some of the examples (as for the reasons outlined above) have a poor level of accessibility, right now. Tomorrow that may improve. The simple point I'm trying to make is that we have existing mechanisms that do 'today' what these examples hope to do tomorrow. I really don't see the problem with supporting existing methods that while may not be perfect - work. In time they can be superseded by better methods. Indeed this was once a mantra of this working group.
Comment 4 Mark Sadecki 2014-04-16 17:16:58 UTC
Joshue agreed to close this bug.  However, the examples in 4.9.1.1 for describing tables still need to be improved.  We will open a new bug against 5.1.