fodder for the "central reference" resource(s) - explaining access failure modes

>Resent-Date: Tue, 30 Nov 1999 07:59:06 -0500 (EST)
>X-Mailer: Novell GroupWise 5.5.3
>Date: Tue, 30 Nov 1999 07:57:59 -0500
>From: "Steven McCaffrey" <smccaffr@MAIL.NYSED.GOV>
>To: <W3c-wai-ig@w3.org>
>X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id
HAA00315
>Subject: Tables and the meaning of "equivalent", an overdue reply
>Resent-From: w3c-wai-ig@w3.org
>X-Mailing-List: <w3c-wai-ig@w3.org> archive/latest/4496
>X-Loop: w3c-wai-ig@w3.org
>Sender: w3c-wai-ig-request@w3.org
>Resent-Sender: w3c-wai-ig-request@w3.org
>
>   
>  
>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 08:25:43 UTC