Re: summary="" in HTML5 ISSUE-32

As this is an ongoing discussion and will be moved forward properly, I  
don't want to go over old ground but suffice it to say, all of these  
points have been previously aired and while there is a real desire and  
need for improvement, nothing yet seen has been shown to adaquately  
replace @summary and also, @summary can be utillized in most if not  
all of the instances described.

As I have stated before, it is necessary to take great care when  
determining when/whether something should be hidden especially when it  
brings added value to the content.  @summary if done well should not  
be hidden as its rendering benefits more than "nonvisual" users.   
Sooooooo many times, I have ben walking through content with someone  
and the topic of what is in the summary comes up to which they reply,  
I don't see that.  I have to read it to them because it is hidden.   
I'm getting off track though.  I am waiting and hoping for an outcome  
that either replaces or improves @summary but if replaced, it must be  
equal to or better than.

Thanks for listening.

On Feb 25, 2009, at 1:26 PM, Maciej Stachowiak wrote:


On Feb 25, 2009, at 9:23 AM, David Poehlman wrote:

> Maciej,
>
> This is something with which I agree but what I was wondering about  
> is something quite narrow in scope.  I take it for granted that folk  
> wouldn't be doing this work if they were not interested and am not  
> fluent in many languages but am aware that they are out there and  
> that others are fluent in languages both singly and multiply that I  
> am not.
>
> What actually mystifies me and I've been following every nuounce of  
> the conversation over a long span on several lists is that there has  
> not been shown to be anything satisfactorily demonstrated to replace  
> what can be and has been used as such an accessibility enhancing  
> attribute as @summary.

Many alternatives to summary have been proposed. At least the  
following techniques have been suggested as ways to provide additional  
information about tables:

1) Use the table caption.
2) Use a separate piece of explanatory text above or below the table.
3) Use the title attribute on the caption.
4) Use a details element inside the caption.
5) Use a separate piece of explanatory text above or below the table,  
using media-specific CSS rules to hide it from visual users.
6) Variants of 4 and 5 using ARIA to associate the information with  
the table.

You may not think that these have not been satisfactorily demonstrated  
to replace summary, but I think that is a debatable point, not a  
blindingly obvious truth.

There has also been discussion about whether different techniques  
might be appropriate to different kinds of additional information:

A) Descriptions of the table's data layout, making it easier to  
navigate the table.
B) Conclusions that summarize the data in the table, so one could skip  
the table entirely if not interested in the details.
C) Additional information not found in the table at all, but relating  
to its contents.
D) Indications that this table is a layout table.

I think there can be honest disagreement over whether summary is the  
best technique to convey some or all of these kinds of information.  
For example, it seems clear to me that (C) is information that should  
be presented to all users, even those not using assistive  
technologies; and cases could be made for (A) and (B) as well,  
depending on the context. (D) seems like information that would only  
be useful for non-visual rendering. Ian thinks we don't need any  
mechanism for (D) because layout tables are nonconforming. Some, for  
example Henri, strongly disagree and think we need to adapt to the de  
facto reality of layout tables.

Perhaps there are other kinds of information that might be conveyed in  
the summary attribute and that are useful for use of tables with  
assistive technologies.

It seems to me that we can have a lot of productive discussion about  
what kind of information needs to be conveyed, who might find it  
useful, and what markup best meets those goals.

> I'm not saying that ideas are not welcomed or discouraged but that  
> there are some hard facts that need to be considered if we are ever  
> going to move toward striking @summary from need.

I am all for consideration of hard facts.

Regards,
Maciej


>
>
>
> On Feb 25, 2009, at 12:02 PM, Maciej Stachowiak wrote:
>
>
> Hi David,
>
> On Feb 25, 2009, at 7:24 AM, David Poehlman wrote:
>
>> in that event, it can be ignored, however, one does wonder why the  
>> resistance to something so obviously benefitial is so *strong*.
>
> I think the disagreement is over whether summary is, on the whole,  
> beneficial, and whether other approaches might be more beneficial to  
> all users. Your framing of the disagreement assumes the answer, and  
> makes it sound like those who disagree with your technical position  
> hate accessibility. Even though it is phrased more courteously than  
> Robert's statement, I don't think it's helpful to discussion.
>
> I don't have a strong opinion one way or another on summary. But it  
> seems that discussion of accessibility features often gets very  
> emotional and heated. I think nearly all of us in this group want to  
> see a Web that is accessible to everyone. What we sometimes disagree  
> on are the best means to achieve these goals. So let's try to think  
> like this: "Person X has a different idea of how to best achieve  
> universal access, how can I persuade them to my point of view? Or do  
> they perhaps have a good point?" instead of like this: "Why is  
> person X against accessibility?" That's the way we try to discuss  
> other technical issues, even though often equally important goals  
> are at stake. And that gives us the best chance of coming up with  
> good solutions.
>
> Regards,
> Maciej
>
>>
>>
>> On Feb 25, 2009, at 9:20 AM, Sam Ruby wrote:
>>
>> Robert J Burns wrote:
>>> I say malicious since the continued repetition of the fallacious  
>>> arguments seem directed at ensuring such information is not made  
>>> available to visually and cognitively disabled users.
>>
>> The above statement is neither productive nor acceptable.
>>
>> - Sam Ruby
>>
>>
>> -- 
>> Jonnie Appleseed
>> with his
>> Hands-On Technolog(eye)s
>> reducing technology's disabilities
>> one byte at a time
>>
>
>
>
>
> -- 
> Jonnie Appleseed
> with his
> Hands-On Technolog(eye)s
> reducing technology's disabilities
> one byte at a time
>




-- 
Jonnie Appleseed
with his
Hands-On Technolog(eye)s
reducing technology's disabilities
one byte at a time

Received on Wednesday, 25 February 2009 18:44:48 UTC