Accessibility simplification for highly-dimensional table

[Harlan Messinger]

When a table has multiple layers of column and/or row headings, as we know,
there are a couple of options for making the table accessible. Using a
*scope* attribute is fine as long as the number of column levels or row
levels doesn't exceed two, since you can only specify "col" and "colgroup"
as scope values in the former case, and "row" or "rowgroup" in the latter.

Then there's the use of *id*, *headers*, and *axis*. For most purposes, I
wonder whether it's over the top. It's highly involved, and in particular
the axis attribute seems to be going overboard unless the kind of tricks
they would permit a user agent to perform computationally are something you
would have wanted to enable even without accessibility considerations. It's
also awkward if it isn't a question of a simple set of permutations (as at:

http://mywebpages.comcast.net/hmessinger/gdp.html

)

Anyway, please take a look at:

http://mywebpages.comcast.net/hmessi...dim-table.html

I've used <th> for the row headings (states) and for the lowest level of
column headings (the grades). (If this were a real page, of course, I'd use
styles to set a uniform appearance for all three rows of column headings.)
I've set *abbr* and *title* attributes for those column headings thus:

<th abbr="1998 reading grade 4" title="1998 reading grade 4">Grade 4</td>
<th abbr="1998 writing grade 8" title="1998 writing grade 8">Grade 8</td>
<th abbr="1998 reading grade 4" title="1998 reading grade 4">Grade 4</td>
<th abbr="1998 writing grade 8" title="1998 writing grade 8">Grade 8</td>
<th abbr="2000 reading grade 4" title="2000 reading grade 4">Grade 4</td>
<th abbr="2000 writing grade 8" title="2000 writing grade 8">Grade 8</td>
<th abbr="2000 reading grade 4" title="2000 reading grade 4">Grade 4</td>
<th abbr="2000 writing grade 8" title="2000 writing grade 8">Grade 8</td>

Does this accomplish the basic purpose? Is it satisfactory? Should I use
only *abbr* or only *title*?

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

[Chris Morris]

"Harlan Messinger" <h.*********@co mcast.net> writes:

Then there's the use of *id*, *headers*, and *axis*. For most purposes, I
wonder whether it's over the top. It's highly involved, and in particular
id/headers is definitely worth doing, since it's the most
widely-supported form of table header/cell assignment markup - I can't
find any browsers that do anything useful with scope, though if anyone
knows of one I'll add it to my collection...
the axis attribute seems to be going overboard unless the kind of tricks
Agreed.
http://mywebpages.comcast.net/hmessi...dim-table.html

I've used <th> for the row headings (states) and for the lowest level of
column headings (the grades). (If this were a real page, of course, I'd use
styles to set a uniform appearance for all three rows of column headings.)
I've set *abbr* and *title* attributes for those column headings thus: <th abbr="1998 reading grade 4" title="1998 reading grade 4">Grade 4</td>
Seems a bit odd to have the ABBReviation longer than the cell content,
(and the abbreviations don't match the cells they're headers for).
Does this accomplish the basic purpose? Is it satisfactory? Should I use
only *abbr* or only *title*?

I think the best way to mark this up would be

http://www.dur.ac.uk/c.i.morris/multitable.html

(Though you could put title="Alabama 1998 reading grade 4" on the
<td>s as appropriate as well, I'm not sure if there's many situations
it would be useful in, but it's not going to harm anything)

(Yes, putting the headers attributes in is fiddly, but with the amount
of data involved if all 50 states were included, it really should be
database (whether SQL or flat-file) driven anyway, in which case your
server-side script and/or HTML preprocessor can take the majority of
the work out of writing it.

A few more examples at
http://www.dur.ac.uk/its/services/we...ority1/tables/

--
Chris

[Harlan Messinger]

"Chris Morris" <c.********@dur ham.ac.uk> wrote in message
news:87******** ****@dinopsis.d ur.ac.uk...

"Harlan Messinger" <h.*********@co mcast.net> writes:

Then there's the use of *id*, *headers*, and *axis*. For most purposes, I wonder whether it's over the top. It's highly involved, and in particular

id/headers is definitely worth doing, since it's the most
widely-supported form of table header/cell assignment markup - I can't
find any browsers that do anything useful with scope, though if anyone
knows of one I'll add it to my collection...

the axis attribute seems to be going overboard unless the kind of tricks
Agreed.

http://mywebpages.comcast.net/hmessi...dim-table.html

I've used <th> for the row headings (states) and for the lowest level of
column headings (the grades). (If this were a real page, of course, I'd

use styles to set a uniform appearance for all three rows of column headings.) I've set *abbr* and *title* attributes for those column headings thus:

<th abbr="1998 reading grade 4" title="1998 reading grade 4">Grade

4</td>
Seems a bit odd to have the ABBReviation longer than the cell content,
(and the abbreviations don't match the cells they're headers for).
Oh, thanks. I threw it together in a hurry. :-)

Does this accomplish the basic purpose? Is it satisfactory? Should I use
only *abbr* or only *title*?
I think the best way to mark this up would be

http://www.dur.ac.uk/c.i.morris/multitable.html

(Though you could put title="Alabama 1998 reading grade 4" on the
<td>s as appropriate as well, I'm not sure if there's many situations
it would be useful in, but it's not going to harm anything)

(Yes, putting the headers attributes in is fiddly, but with the amount
of data involved if all 50 states were included, it really should be
database (whether SQL or flat-file) driven anyway, in which case your
server-side script and/or HTML preprocessor can take the majority of
the work out of writing it.

A few more examples at

http://www.dur.ac.uk/its/services/we...ority1/tables/
--
Chris

[Harlan Messinger]

[Sorry, hit Send too quickly.]

"Chris Morris" <c.********@dur ham.ac.uk> wrote in message
news:87******** ****@dinopsis.d ur.ac.uk...

(Yes, putting the headers attributes in is fiddly, but with the amount
of data involved if all 50 states were included, it really should be
database (whether SQL or flat-file) driven anyway, in which case your
server-side script and/or HTML preprocessor can take the majority of
the work out of writing it.

Certainly, if it were database-generated. Not always an option!
A few more examples at

http://www.dur.ac.uk/its/services/we...ority1/tables/

Thanks for this.

[Lauri Raittila]

In article Harlan Messinger wrote:

"Chris Morris" <c.********@dur ham.ac.uk> wrote in message
news:87******** ****@dinopsis.d ur.ac.uk...

(Yes, putting the headers attributes in is fiddly, but with the amount
of data involved if all 50 states were included, it really should be
database (whether SQL or flat-file) driven anyway, in which case your
server-side script and/or HTML preprocessor can take the majority of
the work out of writing it.

Certainly, if it were database-generated. Not always an option!

Nobody forbids to generate table using script, even if data would not be
stored in serious database. Anyway, you usually have data somewhere when
you start marking up a table. And when you don't, it makes usually sence
to write it down first, and then making it a table.

I¹ parse my Transcript of records from email like this
http://www.student.oulu.fi/~laurirai/crap/ote.txt
(pretty much worst possible format.) to this table:
http://www.student.oulu.fi/~laurirai...ranscript.html
using this perl:
http://www.student.oulu.fi/~laurirai/opiskelu/ote.pl

I think I actually saved time² compared to marking it up by hand,
considering I want it in two languages. And, of course as updating is n
times easier using script. If I had used accessibility markup³, it would
be sure it was faster than do it by hand. If you have some long table,
including something like 50 items, it is practically always fastest to
generate it with script (at least the part that has 50 items.).

And when you do it with script, accessibility markup is probably easier
to add later ;-)

[1] Actually procmail runs the script, all I need to do is to order mail.
[2] Even if this script was first thing I have ever programmed in perl.
[3] I don't think that content of this table really interests anyone but
me, so I didn't bother. May do in future though as exercise...

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

[Brian]

Chris Morris wrote:

id/headers is definitely worth doing, since it's the most
widely-supported form of table header/cell assignment markup

I didn't know what browsers did with such information. Which browsers?
And how do they use it?

--
Brian
follow the directions in my address to email me

[Chris Morris]

Brian <us*****@juliet remblay.com.inv alid-remove-this-part> writes:

Chris Morris wrote:

id/headers is definitely worth doing, since it's the most
widely-supported form of table header/cell assignment markup

I didn't know what browsers did with such information. Which browsers?
And how do they use it?

If you can get a demo copy of IBM Home Page Reader to test with,
that's probably best. Test on
http://www.dur.ac.uk/its/services/we...ority1/tables/
or
http://www.dur.ac.uk/its/services/we...amples/tables/
or some other page with a big table on it. (careful of line wrapping)

But in summary, when in table reading mode they hit a <td> that has a
headers attribute, they read the contents of the <th>s with matching
ids (or that th's abbr attribute, if it exists).

So:
....<th id="a1">Foo</th>...
....<th id="i5">Bar</th>...
....<td headers="i5 a1">Baz</td>...
would be read
[Bar Foo] Baz (or possibly [Foo Bar] Baz)
(where the brackets might be read differently)

In browsers with a 2-D visual display and table support such
information is rarely (ever?) used since it's usually obvious enough
from other cues.

--
Chris