- From: David Poehlman <david.poehlman@handsontechnologeyes.com>
- Date: Sat, 8 Aug 2009 05:29:08 -0400
- To: Murray Maloney <murray@muzmo.com>
- Cc: Leif Halvard Silli <lhs@malform.no>, Steven Faulkner <faulkner.steve@gmail.com>, Henri Sivonen <hsivonen@iki.fi>, HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
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