W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Taking another round at @summary

From: Shelley Powers <shelley.just@gmail.com>
Date: Wed, 6 Jan 2010 14:02:02 -0600
Message-ID: <643cc0271001061202j70aa7cf1t30d69eec42651e12@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: John Foliot <jfoliot@stanford.edu>, Jonas Sicking <jonas@sicking.cc>, Denis Boudreau <dboudreau@webconforme.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, HTML WG Public List <public-html@w3.org>
On Wed, Jan 6, 2010 at 12:45 PM, David Singer <singer@apple.com> wrote:
>
> On Jan 5, 2010, at 17:06 , John Foliot wrote:
>>
>> How does the rarity of @summary's usage today, or instances when the
>> author has done things wrong, negate @summary's usefulness?  All that your
>> data proves is that currently this useful attribute is not being used to
>> its full advantage - nothing more, nothing less.
>>
>
>
>
> I think that this has been discussed as a general point related to summary, alt, and a number of other designs.  I'll try to re-create the argument very briefly, to avoid repetition.
>
> If a facility is so rarely used that it's unlikely that, if looked for, it will be found, and/or when used it is used incorrectly or unhelpfully, so that on the rare occasions it is found, it's useless, then those needing it will give up looking for it, and UAs will give it relying on it as a way to help users needing accessibility provisions.  At that point, it's getting useless.
>
> I don't *know* that this has happened with summary, though some have argued that it has.  Note that experiments that show that when it is used correctly, it's helpful, do not negate the rarity/pollution problems above.
>

The data is based on queries, and if I remember most of these, the
summary value was an empty string, and was associated with HTML tables
used for layouts. So one can say there's a direct correlation between
incorrect use of summary and incorrect use of HTML tables. Or, that
the use of summary was correct, because the table was meaningless from
a data perspective. There's no better way to describe a meaningless
html table, then with an empty string.

For all the discussion about the data, there are issues that have
never been addressed by those who tout the data.

For instance, there's no way to differentiate whether the incorrect
uses of summary were because the data wasn't visible to sighted people
(which has been the argument), or because the HTML 4 specification
didn't do a good job on describing summary, or providing decent
examples. Accessibility folks have been evangelizing summary, and
other accessible approaches, but all of this is still fairly new, in
the great scheme of things. It's really only been 5 years or so, or
less, that people have  _really_ started paying attention to
accessibility. (Folks correct me if I'm wrong on this one.)

With this in mind, it's extremely difficult to differentiate in the
data that's been touted as reason for the change, which data is from
recent web pages, and which data is from old web pages -- and anything
from old web pages is suspect, because most likely most of the markup
in the page is incorrect.

Since we can't differentiate along two levels--old web pages and new,
incorrect use of summary because of the lack of visibility of the
attribute, compared to bad documentation and lack of examples--the
feasible approach, the scientific approach, would be to leave summary
supported in HTML5, and provide better examples and description (with
help from the accessibility folks). Then, at some later time, when
HTML5 has broader support, we'll be able to get a much clearer picture
of the usability of summary, in conjunction with other table
documentation techniques.

At that time, then we'll have good, clean data, and can make the
appropriate decision.

This, is the truly scientific approach.

> David Singer
> Multimedia and Software Standards, Apple Inc.
>

Shelley
Received on Wednesday, 6 January 2010 20:02:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC