- From: Harvey Bingham <hbingham@ACM.org>
- Date: Mon, 11 Jan 1999 22:19:51 -0500
- To: w3c-wai-ua@w3.org
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