Re: Draft text for summary attribute definition

2009/3/1 Robert J Burns <rob@robburns.com>:
> Do we need to rely solely on heuristics to determine which tables are layout
> and which are not when some authors will be eager to make the distinction
> explicitly? I think we do a disservice to non-visual users if we take such a
> strident approach.

A better approach to explicitly identify layout tables would be to use
explicit markup, rather than interfering with an attribute whose
primary purpose is to provide guidance on how to read a data table for
people with vision impairments. Using role="presentation" on a layout
table is infinitely better overloading the definition of the summary
attribute.

> I'm not speaking about WCAG here. I'm suggesting that it is advisable to
> mark the use of layout tables explicitly, since it allows authors who need
> to resort to a single layout table to make that explicit in their markup
> rather than forcing AT to rely on heuristics.

Depending on heuristics could be avoided with explicit markup, such as
role="presentation", rather than interfering with attributes intended
to aid accessibility. There is already confusion about how to use the
summary attribute, without trying to make it the workhorse to
determine which tables are data tables and which tables are layout
tables, and used as a backup for when someone doesn't provide a
caption. The summary attribute has a definite purpose, explained in
version A in the wiki.

> Part of stating unambiguously is filling in the holes where authors will be
> confused about what to do. One of those places is when an author, for
> whatever reason, feels the need to resort to a layout table. If we don't
> provide advice for this situation we do harm to AT users.

Markup already exists to unambiguously determine a layout table.
Overloading the purpose of the summary attribute adds unnecessary
ambiguity. The purpose of the summary attribute is to describe how a
data table is to be read. Simple. If a layout table must be used,
role="presentation" removes ambiguity for AT.

> The second place
> that leads to ambiguity is not telling authors what to do when they
> determine their visual users do not need a caption. If we don't want summary
> used for this purpose, then we should still state explicitly what authors
> should do in this situation.

This is probably the main reason why this discussion has been circular
on the HTML5 mailing list, with everyone talking past each other. The
purpose of the caption element and the summary attribute are
completely different. The caption is intended to provide a title for
the table. The summary attribute is intended to guide users with
visual impairments how to read the table. The summary attribute isn't
a backup for the caption, or vice versa.

>> WCAG 2.0 does not give advice about providing a summary attribute for
>> layout tables. One of the techniques makes a passing reference to a
>> null attribute being acceptable on layout tables (not recommended; not
>> advisable; acceptable).
>
> Agreed.I wasn't trying to claim any more than that. However, I do think it
> is something that HTML document conformance should address or we leave
> ambiguity that is harmful to some users.

Beyond describing the purpose of the summary attribute with simple
examples, guidance on using the summary attribute is best left to
WCAG, or we run the risk of people trying to overload the purpose of
an attribute that is important for accessibility.

> I simply want to make sure we
> address the problem of layout tables (though that might be done instead with
> another criterion such as perhaps prohibiting layout tables).

The use of something more explicit, such as role="presentation",
addresses the problem of layout tables without overloading the purpose
of an important accessibility attribute.

> Again, I feel
> it does harm to AT users to not address the situation.

Something more appropriate, such as role="presentation", addresses this concern.

> I wasn't really referring to the prose. I'm suggesting that leaving gaps in
> these particular situations and use cases (and there may be others) leads to
> ambiguity, however well written the prose. So my point is that if we do not
> address the omission of captions (which often aren't needed for visual
> users) and the continued though diminished use of layout tables, we leave
> ambiguity in the specification that is detrimental to disabled users and
> users of non-visual media.

Overloading the use of summary attribute really isn't a good idea, no
matter how well intentioned your reasoning. It has a specific purpose,
and redefining its purpose to align it with caption is the main reason
why there is so much resistance to it being accepted in HTML5.
Personally, I would prefer HTML5 to make the caption element mandatory
for data tables. I know that isn't going to happen, but I don't want
the summary attribute abused to make up for it.


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

Received on Sunday, 1 March 2009 03:17:24 UTC