RE: EO Tutorials review

[Andrew wrote] The conclusion that I'm coming to is that if one wants to
have a significantly higher degree of certainty that AT will read the table
correctly that they need to have the scope="row/col" or headers/id
explicitly indicated for all of the headings.

I am in favor of requiring scope for tables with more than one row or column
of header cells.  The stipulation is that this will only work if the scope
applies to all cells in that row or column -- if it doesn't then id or
headers must be used.

Jonathan

-----Original Message-----
From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: Tuesday, May 27, 2014 10:25 AM
To: David MacDonald; WCAG
Subject: RE: EO Tutorials review

2) I think we need to address the issue of a two tier simple table which
both JAWS and NVDA handle OK now. I think they should be allowed without
headers and ids. I have an example here
http://davidmacd.com/test/two-tier-simple-table.html

David,
I've been looking into this and I'm tossing around a few thoughts around
tables.  The questions that I think we're trying to address related to H63
are:
1) Is explicit structure required to meet SC 1.3.1 for all-non-simple
tables?
2) Would using scope=row/col be enough?
3) Would using headers/id be enough?
4) Would using just <TH> be enough?

This quickly gets into the question of accessibility support. I did find
that your table worked well with NVDA (and assume that your other testing is
correct), but I had made similar tables and found some issues.

http://awkawk.github.io/scope_col_colgroup.html - this page has five tables.
The most interesting ones are the first and last.  The first one has only TH
elements.  It _almost_ reads correctly - JAWS seems to handle it correctly,
but NVDA identifies the Massachusetts header as a row header.  Voice over
trips all over this table in other ways (including identifying the
"chickens" cell as a header for "massachusetts"??).

The tables where scope is explicitly identified work great.

The final table was made because I sometimes hear that assistive
technologies don't pay attention to scope, but it is clear that they do.  I
took a table with scope that was functioning properly and changed the
attribute values for a few of the scopes and the results are rather
interesting, but do indicate to me that the AT is using the scope attribute
to determine table headings.

Then when I tried your test, I get different results, and the only real
difference is the cells in the upper left - I left mine unmerged and made
then <td> as they aren't headings, and you have yours merged and made into a
<th>.  So there's something in the AT's heuristic for determining what is a
heading and what is not that is choking on this change.

The conclusion that I'm coming to is that if one wants to have a
significantly higher degree of certainty that AT will read the table
correctly that they need to have the scope="row/col" or headers/id
explicitly indicated for all of the headings.

What do you think?

AWK

Received on Tuesday, 27 May 2014 14:33:32 UTC