- From: David Poehlman <david.poehlman@handsontechnologeyes.com>
- Date: Sun, 1 Mar 2009 14:06:18 -0500
- To: Robert J Burns <rob@robburns.com>
- Cc: HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
hmm, summary="presentation"? have at flag it as such? On Mar 1, 2009, at 1:46 PM, Robert J Burns wrote: 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 19:08:23 UTC