Fwd: Table Models

On 1998/01/06 I sent the following message [here slightly edited] to the 
tables technical subcommittee of OASIS-Open, as they are starting a review
and update of the earlier SGML-Open work on tables, of which I was a leader.
----
I encourage any review of the OASIS-Open Exchange (ETM) or 
CALS Table model (CTM) to include the accessibility attributes of 
the HTML 4.0 table model (HTM). 

The principal accessibility issues are 
1) finding the table and what it is about (a table tag and caption or possibly
   an attribute for table title)
2) determining the table structure (and substructure)
3) determining the heading information
4) determining the data cells and the particular heading information that 
   applies to them
5) navigating into that structure in the way that is most natural for
   the particular use (possibly different for different users and
   even for different referrals by the same user).

We ignored accessibility issues in the CTM and ETM table models we developed.
By the time Dave Raggett talked with us about HTM, he had some input on
accessibility. [Some of that input was from Yuri Rubinsky, some from the
ICADD team, other parts of it from those of us that worked on CTM and ETM]. 
I believe there is a far better chance of making the HTM accessible, and even 
transposable, or subsettable, because the identifying information can be
included in the various attribute lists. Therefore HTM is a better starting
place than either CTM or ETM to meet broader needs for making information
available to a variety of user agents, including those with only aural
output, or aural command input or keyboard navigation in place of the mouse.

In essence, the HTM has header cells TH and data cells TD. TH elements provide
identification (column headers and row stubs, possibly with spanning in
either rows or columns, and redefinition when header information changes). 
Each TH has an ID and possibly a shortened form if the actual identification 
content is lengthy. HTM also allows the CALS row sectioning into thead,
tfoot, and tbody. It adds column sectioning, into either COLs or COLGRPs

In a simple, small table, the user can remember which TH apply to which TD.
As the number of rows and/or columns becomes more than 4 or 5, the user may
want help identifying the TH that apply to the TD. 

To provide that help, the data cells TDs have IDREFs to the ordered list 
of TH IDs by which those remote identifying cells can be found and that 
identification presented, as part of the implicit context of the data cells.
[An application-specific stylistic convention could differentiate between
TH used as column heads from those used as row stubs, possibly in the
naming of the unique ID attribute values.] 

A user (hands-free, eyes-free) can request how the table is to be presented.
For examples, by rows, by columns, by selected rows and/or columns 
containing some content, etc. An "announcer" based on some or all of the 
TH in its IDREF list may be requested selectively, and the identifying
content used to provide the content for the announcer, read before the
actual TD content.

Some ordering of TD to have recognizably distinct values (such as 
alternating numeric and textual TD along a row) may reduce the need for
extensive help. It may be sufficient in such case to announce those column 
headings once, and identify just the TH row stub once for all the TD in 
that row. 

A user knowing the application may seek particular expected content. For
selection the search may be limited to TH content or TH attribute values.
It may also be based on TH-qualified TD content (or attribute values).

A user may choose how much of the implicit information from the TH to be
prefixed (or queried) for each data cell.


The ideas expressed on alternative representations for tables break away
from the concept that the 2-dimensional table is a sufficient structuring
means. Some of these alternatives are based on lists of lists.

Recursive tables we fought against in CALS, as it eliminated some complexity
in presentation when constrained to fitting the table on a page, or only
letting growth occur by adding rows, possibly splitting across pages and
having thead and tfoot as stable row content repeated on each page above
and below the data rows of the tbody (an actual application may need to
revise some content of tfoot, such as page number.)

The uses (and in some minds abuses) of HTM today depends on tables for
presentation of dissimilar layout, font size and style, in different
columns or rows, as the means to achieve a different appearance. Often
that effect conflicts with user preferences for how the material is to
be displayed (window size, font, and point-size can distort the author's
display design.) 

Screen reader technology that does not know the particular application
source, but just intercepts the input stream to the rasterizer, can
readily get confused. Many screen readers read across the screen. 
Cells with contents that wrap onto several lines. A screen reader going 
across a line gets only part of each TD in each column before stepping
down to the next line (is it a new row? or a continuation of wrapped
content of the cells that provided the prior line?)

Remembered headings may be confused if the user cannot reliably know the 
column a particular content is coming from. This may happen when the content 
of some cells wraps into more lines than other cells in the same row.

If there are different font sizes in different columns, a consequence may 
be different baselines for text in the cells in those columns. If so, a 
screen reader moving down to the next baseline to continue reading may jump 
across whitespaces, and the user may be uncertain of the particular row or
column providing information. 

As you can appreciate, the use of large tables poses navigation and
identification problems. The paper model required sometimes illogical
needs to break material onto pages of fixed size. The screen model has
different constraints of a logically a semi-infinite 2-space with
scrolling across and/or down, possibly with header information no longer
in view. A linear text-to-speech presentation has limitation because of 
temporal separation and limited user memory of the remote heading
information. Solving these problems is an important accessibility
opportunity. 

Please help solve these problems.

Regards/Harvey Bingham
Yuri Rubinsky Insight Foundation
W3C Web Accessibility Initiative

Received on Tuesday, 12 January 1999 11:45:12 UTC