WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Examples of and justification for id/headers incomplextables

for

From: Andrew Kirkpatrick
Date: May 24, 2007 2:12PM

> Scope only seems simple in theory. When working with
> complex, dynamic tables, id/header is easier, as they are
> simple attributes that are easily expressed as variables.
> Setting up colgroups and the varieties of row group elements
> are problematic in CSS styling and cross-browser
> implementation flaws. For financial institutions that live
> and breathe complex data tables, the id/header attribute is a
> simple solution that is reliable cross-browser.

I'm not sure what the CSS styling issue you describe has to do with the
use or non-use of scope. Can you explain more? Even if you use scope
you still might need to use id for assigning styles.

> Scope does not address the problem of tables with merged
> cells. Only id/header allows the developer to precisely
> assign the header for a merged cell cross-browser.

That depends on where the heading or the content cells are merged. If a
spanned row or column heading cell has scope properly assigned it is
unambiguous which data cells are associated with it. If the data cells
are merged across heading cell boundaries then that would require
id/headers.

I see tables where my initial reaction is "that should be more than one
table" - these tables often need id/headers for correct and unambiguous
associations between data and heading cells. I don't see any good
reason why keeping the "headers" attribute should be a problem, but I
also agree that scope is the easiest way to handle this association for
most tables.

AWK