Harlan Messinger <hm*******************@comcast.net> wrote:
The real-life state of affairs is just awful. I created the expanded
set of examples at
http://gavelcade.com/table2.html, and tested it
with JAWS and IBM Home Page Reader. The results are discouraging
because the leave the sense that with current variations in the
technologies, I'm afraid that the best you can do might be either (a)
provide table accessibility formally, according to recommendations or
guidelines or regulations, ignoring what existing UAs do with it, or
(b) choose one UA to target, and hope other UAs do the same thing.
On the test page, ignore example 2. Examples 1 and 3 are as before.
Example 1 has no accessibility attributes, and Example 3 is identical
except for the "Country" header in the upper left-hand cell, which is
marked with scope="col".
Example 4 has id attributes in the column headings, and headers
attributes in the non-top-level column headings. It follows Ferg's
assumption that data cells will be associated with a TH found above
them or to the left of them, and that the TH's headers attributes will
then be followed to further associate the data cell with higher-level
headers.
Example 5 has both headers and data cells fully marked up with id and
headers attributes. Each data cell's headers attribute associates it
directly to all three levels of column headings, as well as to the row
heading. This could be redundant--data cells are associated with their
higher-level column headers both directly AND vis the lower-level
column headers to which they are associated.
Example 6 is like Example 5 except that the headers attributes in the
header cells themselves are removed, eliminating the redundancy noted
for Example 5.
Example 7 explicitly associates data cells only to the row header and
the lowest-level column header, rather than assuming that the UA will
figure out the lowest-level header as Example 4 did, but, like Example
4, leaves it to headers attributes within the header cells to provide
further associations to higher-level column headers.
The results listed below show what headers are spoken for (1) reading
a cell's contents; (2) changing row; (3) changing column. I refer to
"country" to indicate that the row header is read, and level1, level2,
and level3 for the three levels of column header. In every case, when
a header *has* been read, it has been the correct one for the cell.
Note that for HPR, Example 1, with no special markup at all, is
handled the best! The only less-than-optimal aspect of its handling of
Example 1 is that it reads all the column headers when the column is
changed, instead of just the headers that have changed.
JAWS
Example 1:
Read cell: level1 country
Change row: country
Change column: level1, whether it has changed or not
Example 3: same as Example 1
Example 4: same as Example 1
Example 5:
Read cell: level3 country level1 level2
Change row: country level1 level2
Change column: level3
Example 6: same as Example 5
Example 7:
Read cell: level3 country
Change row: country
Change column: level3
HPR
Example 1
Read cell: country level1 level2 level3
Change row: country
Change column: level1 level2 level3
Example 3: no headings read under any circumstances
Example 4: no headings read under any circumstances
Example 5:
Read cell: level1 level2 level3 country
Change row: level1 level2 level3 country
Change column: level1 level2 level3
Example 6:
Read cell: country level1 level2 level3
Change row: country level1 level2 level3
Change column: country level1 level2 level3
Example 7:
Read cell: country level3
Change row: country level3
Change column: country level3
--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.
