Re: Proposal for checkpoint 7.6 (my action item)

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
container
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")

Ok.
 
> 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
by
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