E-mail List Archives
Thread: Table Structure Policy question
Number of posts in this thread: 4 (In chronological order)
From: Duff Johnson
Date: Fri, Dec 10 2010 2:00PM
Subject: Table Structure Policy question
No previous message | Next message →
Friends,
We have a client who has stated the following policy for the tagging of tables for accessibility purposes:
I would appreciate opinions on this policy, which has been summarized as follows:
----------
Simple tables are defined as having:
a) no spanning cells, and
b) only 1 logical level of both row headings and column headings, and
c) only 1 actual row of column headers.
All other tables are complex tables.
1) For simple tables, the use of "scope" is perfectly acceptable.
2) For complex tables, the use of "scope" is not acceptable. The id/headers method must be used.
3) Colspan and rowspan attributes are considered to have no role in providing logical structure (since spanning cells trigger a requirement for IDs/headers under this policy).
4) In complex tables, the use of "TH" in row heading cells is said to be OPTIONAL (due to the use of the id/headers method).
------------
I recognize this policy as related to the advice given here:
http://webaim.org/techniques/tables/data#headers
With respect to colspan and rowspan, the policy seems to be inspired by this:
http://webaim.org/techniques/tables/data#spanned
Any comment?
Thank you.
Duff Johnson, CEO
Appligent Document Solutions
22 E. Baltimore Ave
Lansdowne, PA 19050
+1 610 284 4006
+1 617 553 1934 (direct)
= EMAIL ADDRESS REMOVED =
http://www.appligent.com
http://www.twitter.com/duffjohnson
From: Jared Smith
Date: Fri, Dec 10 2010 4:03PM
Subject: Re: Table Structure Policy question
← Previous message | Next message →
On Fri, Dec 10, 2010 at 1:58 PM, Duff Johnson < = EMAIL ADDRESS REMOVED = > wrote:
> a) no spanning cells, and
> b) only 1 logical level of both row headings and column headings, and
> c) only 1 actual row of column headers.
If I understand this correctly, it might be easier to state b) as "No
cell has more than one column header and no more than one row header".
> 1) For simple tables, the use of "scope" is perfectly acceptable.
Why not "the use of scope is required"? "Perfectly acceptable" means
"perfectly optional" to developers.
> 2) For complex tables, the use of "scope" is not acceptable. The id/headers method must be used.
Scope is valid for complex tables with multiple levels of column
and/or row headers. It's also acceptable for spanned column/row
headers. However, you can see how it would be confusing for a screen
reader user to determine the structure of a table if more than 2
headers are being read - there's currently no way to know which are
the row headers and which are the column headers. 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.
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.
NVDA doesn't support scope at all (at least for me in 2010.2, though
it's supposed to). Window-Eyes supports scope partially and some of
the time. JAWS supports one level of scope (at most one row and one
column header). VoiceOver supports one level of scope="col", but reads
the headers incorrectly if there are any empty cells in the header row
(http://www.accessibleculture.org/research/voiceover-and-tables-with-an-empty-first-header-cell/)
and doesn't yet support row headers.
In short, support for scope is pretty poor. And if support for scope
is poor, then screen reader support for id/headers is abysmal. No
screen reader properly supports it yet. JAWS comes closest, but it
only reads at most two headings (and the two it reads seem quite
random).
Fortunately, the use of id/headers would only be necessary in a table
in cases where a header's scope would apply to a cell that doesn't
actually belong to that header. This is quite rare and can usually be
alleviated by simply splitting the table into multiple tables, which
will be usually be better for everyone anyway.
> 3) Colspan and rowspan attributes are considered to have no role in providing logical structure (since spanning cells trigger a requirement for IDs/headers under this policy).
I don't understand this statement. Again, the presence of spanned
cells doesn't automatically make using scope an insufficient
technique. As noted above, it's the best technique except in rare and
very complex cases.
> 4) In complex tables, the use of "TH" in row heading cells is said to be OPTIONAL (due to the use of the id/headers method).
Identifying the actual headers with <th> would be much more vital to
accessibility than associating the data cells to them with the headers
attribute or scope. Because there's no way to differentiate a data
table from a layout table, screen readers often look for the presence
of <th>s to tell what type it is. If there are no headers, the screen
reader is likely to treat it as a layout table, thus id/headers
(assuming they were actually supported), wouldn't be recognized. <th>
is vital for all table headers.
> I recognize this policy as related to the advice given here:
>
> http://webaim.org/techniques/tables/data#headers
We probably should update this page to reflect the actuality of table
accessibility, not the way it's supposed to be. Do note that the
simple id/headers example on that page could be made accessible using
only scope - that is if screen readers supported it correctly. No
screen reader I tested currently handles even this simple example
correctly when using either scope or headers/id.
So, you can require headers/id that is overly complex and doesn't ever
work, or you can require scope, which is simple and might sometimes
work. As such, I'd recommend dropping any requirement for id/headers.
I'd maybe go with something like this:
- Identify all table headers with <th>.
- Do not use <th> for anything other than a non-empty table header.
- Where possible, simplify or 'flatten' tables so that no data cell
has more than one column header and no more than one row header.
- Provide the appropriate scope attribute value (row or col) to each <th>.
- When any cell within the scope of a row or column header does not
belong to that header (e.g., very complex tables with spanned cells or
headers), separate into multiple tables to ensure accessibility.
Jared
From: Duff Johnson
Date: Fri, Dec 10 2010 5:21PM
Subject: Re: Table Structure Policy question
← Previous message | Next message →
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 ADDRESS REMOVED =
http://www.appligent.com
http://www.twitter.com/duffjohnson
From: Jared Smith
Date: Fri, Dec 10 2010 6:03PM
Subject: Re: Table Structure Policy question
← Previous message | No next message
On Fri, Dec 10, 2010 at 5:21 PM, Duff Johnson wrote:
>> ... 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!
You're right. Authors can define this markup, but screen readers do
not identify them as column headers as opposed to row headers. They
simply read the header text. And in the case of JAWS, there is no
consistent in which is read first if you're using headers/id, so you
can't even rely on the first header text being the column header, for
example.
Added difficulty comes when there are more than two headers. Assuming
this were actually supported in any screen reader, the user would not
know if the extra header is another row header or another column
header without navigating through the table and orienting to its
structure. This is why I think screen readers should identify these
explicitly in this instance ("Column headers: blah, blah").
> 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?
Very fair. You can call it a bug or lack of a feature, but no matter
how you cut it, these are accessibility techniques that have been in
HTML and accessibility guidelines since at least 1999 though they are
not yet properly supported by any screen reader.
> 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?
I think you've summed it up well.
Jared