RE: Summary of Thursday's IRC conversation about @summary

Jonas Sicking wrote
> 
> Indeed. When something out of HTML4 hasn't accumulated use over the
> past decade that HTML4 has been deployed, I think not looking for a
> "why" and "do we need to change something" is to close your eyes to
> reality.

And indeed, that question has been asked.  However, is it the failure of
the attribute, or the apathy and lack of education inside the 'industry'
that exists today (earlier in this thread others have had to explain the
difference between a summary and caption)?  If you cannot grok the
difference between the two, is it a failure of the attributes/elements or
a failure of developer comprehension?  At what point must we stop holding
the hands of professionals and demand that they understand what it is they
are dealing with and working with?

[re-quoting Laura Carlson]

A caption is provided visually. Like it says in the Use Case section of
the "Mechanism to Summarize a Table" Wiki page for the majority of sighted
users a summary is not needed. For instance:

<table summary="Rows contain destinations, traveling dates, and grand
total. Columns contain expense category and total. The first column
contains merged table cells.">
<!-- Remainder of table -->

A sighted person can see how the rows and columns are laid out and where
the cells merge by a quick scan or glance. They typically wouldn't need an
explanation. Providing it visually would be extra verbiage that most
authors/designers would be reluctant to include visually on a page because
of redundancy.

A programmatically-determined summary mechanism serves a very specific and
most critical use for blind and non-visual users. It provides an
affordance equivalent to the visual user scanning a table for spatial
structure, orientation, and relevance. A summary mechanism provides a
reasonable accommodation. It enables a person with a visual disability to
have an equal opportunity.

[end]

> 
> I do hope that the people advocating @summary has looked into these
> questions and come to the conclusion that @summary can not be
> improved.

Those that advocate it's continued inclusion have not reached the same
conclusion as you apparently have - we don't think @summary is broken,
simply under-used and likely mis-understood. The specific functionality it
seeks to address it delivers in spades: as the PF WG noted, "Summary
serves a need, and serves it well. It is familiar to users. It is
supported in browsers. It is properly utilized on many web sites which
strive to be accessible." (and again: "The wider web is not an example of
good practice.")  However, education can be improved upon significantly,
and in this we are all in agreement.  For someone who earlier said you had
no opinion one way or the other, you are coming across as being fairly
dogmatic in your insistence that @summary is broken and needs to be
discarded...

> However they have unfortunately not provided any information
> about which alternatives were looked into and why @summary was deemed
> better.

Herein lies the other half of the problem - nothing has been adequately
proposed that replaces the specific functionality that @summary currently
delivers.  Suggesting to merge caption and summary into one 'global'
thingy is like suggesting that bikinis and billy-boots can be grouped as
"beach-wear"... (I mean, you can, but...)

Thus asking accessibility advocates to discard something that exists today
without replacing it with something of equal or better value is to many a
move backwards.

JF

Received on Friday, 5 June 2009 23:59:06 UTC