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