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

Re: Draft of @summary text for HTML 5 poll

From: Shelley Powers <shelley.just@gmail.com>
Date: Thu, 23 Jul 2009 18:17:21 -0500
Message-ID: <643cc0270907231617k72c35b46jadeec224f8029c41@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: HTML WG <public-html@w3.org>
On Thu, Jul 23, 2009 at 12:10 PM, Sam Ruby<rubys@intertwingly.net> wrote:
> 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

My recommended text for the roll call/vote is the following:

Replace the examples listed in Section 4.9.2 with a table that is more
demonstrative of a complex table. (One was suggested that was created
by Gez Lemon I believe, and should be included in the vote, but I
can't find the email with the example.)

Update the examples to reflect the new table. (TBD)

Replace the line that reads:

"If a table element has a summary attribute, the user agent may report
the contents of that attribute to the user."

With a new example, listed in parity with other examples, that begins with:

Use the summary attribute on the table element:

(Example TBD)

Yes ( )
No   ( )
Abstain ( )

If someone can provide that email with the table example, I'd flesh
this out into a spec ready snapshot, and include a related document
showing the text embedded into a copy of the HTML 5 spec. Just to
ensure people could see exactly how the change would look. But I
thought I would put out a suggestion, first, before doing the work.

Received on Thursday, 23 July 2009 23:18:01 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:48 UTC