Re: summarization information delivery options: attribute or element

Hi John,

> I agree Gez, and in a bit of shameless self-promotion, I just posted a very
> brief blog posting about this very topic: http://john.foliot.ca. I welcome
> your thoughts, as well as the thoughts of others.

Reading your blog post, it seems you're also of the opinion that
summary is a long description for a data table. I don't think anything
extra is required to provide this, as this is the kind if information
that would benefit everyone; not just people using screen readers that
would benefit from a concise overview of the structure, as this isn't
visually evident.

> 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.

> 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.

> 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.

> 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.

Cheers,

Gez


-- 
_____________________________
Supplement your vitamins
http://juicystudio.com
http://twitter.com/gezlemon

Received on Thursday, 25 February 2010 23:40:43 UTC