W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2000

Re: Proposal for checkpoint 7.6 (my action item)

From: Ian Jacobs <ij@w3.org>
Date: Wed, 20 Sep 2000 12:20:30 -0400
Message-ID: <39C8E3CE.6FE6D341@w3.org>
To: Charles McCathieNevile <charles@w3.org>
CC: WAI UA group <w3c-wai-ua@w3.org>
Charles McCathieNevile wrote:
> 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 )

I STRONGLY OPPOSE THIS PROPOSAL. The WG long ago chose not to include
a table navigation checkpoint and I don't believe that this issue should
be reopened at this point. Refer to issue 160 [1]

[1] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#160
> 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).

I don't like this ISO-HTML specific checkpoint. Why doesn't SVG have a
model? What is the "g" element? 

Can this just be a technique? Is there a URI to the ISO-HTML spec?
If a URI isn't available (or if the ISO spec costs money) I am not
excited about including it.
> 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.

We have already decided that this navigation mechanism is best handled
assistive technologies. I strongly object re-adding this requirement.
> 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.

 - Ian

Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Wednesday, 20 September 2000 12:20:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:28 UTC