Fwd: Draft of @summary text for HTML 5 poll

I've received permission to forward this to the Working Group for wider 
discussion and suggestions before we proceed to a straw poll.

I'd like to request that people focus on making concrete suggestions for 
alternate wordings of the poll itself.  I'd specifically like to avoid 
open ended-suggestions on alternative ways to approach the poll; I'd 
furthermore like to ask that people hold off on expressing opinions as 
to which alternative they feel is better and why until the actual poll 
itself.

- Sam Ruby

-------- Original Message --------
Subject: Draft of @summary text for HTML 5 poll
Date: Fri, 17 Jul 2009 17:14:26 +0100
From: Joshue O Connor <joshue.oconnor@cfit.ie>
Reply-To: joshue.oconnor@cfit.ie
To: Sam Ruby <rubys@intertwingly.net>
CC: Ian Hickson <ian@hixie.ch>, Chris Wilson 
<Chris.Wilson@microsoft.com>,        Dan Connolly <connolly@w3.org>, 
"Michael(tm) Smith" <mike@w3.org>,        Janina Sajka 
<janina@rednote.net>, Michael Cooper <cooper@w3.org>

Hi all,

There seems to be some confusion about exactly what we are voting on in
the upcoming poll on @summary [Action 128] , just to be clear.

PF will continue support for the tested and implemented summary
attribute as a prerequisite for improving accessibility of tables. We
support the goals to make tables accessible to all, and would like to
participate in that. However, we think this work should be done in
addition to, not instead of, providing support for the legacy summary
attribute. Therefore the current situation regarding the summary
attribute and this poll is not about engineering a new solution but
about the
status of the legacy summary attribute.

Some of the possible questions in the survey could be worded around:

* Summary is the best way to make tables accessible, even though it is
specific to people with disabilities
* Continued support for summary is needed as a bridging mechanism while
other methods to make tables accessible are developed and proven
* Summary is not effective and should be immediately replaced with other
mechanisms to make tables accessible
* A well constructed table with caption and headers would never need any
kind of summarizing mechanism, user agent heuristics can generate a good
overview

The survey could also be  broken into several questions, with several
straw poll options on each. Ian suggested there could also be scope for
people to add their comments
and ideas.

I am fine with whatever is the consensus after this text has been
submitted to the wider group.
I don't wish to design and build the poll but I hope that my initial
draft is enough to get this work moving.

Cheers

Josh

@summary draft text for HTML poll.

Overview

HTML 5 needs a mechanism to provide a data table with a summary. An
explicitly associated, programmatic feature is required in order to
provide an overview of tabular data or a brief explanation of how to
navigate a data table for people who use Assistive Technology (AT).

This is because an AT user needs to easily form a mental image of
a tables contents in order to better understand its structure, or
semantic relationships. The mechanism needs to be explicitly associated
with the table or it becomes more difficult for AT to make that
association. A summary mechanism may seem irrelevant or redundant to
those with good eyesight because they have access to content
relationships at a glance

Currently the @summary is considered conforming but obsolete, the HTML 5
specification wording is that "Authors should not specify the summary
attribute on table elements.  The caption element or one of the other
techniques described in the table section should be used instead." [1]

The specification does not explicitly mention what the @summary
attribute is for, or provide examples of how to use it correctly.

To find out how to use @summary authors must refer to the HTML 4.01
specification. [2]

In the HTML 4.01 specification authors are advised that:
"“This attribute provides a summary of the table's purpose and structure
for user agents
rendering to non-visual media such as speech and Braille."

In short, @summary should be used as a mechanism to provide an overview
of the structure of a data table. It can be used on both simple and
complex tables. On complex tables it can be used to give an overview of
the structure, more simple tables may not need this description however
@summary can then be used to describe the purpose of the table.

This attribute was designed primarily to support the needs of blind and
visually impaired users of AT. It is supported well by these user agents
such as JAWS, Window Eyes, NVDA etc. Similar to the <caption> element,
if present on a data table the contents of the @summary are announced
out as soon as the user gives a table focus. The user can choose to
listen to this output or quickly move on to another element.

@summary can therefore be used in conjunction with the <caption> element
to provide much needed descriptions of the table, its contents and
purpose thereby increasing the accessibility of the web and improving
the user experience for people with disabilities.

Protocols and Formats Working Group Input

Note the following consensus was reached by the Protocols and Formats
Working Group (PFWG) during its teleconference of Wednesday, 3 June
2009: [3]

The PFWG also formally requested that the table summary element be
restored in HTML 5 on August 6th 2008 and again in June 2009: [4] [5]

For more details on the @summary issue see the ESW wiki. [6]

Limitations of @summary

PFWG acknowledge that @summary has its limitations and that it is not
suitable as a long descriptor and therefore there needs to be another
mechanism such as ARIA describedby or some other suitable HTML 5
mechanism that can act as a semantically rich container.

This issue is similar to that discussed in "“Recommendations regarding
Long Text Alternatives" WAI-CG Task Force on Alternative Text. [7]

However: PFWG notes that:

*Summary currently serves a need, and serves it well. It is familiar to
users of AT. It is supported in many browsers.

*If it didn't exist, we'd need to invent it. Indeed, such alternative
approaches as have been proposed constitute a "reinvention" of @summary.

*We reject the argument that summary should be removed from the HTML
specification because it is not implemented on most web sites. We note
that accessibility is poorly supported on most web sites. The wider web
is not an example of good practice.

*We need summary for backward compatibility.

*We note that summary is often used as a technique for accessibility
support where governmental regulations require governmental web sites to
be accessible. An example is the U.S. Government's Social Security
Administration (SSA) pages as SSA conforms to its "Section 508."
mandate: [8] [9]


* If summary is removed, U.S. Government web sites, might find it more
difficult to conform to HTML 5. We further note that Section 508
regulations apply to U.S. state and local governments, and that similar
accessibility requirements are emerging in Canada, the U.K., the E.U.,
Australia, and elsewhere.

*Restoring summary in HTML 5 would not, in our understanding, negatively
impact HTML 5 in any way.

Use of @summary is also advised in the current Web Content Accessibility
Guidelines (WCAG 2.0) and its corresponding tests (H73 & Test 111).

WCAG 2: H73: Using the summary attribute of the table element to give an
overview of data tables. [10] [11]

References

[1]
http://www.whatwg.org/specs/web-apps/current-work/#conforming-but-obsolete-features

[2] http://www.w3.org/TR/html401/struct/tables.html#adef-summary

[3] http://www.w3.org/2009/06/03-pf-minutes.html

[4] http://lists.w3.org/Archives/Public/public-html/2008Aug/0213.html

[5] http://lists.w3.org/Archives/Public/www-archive/2009Jun/0026.html

[6] http://esw.w3.org/topic/HTML/SummaryForTABLE

[7] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

[8] http://www.usdoj.gov/crt/508/web.php

[9] http://www.access-board.gov/sec508/guide/1194.22.htm#(g)

[10] http://www.w3.org/TR/WCAG20-TECHS/H73.html

[11] http://www.w3.org/WAI/GL/WCAG20/tests/test111.html

Received on Thursday, 23 July 2009 17:11:19 UTC