Tables and the meaning of "equivalent", an overdue reply

   
  
Hello all:
1. General:
I hope none of my comments thus far have been interpreted to mean I am 
arguing for the complete ban of tabular layout, whether implemented using HTML tables or CSS.  I am not arguing for this.
I am however, continuing to raise the issue of whether linearized alternatives provide equivalent access when tabular layout provides more than simple aesthetic  attributes, that is, when the layout is used for efficient information retrieval or classification.
In fact, if people with cognitive disabilities (or any other disability or no disability) finds it either useful or desireable to have a tabular layout for comprehension purposes, I am not only not arguuing for the non-use of tabular layout 
(sorry for that double negative!)
but actually  this layout should be provided.
We are not talking either/or here.  We are talking about what happens if only one format/presentation is used and whether tools exist to transform that presentation to an equivalent form for other modes of access.
If such tools exist or some stable URI exists of an equivalent alternative format exists that is maintained with equal dedication, then I think this would be sufficient.
My main focus is the definition of "equivalent".  I think the glossary of the WCAG defines this well.  I am applying it to tables here, but the issue is a larger one.
A somewhat inaccurate analogy in the area of wheelchair access to a building might be if someone said
"Well, this building used to have 10 steps, now it just has three, so access has been provided"   It's better, but not equivalent yet.
For any "alternative" to be considerred "equivalent" can only be judged, in my view, by those using the purported equivalent.
Sometimes, the users of the purported equivalent may not even be aware at first what they are missing until someone with a different mode of access points out that "With my mode of access, if I want to know Y, then all I have to do is X (e.g. focus my eyes on some area of the screen).  It does not seem to me that you, with your "equivalent" alternative, you can do the same thing."
These considerations do not apply only to tables, but whenever "alternative" formats are required.
2. In terms of priority 1,2, and 3 I guess my question would be where does the notion of "equivalent" access fall in these categories?  Is it just a matter of quantifiers (e.g. "all", "some") or is degree of access also a factor (e.g. "may have difficulty", "will have difficulty")?
 
3. Kynn, an Example:
An example of an online magazine that uses some columnar layout that I found difficult to understand is
http://www.slate.com.  Even when an article is selected, apparently the article is displayed on a screen that has some kind of 
columnar layout (I can't tell if there are frames or HTML tables or CSS).
When I linearize it, I get a list which, one by one, is understandable, but lose the whole grouping level of understanding.
The WCAG recognizes this when it points out that context could be lossed because some users access a page one word at a time.  Yes.

4. An interesting paper:

"Increasing Access to World Wide Web Sites for Blind and Visually Impaired Computer Users"
by Dena Shumila and Jan Richards
http://www.utoronto.ca/atrc/rd/library/papers/accessWWW.html
discusses many context issues the blind face when trying to understand a web page.  I do not necessarily endorse any of the proposed solutions, but think the explanations of exactly what a blind reader may lose (esp. end of 2) ) due to lack of contextual information is right on the money.
I quote a small section of their paper below.

 
"
1) OUTLINES:
Rather than assuming that users are capable of scanning the Web document, and understanding its structure as a whole, HTML writers should place a general outline at the point on the page where a screen reader would begin to read. This need not change the appearance of a web document since this information can be 
displayed as Alternate (ALT) Text inside a graphic page header. Similar 
explanations should be presented at other points in the document, particularly if it is long or divided into distinct subsections. 
These outlines are valuable to blind users because screen readers only provide information about a document's format one piece at a time. In addition, screen readers do not normally alert blind users to the presence of paragraph indentations, centred titles, bolded and underlined text, columns... In fact, if 
the screen reader is instructed to read the whole screen, the program will wrap around lines, skip over blank spaces, and ignore text attributes like highlighting and footnotes. It is then necessary to issue specific "find" commands to obtain such information. Outlines can identify relevant features of 
the document, such as its length, the number of HyperLinks it contains, and a description of its general content. 
2) TAGS & LISTS:
Tags can be used in conjunction with outlines to provide information about page breaks and lists. For example: they can appear as ALT Text within graphical page separators. The Adaptive Technology Resource Centre (ATRC)'s own home page uses 
tags by placing a single dash on either side of the tag's text. However, they can be implemented in various ways. 
Tags can also be used when labelling and constructing lists. For example: "- 
List with 7 choices -". Each of the 7 choices should then be numbered, so that readers can remember the numbers of the choices that interest them. The numbers also break up the text, providing a distinct separation between each item. For 
the sake of contrast, sub-lists could then be represented alphabetically. Avoid using the HTML list elements, because screen readers may interpret these markers 
as asterixes or ignore them altogether. Horizontal lines should also be avoided, because a screen reader, working in conjunction with certain browsers, could mistake them for text entry lines in a form. Vertical lists may also be misinterpreted by the screen reader. Although they are easy for sighted users to identify, blind readers lack the following vital information, when dealing with the typical list format. When and where does the list start and finish? When and 
where does each list item start and finish? Are there sub-lists? How many list items are there? The need for this kind of information further supports the value of tagging and describing lists, as well as numbering their items." 

-Steve
Information technology Services
New York State Department of Education
(518)-473-3453

Received on Tuesday, 30 November 1999 07:58:46 UTC