Re: Proposal for checkpoint 7.6 (my action item)

Hello,

Here's why I think a table navigation checkpoint isn't
required (and this, I believe is a summary of the history
of how we got to where we are today):

1) Checkpoint 2.1 requires access to all content.
2) Checkpoint 8.1 requires the UA to communicate relationships
   among cells and headers
3) Checkpoint 7.6 requires navigation to meaningful elements, which
   includes tables and table cells in the case of HTML.

Therefore, I believe that Charles' requirement is already met
by the current set of checkpoints, and the current set of checkpoints
is the result of work that led to us removing checkpoints for
navigation to elements of a particular type.

More comments below preceded by IJ2.

 - Ian


[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000901/


Charles McCathieNevile wrote:
> 
> On Wed, 20 Sep 2000, Ian Jacobs wrote:
> 
>   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 )
> IJ
>   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
> CMN
> If I can't find out what is in a table I can't access the content. For
> graphical systems we have agreed that vertical / horizontal scrolling plus
> exporting the DOM are sufficient. That is not the same as "therefore there is
> no requirement to be able to read the content".


IJ2: see comments above.

> I had said:
>   > 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).
> IJ
>   I don't like this ISO-HTML specific checkpoint. Why doesn't SVG have a
>   container
>   model? What is the "g" element?
> CMN
> SVG does have a container model - and therefore this checkpoint would not
> apply to SVG. (My editorial bad).
> IJ
>   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.
> CMN
> No, I do not consider that this can just be a technique. It is a requirement
> to have a navigable structure, and HTML doesn't. We can specify the algorithm
> ourselves rather than referring to ISO - I just wanted to save myself typing
> something I believed everyone understood.

IJ2: If HTML is broken, ask that it be fixed. I don't think we should
enter
the realm of repair checkpoints at this point in the life of the
document.
We can make suggestions in techniques for the case of HTML. I would
rather avoid
technology specific requirements in the checkpoints (and I am glad to
get rid
of the explicit list of HTML elements if we can).

> I had said
>   > 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")
> IJ
>   Ok.
> 
> CMN
> This would apply to SVG. It is a strategy for dealing with the fact that poor
> authoring may result in a large series of paths, only differentiated by style
> properties. The gain in that circumstance might be minimal, but minimal is
> better than nothing.
> I had written:
>   > 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.
> IJ
>   We have already decided that this navigation mechanism is best handled
>   by
>   assistive technologies. I strongly object re-adding this requirement.
> CMN
> As I understood it we had agreed that a visual technology had to layout the
> things in table form and scroll up down left right with the viewport, plus
> export the DOM so an assistive technology could provide whatever it wanted. I
> didn't understand that we had therefore decided that the functionality wasn't
> important, and if we had then I register my very strong disagreement with
> that decision.

IJ2: See comments above.
 
> charles

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Monday, 25 September 2000 08:51:03 UTC