Re: PF Response: @Summary

On Tue, Jul 7, 2009 at 5:08 PM, Janina Sajka<janina@rednote.net> wrote:
> Jim Jewett writes:


>> I think most people agree that the structural
>> information shouldn't be in the summary

[I meant "caption", and endorse Janina Sajka's correction; leaving
"summary" was a typo left by my edits],

>> but may be useful to some people.


>> The questions are:

>> (1)  Can the browser determine this structural information automatically?

>> (2)  Can the browser do it well enough that
>> summaries should always be automated, so as to
>> benefit from standardization?

>> I'm not sure exactly what structural information is needed, but if
>> some *is* needed here, then it looks like an automated (User Agent)
>> process could often do better than even an expert (Author) does in
>> practice -- and so maybe the UA guidelines are what should be
>> specified.

> PF responded on these questions formally. We would appreciate the
> basic human courtessy of acknowledgment.  If you don't like what we said, please
> speak to that. But kindly don't simply ignore us.

> http://www.w3.org/mid/20090604000217.GA2789@sonata.rednote.net

I do not speak for anyone but myself; I read the note at the time, and
have re-read it now.

I don't find any information there about precisely which structural
information should be included, and which should be left out.  I (and
others) have tried to reverse-engineer that based on example "good"
summaries, but I am not confident in the results.

I also don't find any information there on whether or not it would be
possible for browsers to determine the structural information on their
own (and then expose it to AT).  I can't answer this question for
myself without knowing what makes a good summary, what makes an
adequate summary, and how common either is.

------

I defer to your expertise and assume that you are correct that summary
would need to be reinvented if it didn't exist.

I defer to your expertise and assume that you are correct that
@summary is often used to meet a section 508 mandate.

I agree that the specfication needs to define how a User Agent will
process the summary attribute.

But these assumption doesn't imply that @summary is the best (or even
an effective) way of actually providing accessibility.  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.

*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.   Nor can I properly judge how bad the current
situation is, since I don't know which bad summaries are automatically
ignored by the AT.

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.

-jJ

Received on Tuesday, 7 July 2009 22:37:02 UTC