Re: summarization information delivery options: attribute or element

Leif Halvard Silli wrote:
> Shelley Powers, Thu, 25 Feb 2010 23:55:24 -0600:
>
>   
>>>> I personally like Cynthia's proposal, as it addresses the *problem* at a
>>>> level that accepts that the issue does affect more than just screen reader
>>>> users. It also seeks to extend the solution,
>>>>         
>>> Exactly; this is information that would benefit everyone. It's
>>> possible to do that now, and I don't think a special element is
>>> required to do this. That's why I don't support the proposal.
>>>       
>> I think Gez really touched on the main issue  […]
>>     
>   […]
>   
>> The use case for the summary attribute is actually 
>> included within a description for the element in the HTML 4 spec:
>>
>> "This attribute provides a summary of the table's purpose and 
>>     
>
> I have never heard Gez include "purpose" when he describes what 
> @summary is for. Superficially, think any reader would like to know the 
> purpose of the table. But I suppose "purpose" in this regard is meant 
> to help the reader to decide whether i is worth it spending time to 
> read the table - as this can be quite time consuming with some media 
> types.
>
>   

I've also read recommendations for including the name of the table in 
summary, as well as purpose and description of structure. I think, 
though, that common sense tells us that if the purpose of the table is 
integrated into the text that precedes the table, it doesn't need to be 
repeated in the summary attribute.

And it is just this kind of information that could be used to annotate 
the summary attribute in the HTML specification, making it more useful.

>> structure for user agents rendering to non-visual media
>> such as speech and Braille."
>>
>> That's very concise, very specific, definitely a strong use case, and 
>> with a simple, to the purpose solution: an attribute that's specific 
>> to devices that either deliver the text as Braille, or as speech.
>>     
>
> Perhaps we should simply limit ourselves to say that it could sometimes 
> be of benefit to be able to explain something to one user group, 
> without disturbing another. That's what I'll try to do with my upcoming 
> media/accessibility <caption> proposal.
>   


I think that's a very good way of looking at it. the @summary attribute 
has a specific purpose for a specific audience: a description of the 
physical layout of unusual or complex tables specifically focused at 
those who are using screen readers or braille readers.

What I'd like to know is what other aspects of the table can make 
understanding the table contents difficult, and for which community. 
There was discussion about Cynthia's proposal and how it would aid other 
communities. But Cynthia's proposal doesn't touch on any other community 
other than those needing to use screen readers or braille devices. The 
only reason to have the hovering/visibility is so that authors can see 
the text, in the page, because supposedly the whole hypothesis behind 
the reason summary is failing, is because we sighted authors and 
developers won't fix what we can see in the web page.

The discussions about other groups, such as low vision groups, or those 
with cognitive disabilities, is also completely tangential to Ian's 
original pushback against the summary attribute, or Cynthia's proposed 
solution.

So we're going in two directions: one has to do with summary, and 
whether the fact that the text is not visible in the web page, when 
loaded in the browser, is causing all the problems with its use; the 
other has to do with the perception that summary doesn't solve all 
issues related to the accessibility of the HTML table, and it should, or 
something should solve all the accessibility issues with HTML tables.

I'm curious, Leif, where does your caption proposal fit into this? The 
summary is broken because it's not visible in the browser? Or the 
summary doesn't provide a solution for all known accessibility problems? 
And if it's the latter, what accessibility problem will your 
recommendation solve?

Of course, all of this will probably be in the change proposal, so if 
you want to just tell me to be patient, that's cool too ;-)

Shelley

Received on Friday, 26 February 2010 19:11:01 UTC