Re: summarization information delivery options: attribute or element

>   
>> 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 with this point.

We keep talking about elements and attributes, but these are solutions. 
What we really need to understand is what is the problem we're solving. 
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 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.

Doesn't mean that there aren't other people who need help in other ways, 
and we should identify these ways and ascertain that there are solutions 
for their needs, as well. But that doesn't mean we should take a simple, 
elegant solution to one specific need, and convert it into something 
that not only probably won't solve the original need very well, but not 
solve anyone else's needs, either -- because we keep trying to solve the 
world of special needs, all at once.

You can't solve all problems with one solution. If we could, HTML would 
consist of one element: div.

I don't believe we need new elements, either. I do think we need to 
identify the special needs for HTML tables, and provide recommendations 
that address these needs. But I don't think this means having to trash 
summary, just because it doesn't solve all possible problems.
>> while also acknowledging the
>> significant resistance to @summary.
>>     
>
> The main resistance to the summary attribute is that it hasn't been
> used correctly in the past. I don't see this as a reason to abandon
> something useful, but a reason to make sure it's better described in
> the specification. I also think there's resistance because people just
> don't understand the purpose of what the summary attribute was
> originally intended; understandable, as there's so little guidance and
> it's been misused in the past.
>
> If something is provided that is made available for everyone, then I
> think the original purpose of the summary attribute will be even less
> likely to be used, as the structure is visually obvious and I don't
> think people will see past that (no pun intended), and merely provide
> a long description for the table that isn't likely to include prose
> that is visually obvious.
>
>   

Emphatic agreement.

>> As some-one once said to me, you can be
>> right, or you can be married. Personally, I prefer to focus on how we
>> support the end users, rather than the specific technique involved - if the
>> <details> proposal delivers on the solution, but meets less resistance than
>> @summary, the end user still wins, no?
>>     
>
> I don't think so, for the reason outlined above. I don't have a
> problem with the details proposal if its purpose is to provide a long
> description of a data table, but I don't think it would serve what the
> summary attribute was intended to do; that is a loss for the intended
> audience of the summary attribute.
>
>   
Head nodding, emphatic agreement.

>> One of the points I touch on in the posting is that cognitive studies have
>> shown that lists are easier to 'consume' than even paragraphs. An attribute
>> couldn't take on a list, an element could. (lists are also generally quite
>> concise)
>>     
>
> <snip>
>
>   
>> I think making this content material that is inside of an element allows
>> authors a level of creativity in making that content available to all users,
>> not just those who have AT wired to extract @summary.
>>     
>
> If we're talking about a long description for a data table, then I
> agree. It should be available for everyone, provided in rich markup
> and nothing new is required to do that. My concern is that people who
> cannot see the data table visually will be left out, which obviously
> doesn't help the people the summary attribute was originally intended
> for.
>
> Ultimately, I think our different points of view are based around
> whether the summary should provide a concise overview of the
> structure, or whether it's a long description for the data table. I'm
> of the opinion it's the former, and respect that you and many others
> are of the opinion that it's the latter.
>
>   
(This is a good reminder for me, as I find myself bristling more than 
once because of these discussions.)

Suggestion, and I'm new to the group, and not an accessibility expert, 
so forgive me if I'm out in left field with this one, but I would like 
us to consider taking a step back, and perhaps -- and I know people are 
tired of this discussion and just want to solve _something_ and move 
on-- focus for the moment on the special needs use cases for an HTML 
table, rather than getting into debates of elements over attributes, and 
whether to use a button or not.

I just can't help thinking we don't need to create anything, redefine 
anything, or drop anything to solve most, if not all of these cases. And 
the less disruption we create moving from HTML4 to HTML5, the better off 
everyone, and that includes people with special needs, will be.

> Cheers,
>
> Gez
>
>
>   

Shelley

Received on Friday, 26 February 2010 05:56:04 UTC