Re: Proposal for checkpoint 7.6 (my action item)

Summary:

1. Provide better cues to the User Agent developer as to what we mean by
efficient structural access to various points in the document.
Specifically, mention time-to-speak as a relevant measure for assessing
efficiency of access.  A sample, not minimal implementation of this point
would be: to a) say that 8.4 table of contents must be navigable and b) say
that it must be configurable as to verbosity down to "order of seven give
or take two" items.  That would meet minimum requirements, but it is not
required of all minimum implementations.

2. Ensure that something in the document means the user can step past a MAP
in one user action.

3. Differentiate among the element types mentioned in HTML; they have
different levels of structural relevance.  This is a more faithful
representation of the format specification, in a way that bears on the
efficiency of the User Agent implementation.  But also reduce this clause
to informative because it is not sufficient for a minimum implementation.  

Please read the details (below) too.

Al

At 09:05 AM 2000-09-25 -0400, Charles McCathieNevile wrote:
>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.

AG::

Sorry, this is going to be hasty.  I have been wanting to do a more
professional writeup but I know you are having a meeting tomorrow where you
need to consider this.

a) So far as I know the only justification for the P2 priority is the "top
links tank trap" problem.  Otherwise structural navigation is a convenience
but not an access necessity [only 1 vote].

b) The WCAG has two techniques for the author to use to avoid the above
problem.  One is the skip-navigation link after the fashion of the ACB
site, and the other is to wrap groups of related links in a MAP.

c) Pursuant to the second technique, there was some discussion between the
groups where I believe the status at the end of the conversation was that
yes, the GL group was assuming the UA group would ensure that the user
could step past a MAP when encountered.  This is not as efficient as the
skip-navigation link but if the author does use the MAP wrapper and the
user agent does support a "skip the whole thing" for at least this subtree,
the number of steps to get to the meat of the page gets down to a level
where it no longer merits recognition as a P2 severity access barrier.


d) It would be much cleaner to proved the "skip subtree" navigation command
more generally than just for MAP.  But providing it only within the context
of a filtered table of navigable destinations within the page would be
appropriate.  It need not be a purely syntactic rule that determines what
subtrees have this function or where you go on asking for the 'next'
instead of the current one.

e) Stepping past MAP only gets as far as implementing UA support for WCAG.
There is merit to considering what the UA should do for arbitrary HTML4
(XHTML 1.0) pages where the WCAG techniques described above have not been
followed.  This is as I understand the basis for claiming that checkpoint
7.6 is required at P2 severity.

f) The problem with the present state of 7.6 and 8.4 is that it is too flat
with regard to levels in the topic tree.  A related problem is that there
is no clean way to extract a human-helpful topic tree from the markup alone.

The access problems diminish as one gets to finer and finer levels in the
topical outline.  One always has access to reading the full hypertext
linearly.  If that is not a long process, then failing to have structural
subdivisons navigable or briefed (8.4) is not a big deal.  The
access-critical structure is the upper level or possibly two levels of page
decomposition.  A scientific rule would be to decompose until the
time-to-read of the undivided chunks is small enough.

g) The missing dimensions that are critical to the P2 level problem and are
not adequately reflected in the current set of checkpoints are

1) concern for how the implemented topic tree, whether as briefed (8.4) or
as navigable (7.6) divides up the time-to-speak of the page.  A
well-constructed effective topic tree will be tuned to break the page up
into parts of time-to-speak which are roughly equal among the children of
the same node.  This is the quantitative semantics required for "efficient"
navigation to various interesting starting points in a page.

2) concern for how long it takes to find an alternative to starting at the
top, when the page outline is used as a navigable index.  Saying that the
table of contents described in 8.4 must be navigable is almost a good
checkpoint.  The almost is because there is still a failure mode allowed
under this description if the table of contents is too verbose to provide a
rapid overview of the top level structure of the page.


h) The other problem is that the element type list is not prioritized.  The
elements named vary widely in their structural significance.  Note the note
in 8.4 which says that level of detail pruning is intended.  But it is
never defined anywhere.  The present state of 7.6 defines an untrue minimum
implementation because if the elements listed are all made the navigation
basis at the top level the resulting navigation will not be efficient.  The
success of 7.6 is likewise contingent on the implementers adding more
intelligence into what is done.

i) There needs to be stronger language saying that whatever navigation tree
is exposed to the user through 8.4 and 7.6, that it has to be very close to
exactly the same thing.  Conflicting information from the briefing (8.4)
and response to user input (7.6) would be a strong violation of "the system
response to user input must be predictable).

j) There is a problem built into the UAAG use of priorities and minimum
implementations.  The minimum implementation of a P1 checkpoint leaves a P2
problem.  The minimum implementation of a P2 checkpoint leaves a P3 problem.

k) Providing a forward-only, step-to-next [child of same parent] would
remove the P2 level problem here.  Or at least that is my rough guess of
the usability prognosis.  As Charles has noted, this is not the structural
navigation one would want, but there is not a P2 severity access barrier if
that desirable function is missing.  Something along these lines is
required to fulfil the agreement with GL.  This is one version of a
possible minimum implementation, but as noted above it fails to touch the
many pages that are not AAA per WCAG.


l) A more direct approach is to tie 7.6 more closely to 8.4 where to
implement 8.4 the user agent has to make some decision or other about the
table of contents extraction -- what to include and what not to.

m) in HTML itself, I still recommend that the analysis of element types be
informative, moved to 8.,; and that it be graded.  

Here is a rough stratification of the list into categories of descending
usual criticality for structural navigation:

i) Clear structural role, used a lot to convey critical structure:

FRAME, FORM, TABLE

Note: this could possibly be limited to the outer TABLE in a nest.  If
treated thus, the interior TABLEs move to category (c) below.

ii) Clear structural role, and when used, probably indicate important
structure:

MAP, DIV, (the virtual DIVs associated with H1-H6), FIELDSET, THEAD, TFOOT,
TBODY

iii) Clear structural role, structured navigation less critical than the
above:

OPTGROUP, OL, DL, UL, (the virtual DIV comprising one DT and its associated
DDs)

iv) weak grouping function: P, DD, LI

v) Important atomic entries, no particular structural function: A, BUTTON,
TEXTAREA, INPUT, IMAGE (sometimes), OBJECT  

vi) Structurally unimportant atomic elements: ADDRESS, DT

If you cover a) and b) above, you should pass at P2 level (merit AA).  The
rest should not be required for a P2 checkpoint (makes browsing useless for
some group).

Add c) and d) together with level-of-criticality filtering at intermediate
levels of navigation [c.f. guideline 8] you pass at P3 level (merit AAA)

n) It would be clearer if we change "important structural elements," which
comes across as "important _and_ structural elements," given the list, to
"structurally important grouping elements" in the text of the checkpoint.


o) The implementation of hierarchy in 7.6 and 8.4 includes the following:
In deciding which starting points to include in the effective table of
contents slash navigation, it is appropriate for well-labeled
structurally-significant containers to hide significant starting points
within them for the purposes of extracting a summary view.  The
availability of such a mnemonic superstructure is a factor in deciding the
show/hide property of an element in the extraction of the effective
structure presented to the user.

p) In addition to the fundamental ergonomic consideration of how the
effective navigation tree divides up the time-to-speak of the contents, the
following heuristic hack would also probably produce useful information:

Divide the graphic canvas of the page into five equal-area parts.  One
full-width rectangle across the top, another full-width across the bottom,
and the remaining three areas being three columns running from the bottom
of the top rectangle to the top of the bottom rectangle.

In the Table of Navigation pruning, give consideration to obtaining
representation for syntactic slash DOM elements contributing content to as
many of these regions as possible.

End of screed.

Al


>
>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 10:28:08 UTC