Proposal for checkpoint 7.6 (my action item)

Proposal and rationale - techniques to follow...

My proposal is to modify as follows:

Add a P1 requirement for columnwise navigation of tables.
 (two different techniques:
    + provide cell-level focus and vertical movement within tables or
    + use tablin or similar to change the table axes back and forth )

add a P2 requirement to be able to navigate a Document tree (parent-child,
and sibling-sibling, moving each way). This is an extension of 7.6

Add a P2 requirement for document types which are not based on a container
model (i.e. does apply to HTML, does not apply to SMIL or SVG) to navigate an
outline constructed according to the algorithm ISO-HTML specifies (and WCAG
implies) for using Hx elements. (same requirements as for the actual tree).

Add a P3 requirement to navigate a tree configured according to checkpoint 
8.5 (i.e. as above but with the user able to configure what elements are
used as dividers in the algorithm). The user should be able to specify
elements, or elements with specific style properties. (Al's "show me the next
thing like this")

Rationale:

The requirement is that a person who has restricted ability to cope with a
lot of content at once (for example using an audio interface) and has limited
ability to navigate (for example using a restricted keyboard), can easily
work with a document such as a large table, a specification, or a section of
a text book (to name just a few of many possible examples).

It is possible to get to all the content by being able to read the document
forwards. however, in the case of a grid such as a table this may not make it
possible to understand what items are in what column. If the person can move
from the beginning of a column to the end of it, vertically, then this is
solved.

So an absolute requirement is to be able to do this.

This makes it possible to find out what all the structures are, but it is
still very difficult, it is not easy to navigate, and it requires remembering
all the context one has passed through. If navigation is not bidirectional
the difficulty is increased significantly, effectively requiring someone to
recall almost the entire context of a document to understandd the context of
something near the end.

In order to make this workable, it has to be possible to navigate the
structure faster, in order to remember the context more easily.

Method 1:
Navigate the DOM tree. For container based languages (for example WML) this
works quite well. The required motion is parent-child and
sibling-sibling. But for content such as HTL, which does not have a container
model, this is not sufficient, since it amounts in most cases to a simple
element by element navigation through a linearised tree, and does not provide
a way to recall context.

Method 2:
For well written HTML (i.e. according to WCAG, or according to the ISO-HTML
spec), it is possible to construct a containment model using the algorithm
implied in WCAG and specified in ISO-HTML. That is, each Hn element marks the
beginning of a DIV element that includes all content up to the next Hm
element where m is the same or less than n. In english, a documentis divided
into sections at the Header elements, with headers assumed to be properly
nested so that H1 sections contain 1 or more H2 sections that may each
contain 1 or more H3 sections and so on.

The combination of the first two methods provides a good navigation method
for well-written HTML. Amaya provides a sample implementation with its
structure view (method 1) and its table of Contents view (method 2)

But there is a lot of HTML which is only "structured" by means of visual
formatting. In order to provide a good method for dealing with this content,
analagous to Method 2, it is necessary to allow the user to configure the
elements (or the combination of element and style porperties) that are used
to create the tree in Method 2 above. Because of the added complexity of this
task for a user, it provides less immediate benefit than method 2, although
it does make it possible to easily navigate many existing documents that are
otherwise difficult to navigate.


cheers

Charles McCN

-- 
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
September - November 2000: 
W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France

Received on Wednesday, 20 September 2000 11:31:44 UTC