Re: Draft text for summary attribute definition

Hi Ian and Gez,

On Mar 1, 2009, at 3:09 AM, Ian Hickson wrote:

> On Sat, 28 Feb 2009, Robert J Burns wrote:
>>
>> I think we should discourage the use of layout tables, but that we
>> shouldn't avoid guiding authors who use them (unless we're prepared  
>> to
>> prohibit their use and say "authors must not use layout tables").
>
> The spec does in fact currently prohibit them, explicitly, several  
> times.

Yes I'm aware that the draft currently prohibits layout tables. The  
draft also currently prohibits the summarization of tables. These are  
the topics that the WG should discuss. The point I have been making is  
that prohibiting data tables in the current climate does harm to users  
of assistive technology. Authors sometimes find the need to use layout  
tables. We find them in existing web content. CSS has largely replaced  
the need for them (especially the more hideous uses of nested layout  
tables with nobreak elements and spacer gifs). However, authors have  
sometimes found CSS more cumbersome to use than to simply using a  
single layout table. Pretending that is not the case is not really an  
approach I think this WG should take since it leads to layout tables  
in content that then requires heuristics to discern (when authors  
would be happy to add an attribute value indicating a layout table).

So while the draft prohibits layout tables, I would argue that we're  
not prepared to prohibit them. Doing so really just buries are head in  
the sand and fails to provide authors sufficient realistic guidance on  
common authoring practices. Since this discussion started with the  
prospect of an RFC 2119 compatible specification of table summaries it  
would be good to remain aware of what harm a single clearly  
discernible layout table does to authors or users to warrant a  
prohibition (RFC 2219 "must not" use). As far as I know AT has no  
problem processing this. It may make maintainability more difficult  
for static pages. But for template generated pages, it is likely  
simpler to maintain than the alternate CSS.

On Mar 1, 2009, at 5:16 AM, Gez Lemon wrote:
> 2009/3/1 Robert J Burns <rob@robburns.com>:
>> I'm fine with using role='presentation' for layout tables. I think  
>> that
>> addresses the use case I described adequately. The only concern I  
>> have with
>> that is that AT already supports null summary in that situation  
>> with less
>> existing support for role='presentation'.
>
> AT already supports not providing a summary attribute at all for
> layout tables, which is why not providing a summary attribute at all
> for layout tables is allowed in WCAG 2.0, even though layout tables
> are strongly discouraged.

I'm not sure what you mean by this. Not providing a summary attribute  
on a layout table is supported, but it creates an ambiguity with a  
data table that requires no summary. Therefore we have two completely  
dissimilar tables – a layout table and a data table requiring no  
summary – both with the same markup. Assistive technology then needs  
to turn to heuristics to differentiate them.

Providing a null summary is also allowed in WCAG 2.0. And when  
providing a null summary it also helps distinguish a layout table from  
a data table in a way that omission of the 'summary' attribute cannot  
do. It also is consistent with the pattern already familiar to authors  
where alt='' indicates a presentational image. Similarly summary=''  
indicates a presentational table that should not be processed by AT as  
an actual table.

Earlier you said you preferred role='presentation' over summary='' for  
layout tables. You're also citing the HTML5 draft as prohibiting  
layout tables. Yet we still don't even have the 'role' attribute  
included in the HTML5 draft, so support for the 'role' attribute needs  
to be added before it can replace summary='' as the only other way  
proposed so far to distinguish layout tables from data tables. Again  
we're simply burying our heads in the sand regarding layout tables if  
we just prohibit them and provide no markup to distinguish them from  
data tables.

Take care,
Rob

ISSUE-32

Received on Sunday, 1 March 2009 18:47:32 UTC