W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2009

towards a shared understanding of @summary (was Re: FW: CHANGE PROPOSAL: Table Summary)

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Wed, 2 Dec 2009 23:14:54 +0000
To: Ian Hickson <ian@hixie.ch>, Cynthia Shelly <cyns@microsoft.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-Id: <20091202231053.M97508@hicom.net>
aloha, hixie -- perhaps the following will be of assistance in 
understanding not only the importance of @summary, but the intended,
and necessary use of @summary for those who cannot process a TABLE
(visually and/or cognitively)

1. think of CAPTION as a terse-descriptor for the TABLE

2. think of @summary as a long descriptor for the TABLE; 

@summary provides the same eureka moment that most users unconsciously 
receive through their ability to both visually process the information 
contained in a TABLE and to cognitively associate disparate items of 
information with their respective headers, sub-headers, background 
colors (so that a user could use an assistive technology's ability to 
change, for example, voice characteristics when the background color 
changes from one named color to another), etc.

therefore, there is no inherent need for the user who can perform both 
tasks by herself to have a summary presented, but there is (a) a need 
for the TABLE's structure and organization to be communicated to those 
who are parsing the TABLE non-visually, or through a VERY small 
point-of-regard and (b) no reason why a user agent, an authoring tool,
or any other program cannot provide a means to expose the content of 
@summary at a user's request -- whatever form that request takes, but 
there is NO usability need to provide ALL users with a summary which is 
intended to provide contextual and orientational information about the 
data contained in the TABLE, which the overwhelming majority of users 
will provide for themselves simply through the act of perceiving and 
processing the TABLE...

gregory.
----------------------------------------------------------------
CONSERVATIVE, n.  A statesman who is enamored of existing evils,
as distinguished from the Liberal, who wishes to replace them 
with others.         -- Ambrose Bierce, _The Devil's Dictionary_
----------------------------------------------------------------
             Gregory J. Rosmaita, oedipus@hicom.net
  Camera Obscura: http://www.hicom.net/~oedipus/index.html
----------------------------------------------------------------

---------- Original Message -----------
From: Ian Hickson <ian@hixie.ch>
To: Cynthia Shelly <cyns@microsoft.com>
Cc: HTML Accessibility Task Force <%%WORD123%y@w3.org>
Sent: Tue, 1 Dec 2009 20:40:14  0000 (UTC)
Subject: Re: FW: CHANGE PROPOSAL:  Table Summary

> On Tue, 1 Dec 2009, Cynthia Shelly wrote:
> >
> > Can we please put this on the agenda for 12/10?  I have a prior 
> > engagement this week, so I won't be able to discuss it on 12/3.
> >
> > 
http://www.w3.org/WAI/PF/HTML/wiki/Summary_Change_Proposal_Nov_18,_2009
> 
> I'm a little uncomfortable with this change proposal.
> 
> Specifically, I feel two of the requests -- adding summary="" 
> and orientation="" -- are actually likely to cause harm to 
> accessibility overall rather than help it.
> 
> Re summary="": I think it would be better to encourage authors 
> to always provide visible text explaining tables, since this 
> would would be more likely to be correct, and would benefit more 
> users. We've seen that when accessibility information is not 
> visible to authors by default, they tend to screw it up, so 
> having help information only visible to screen readers is 
> unlikely to help accessibility; and we've seen that for the few 
> authors who do provide helpful summary="" text tend to put 
> values in that attribute that would be useful to more than just 
> users of accessibility tools, causing other users to miss out on 
> potentially useful information.
> 
> Re orientation="": It seems dangerous to have features that are 
> so media-specific, since again, authors are unlikely to use it 
> correctly. It seems better for user agents to use the 
> information that can be derived from the table model to 
> determine whether the table is row-major or column-major. If we 
> keep this in the proposal, we should at least include a few 
> examples of tables where the UA would be unable to accurately 
> determien the right reading direction, especially giving 
> examples of orientaton=vertical.
> 
> Since I will be unable to attend the call on 12/10, could I 
> request that we discuss this by e-mail instead of on the teleconference?
> 
> Cheers,
> -- 
> Ian Hickson               U 1047E                )\._.,--....,
> '``.    fL http://ln.hixie.ch/       U 263A                /,  
>  _.. \   _\  ;`._ ,. Things that are impossible just take 
> longer.   `._.-(,_..'--(,_..'`-.;.'
------- End of Original Message -------
Received on Wednesday, 2 December 2009 23:15:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:41:57 GMT