W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

[Bug 13129] New: Accessible Tables examples in HTML 5 spec

From: <bugzilla@jessica.w3.org>
Date: Mon, 04 Jul 2011 10:11:54 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-13129-2486@http.www.w3.org/Bugs/Public/>

           Summary: Accessible Tables examples in HTML 5 spec
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: joshue.oconnor@cfit.ie
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,

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. 

 <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
    <th id="n"> Negative
    <th> Characteristic
    <th> Positive
    <td headers="n r1"> Sad
    <th id="r1"> Mood
    <td> Happy
    <td headers="n r2"> Failing
    <th id="r2"> Grade
    <td> Passing

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

For example: 
  <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
    <th id="n"> Negative
    <th> Characteristic
    <th> Positive
    <td headers="n r1"> Sad
    <th id="r1"> Mood
    <td> Happy
    <td headers="n r2"> Failing
    <th id="r2"> Grade
    <td> Passing
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. 


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. 


Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 4 July 2011 10:11:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:55 UTC