- From: Murray Maloney <murray@muzmo.com>
- Date: Fri, 07 Aug 2009 23:51:32 -0500
- To: Leif Halvard Silli <lhs@malform.no>,
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, Henri Sivonen <hsivonen@iki.fi>,HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
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 03:51:12 UTC