Re: summarization information delivery options: attribute or element

Laura Carlson, Fri, 26 Feb 2010 07:09:06 -0600:
> Hi Leif,
> 
>> I am willing to write a change proposal for this, if I perceive that
>> there is any interest for the AT <caption> solution.
> 
> To me a second caption seems like it would be confusing for authors
> but others may disagree.

Thanks for feedback. Unless you tell what kind of confusion you have in 
mind, then I don't know how to react.

On on hand: the thing that @summary is confusing for authors is perhaps 
something that even this group could agree about. On the other hand: 
You support a specific <summary> element, directly as child of <table>. 
How different is that from a "second" accessibility <caption>? 

I will be clear about where <summary> could be confusing for authors: 
The only place where <summary> would be clear to authors about its 
purpose would be in its direct link to @summary. Thus if @summary is 
confusing to authors, the so could <summary> be. 

Discussion has also shown, IMHO, that it is difficult to narrow down 
the exact purpose of @summary. Gez has offered some good insights. But 
in practise, it is difficult for authors to pinpoint what a structure 
description is, compared to any other description.

> Matt said on the survey that the details proposal was overly
> complicated for authors. It required additional effort on the part of
> authoring tools and AT, and reeducation on the part of authors. He
> talked about not resigning ourselves to contortion at this phase of
> the development of the spec. I think that is good advice.

I don't feel certain that <summary> also isn't hit by his advice. The 
essence of my idea is: 

	a) allow more than one <caption>
	b) somehow specify the target group for each <caption>

Which to me seems rather simple. Some details needs to be worked out 
... So perhaps I _will_ offer that change proposal ... ;-)
-- 
leif h silli

Received on Friday, 26 February 2010 15:16:34 UTC