Re: HTML 3 Tables: Caption/Note and Axes

Dave Raggett (
Tue, 28 Feb 95 09:36:32 EST

> Table content model: To avoid wide cells, Braille needs some
> kind of note element. The cell content is moved to a note,
> and a reference to this is placed in the cell in question.
> Unfortunately (from the point of view of the simplicity of a table
> model) this is not the same as a footnote for several reasons:
> 1) It appears before the table not after.
> 2) Most importantly, it is a by-product of the Braille translation
> process -- it is *not* a reflection of existing original text. A blind
> person may yet run into footnotes on the table; they need to be
> distinguishable as such. (In multi-page tables, for example, key
> footnotes may be repeated in a footer on each page. These are not like
> those at all, and would be confusing if they found their way into a
> footer.)

There is no reason why "footnotes" shouldn't appear in advance of the
table with hypertext links from the table cells to the relevant notes.

The distinction between this braille derived notes and other notes can
be made clear by subclassing the element, using the class attribute.

A brailler or text to speech browser reading an HTML document would presumably
scan through the table to establish how to lay it out just like a GUI browser
such as Arena does. In doing so, the braille browser would create and lay out
the notes as needed to reduce the width of the table. The AXIS and AXES
attributes are part of the HTML 3.0 table model to allow authors to create
documents that are convenient to use with text to speech/braille browsers
as well as conventional browsers. The extra thought that goes into adding
these attribute values will benefit visually impaired users by offering
succinct and easily understandable cell names.

An html document created with only braille browsers in mind is practical:
you could use the NOTE element for the displaced cells and the anchor element
to reference the notes via their IDs as normal hypertext links. You might use
CLASS=BRAILLE to indicate the notes were an artifact of some earlier
translation process.

Yuri goes on to suggest the restrictions:

> Only TH has the AXIS attribute. This is where you give each row or
> column a one-word name to allow software to tell you where you are
> in the table by reading all applicable column and row headers.

> Only TD has the AXES attribute. This is where software might store
> the names of all the applicable AXIS values of the applicable row or
> column header cells. (This assumes some software won't be able to
> calculate these on the fly, particularly in tables which may stretch
> across physical pages in some representations.)

These restrictions seems quite reasonable to me.

> I would still like to see the TR model be
> (TH*, TD*)
> instead of the current
> (TH | TD)*
> in order to recognize and encourage the fact that (for machine
> processabilitiy if nothing else) a mechanism which starts with the
> table cell need look up and to the left in order to determine all
> the applicable AXISnames for its content.

No, some tables have headers on both left and right hand side columns.
Also for some languages, such as hebrew, it may be more natural to have
the headers on the right hand size of the table as the normal practice
is to read from right to left.

-- Dave Raggett <> tel: +44 117 922 8046 fax: +44 117 922 8924
Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom