Re: How did the summary attribute become part of HTML 4.0?

As a blind web user and evaluator of technologies, I recall that even  
as far back as 199, we had some capability to choose the chunks of the  
text on the screen we wanted to read.  Think of the @summary as a road  
map to the table if you will and nt a means to skip it.  This was its  
original intent when I was around back then and we foresaw many  
complex data tables handled in such a way as to have @summary make  
them more comprehensible, not to decide whether or not to skip them.

On Aug 8, 2009, at 12:51 AM, Murray Maloney wrote:

At 09:39 PM 8/7/2009 -0500, Murray Maloney wrote:
> At 02:15 AM 8/8/2009 +0200, Leif Halvard Silli wrote:
>> [...]
>> So, might it be that table@summary was meant to be presented to AT  
>> users /before/ the entire table had been rendered?  If so, then  
>> this might also explain why some @summary texts perhaps are more  
>> wordy than we today consider kosher: In such a scenario it would  
>> perhaps not matter if the summary repeated bits of what the user  
>> later would read inside a caption. (For instance, perhaps the user  
>> would use the @summary info to simply skip reading/loading the  
>> table?)
> Exactly. The reader gets to the table and pauses.
> My understanding at the time was the user could proceed apace or
> ask for the table title and summary, then possibly look ahead to the
> caption and legend, before deciding whether to simply skip over the
> table or proceed. Developers at the time felt that having @summary on
> <TABLE allowed for a breakpoint to be set, facilitating skipping
> over the table and saving cycles in the process.

I just realized that I left out an important part... some of the  
people involved at the time
had experience with Braille publishing and with Braille readers, and  
others had been
involved with ICADD. They were unanimous in expressing the need for  
pausing at a table
to survey the terrain before proceeding, lest they enter a rat's nest  
of incomprehensible data.
Breakpoint set, they could examine the table element for in-attribute  
information and related
links to long descriptions, and present available information to the  
user to help them make a
decision about how to proceed. Of course, ARIA attributes will provide  
a better solution in time.

Received on Saturday, 8 August 2009 09:29:55 UTC