WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Table Structure Policy question

for

From: Duff Johnson
Date: Dec 10, 2010 5:21PM

Jared,

Thanks for such a complete answer. It more-or-less mirrors my thinking and arguments precisely, except that I was under the impression that scope and IDs/headers had reasonable support in "modern" AT... sorry to hear that's not the case.

I have a couple of followup questions, for which I've snipped, below...

>> 2) For complex tables, the use of "scope" is not acceptable. The id/headers method must be used.
>
> <snip>
> ... there's currently no way to know which are
> the row headers and which are the column headers.

No? I thought that's what scope is for!

After all... if a TD "knows" that it has two THs.. and if one TH has a scope of col and the other has a scope of row... then it's possible to identify the row or column headers from the TD and thus provide navigation with no additional information.

Perhaps because I come from the land of PDF (where the subject of this policy was raised, btw), I've always tended towards the assumption that multiple levels of TH cells simply recurse, and as such, the rules for voicing them in AT terms would be quite straightforward. It's disappointing to hear that support is so weak.

> This could be
> resolved if screen readers identified whether each was a row or column
> header in instances where more than one of either existed for a cell.

If I understand you correctly, and per my above point, any AT that cannot figure out which column TH and which row TH are the headers for that cell... has a nasty table-reading bug, pure and simple.

Is that a fair statement?

> However, no modern screen reader (that I know of) has implemented
> proper support for instances where a cell might have more than one
> column or more than one row header even if scope is properly
> implemented. They will either ignore the extra headers, ignore some or
> all of the headers, or read the WRONG headers.

I've always imagined that AT should simply navigate the headers recursively, which I've always assumed to be a relatively easy and reliable approach.

Again... aren't we simply talking about bugs in the software? You've confirmed by understanding of table structure. It seems (feels) like the only real problem here is lousy support for perfectly logical, reasonable and predictable table structures in current-generation AT.

...or am I missing something?

Thanks,

Duff Johnson, CEO
Appligent Document Solutions

22 E. Baltimore Ave
Lansdowne, PA 19050
+1 610 284 4006
+1 617 553 1934 (direct)
<EMAIL REMOVED>
http://www.appligent.com
http://www.twitter.com/duffjohnson