RE: PF Response: @Summary

Jim Jewett wrote:
> 
> But these assumption doesn't imply that @summary is the best (or even
> an effective) way of actually providing accessibility. 

Fair, but they do re-enforce the need - if there is a better way forward
lets go, but at the same time @summary (warts and all) is the best we've
got today: it's been around for a decade, it has browser support and
expert authors have a basic understanding of what it is and what it should
be doing.  Could it be better? Of course, but it's better than nothing at
all.

> If
> human-generated summaries are in practice not effective, then there is
> no reason to make it conforming for newly authored pages.  Let the
> people who have mandates (or strong consciences) spend their time
> writing better alt text, and better captions, and better table header
> cells.

None of those others provide what summary provides.  If summary is to be
obsoleted, then deliver on the specific need that it was trying to
address, rather than suggest that other elements or attributes can somehow
fill the void: there is zero evidence that authors will groc that either
and we are left with a void that is currently being filled with the
(imperfect) summary attribute.  Making summary non-conformant does not
address the real problem that is being put forth about current @summary
usage (bogus or bad data), it simply removes an existent if maligned
solution.

> 
> *If* summaries can be done reasonably by automated means, then it
> *also* makes sense to specify that a conforming User Agent will do so,
> and provide this information to the assistive technology.  I do not
> have the expertise or experience to judge how useful automated
> summaries are.  

William (Love) summed it up very well earlier - the intent is to describe
what visual users grasp upon glancing at the table.  It is descriptive of
structure with no editorial input, unlike attributes such as @alt that
rely on context.  Currently AT (screen readers) must process tables row by
row, cell by cell until the non-sighted user can build a mental image of
the table's overall structure: summary is supposed to deliver on that
structural overview, speeding page processing, and reducing cognitive load
on non-sighted users. If a better means to achieve this can be produced
then great, lets suggest authors do that instead as a best practice: again
however it does not flow from this that summary should then be made
non-conforming. (It's sort of like saying that now that most autos have an
automatic transmission that we should make manual transmissions illegal) 

> 
> I don't personally care if these questions get answered formally by a
> working group or informally by a single expert -- but I would like
> answers, and I haven't understood the ones offered so far.

Did these help?

JF

Received on Wednesday, 8 July 2009 16:53:47 UTC