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.