Re: Proposal for checkpoint 7.6 (my action item)

OK. This makes sense to me, so I withdraw the proposal for navigating table
cells.

I agree that the place to  repair HTML is in the HTML WG, but there may be
many reasons why a document is not constructed with a container model. HTML
is just one example of a type that is rarely created in this way.

An alternative approach is to require that any outline (for example provided
in accordance with 8.4) be navigable parent-child and sibling-sibling. This
is weaker than my original proposal, since it is not clear how such an
outline is constructed. I agree that there is a problem with the specificity
of my proposal. An alternative would be to propose to the WCAg group that
they make explicit their requirement for structure, in such a way that a
checkpoint of this kind could refer to it. But that will also be complex.

Charles

On Mon, 25 Sep 2000, Ian Jacobs wrote:

  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
  
  

-- 
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 Monday, 25 September 2000 09:05:02 UTC