Re: Table Summary Change Proposal

Laura Carlson, Tue, 2 Mar 2010 07:18:58 -0600:
> Hi Leif,
> 
> Thanks for putting this Change Proposal together and for your
> thoughtful responses on the other thread, Leif. I'll be giving them
> serious thought. Your proposal removes much of what is wrong with
> Cynthia’s.

Thanks. I at least hope it brings us a step forward. I am open to input 
(and cloning, for that matter). The proposal is much less specific 
w.r.t many of the things that you have in your proposal. But that is 
not so much because I disagree with your CP, but because I took it from 
another angle. 
 
> As the recent survey was split and the discussion on the other thread
> seems to be at a stalemate, it might help if the group came to
> consensus on a table summary's current and future functional
> requirements.  As mentioned previously [2], a survey on that might
> help. You have already answered these but if the group did it might
> help.

I did not answer the survey (did not pay attention/wasn't member of 
this TF for while). But I hope I provide some answers in my CP.
 
> * Is a summary's purpose to provide an overview of how data has been
> organized into a table or a brief explanation of complex data table as
> stated in WCAG2's H73 or is it to provide a long description as stated
> in HTML 4?

HTML4 and WCAG2 H73 agree that the purpose of @summary is to solve 
media related to side effects. The word "long" in HTML4 perhaps has 
caused some unlucky connotations ... But I would not exaggerate the 
differences. Though WCAG2 H73 can probably be said to have refined what 
@summary is for. It more precisely nails down *when* info should go 
into @summary. And *what* info should go into @summary.

Both H73 and HTML4 says that @summary should not duplicate <caption> - 
and in this, I think there is an opening both places, for placing the 
kind of info that H73 describes, directly in the <caption> instead: 
Don't place it into @summary if it is already in the <caption>. (But 
then, if both are placed in the same <caption>, a second problem 
appears: identification of table caption string versus identification 
of table summary string.)

Btw, neither HTML4 nore WCAG2 H73 whether speak for or against that the 
table summary and table caption is placed in a single <caption> instead 
of being separate in <caption> and @summary. And perhaps this is good. 
I mean, too much info can also be confusing - for users of screen 
media. 

I think, on one side: when we move over to talk about screen media 
users who are not able understand the table without some explanation of 
it present, then we have moved away from the specific media related 
side effects that @summary is meant to make up for. But on the other 
side: If the author *does* provide lots of explanation of the table 
inside the <caption>, then that in turn, may take away the 
need/justification for providing a specific 'table summary' for the 
non-visual media - simply because WCAG2 and HTML4 tell us to not 
duplicate the info of the table caption inside the the table summary 
container.

> * Text string, restricted inline content, inline content, or block
> level content?

It seems to me that the answer to this also relates to whether 
*<caption>* should allow block level content.

Another and more fundamental question you should have asked, I think, 
is: Can the 'table summary' be placed directly in the <caption>, 
together with the 'table caption', or not? And then: should it always 
be recommended to place both inside the <caption>? (Or does it pay more 
respect to BOTH screen media users AND non-visual media users, to not 
have a rule for this?)

> * Invisible, visible, or some combination (button) by default?
> 
> * Visibility settings via user agent or markup or CSS or JavaScript?

Yes, to 'Visibility settings via user agent or markup or CSS or 
JavaScript'. I'll just bring in another thing, though: How should user 
agents of the AT class react to CSS? Specifically generated content? If 
they reacted better to generated content, then even @summary could have 
been more accessible: It is possible to make the content of @summary 
visible via CSS. To bring up another test case I made:

http://målform.no/html5/summary+css


The problem is that VoiceOver, which doesn't read @summary, also 
doesn't read it when it has been made visible via CSS (generated 
content). If it _had_ read generated CSS content - or could be made to 
read such content, then @summary support could probably be provided via 
the well known ways for providing content that only screen readers see: 
element{position:absolute;left:-99999cm;}

> If the group agrees on the requirements in advance, writing a proposal
> would be much easier.

I agree. 

> [1] http://lists.w3.org/Archives/Public/public-html-a11y/2010Feb/0572.html

-- 
leif halvard silli

Received on Tuesday, 2 March 2010 14:43:32 UTC