ISSUE-130 layout-tables vs ISSUE-129 ARIA mapping

In decision on ISSUE-129 ARIA mapping, several specific role 
combinations (such as <h1 role=spinbutton>) were forbidden. 

As consequence of ISSUE-130 layout-tables, it seems logical to make it 
non-conforming to use <table role=presentation> in combination with 
certain "semantic" table features non-conforing. 

Proposal: layout table should not contain any <th>, <caption>, 
@summary, @headers and @scope. Logically/Optionally, they should also 
not contain: any <tfoot>, any <thead>, more than 1 <tbody>, more than 1 
<colgroup> or any <col>, since these features are primarily meaningful 
for semantic scoping/cell headinghiearchy navigation - layout-wise, 
they shouldn't be needed.

Discussion: Combined with <table role=presentation>, an AT would not 
convey the above features' normal semantics. For example AT would not, 
I believe, make any use of @headers/@id or @summary or <caption>, if 
the table is presentational. And features with scoping effect are 
typically used to highlight the structure of data tables are thus also 
not meaningful in a presentation table. In combination with 
role=presentation, these features would make the table /look/ 
"semantic" and meaningful, whereas it in reality would be nothing more 
than - well - layout. 

Summary: a single layout table should only have a single <tbody>, a 
single <colgroup> and as many <td>s as necessary. Most 'layout tables' 
out there do only use those elements.

If it were to become conforming to combine <table role=presentation> 
and <th>, then, at least in practical terms, we would expand the 
meaning of 'layout table' a good bit from the traditional view of what 
a layout table is.

Thoughts? Could this proposal have negative consequences? E.g. are 
there times when it is meaningful to interactively switch a table from  
role=presentation to "table role", and vice versa?
-- 
leif halvard silli

Received on Wednesday, 16 March 2011 18:58:46 UTC