where is this going? to accessible intrapage structural navigation [was: Re[2]: request for sample page structure analyses]

At 3:06 PM +0100 10/26/04, Pawson, David wrote:
>     >Tell me where this is going please?


** short

We are seeking a solution that will deliver structural intra-page navigation,
and page parts that both

- convey enough information to enable effective structural navigation
.. and
- authors can readily learn, will recall, and will use correctly for 
the most part.

The page structure that is "plain to the viewer" is a fine starting place
but not a fit ending place in that pursuit.

We are not going to agree on a dictionary of *canonical* page parts until:

a) the part types have definitions: diagnostic collections of characteristics
.. and
b) the collection of part types has been reviewed for its contribution to
  structural intra-page navigation.

If that is not where you thought we were going, please explain the 
accessibility
benefit of the alternative.  Author dialog to review and adjust the navigable
structure of the page is [highly productive?  necessary for practical 
purposes?]
for the achievement of widespread usable intrapage navigation.  And 
an effective
catalog of page part types, sensitive to both access and design issues, would
appear to be a strong technology asset in this regard.  Doing 
anything else with
standard part names would

a) constitute a missed opportunity
,, and
b) raise barriers to later introduction of what we need

** long

A capsule description of the process is at
http://www.w3.org/2004/06/DI-MCA-WS/presentations/120920/text6.html

although you may want to do the whole presentation to get the context.

Our objective is a pattern of practice of creating and walking a 
"full container model"
such as called for in the XAG [1].

The process of an author creating the structure involves both visual
design and interactive dialog to fit the navigable structure terms
and any missing orientation properties to the design.

The process of the user walking the structure is performed in a
variety of ways that are under the user's configuration control.

For page parts, however, most of the requirements can be seen from the
use case of hierarchical navigation using a DAISY-book like binding 
of the cursor
quad.

 From "part types we can see" we want to go to part types the authoring
tool can see, so as to query the author to confirm or deny the navigable
structure that the authoring tool suggests.  And the result of this
interactive dialog should be a structure *marked* in the document which
supports efficient and effective navigation under a short list of different
navigation styles.

So for all candidate part types, we need to identify:

distinguishing characteristics that we can see.

correlated characteristics that the UA, AT, or Authoring Tool can data-mine.

characteristics that distinguish a good navigable structure from a bad one.

Then we can consider what subset of the part ontology thus framed
should be enshrined in WAI and in XHTML2 -defined terms, in the various UA
navigation methods, and in the AU author dialogs.

Al

[1] http://www.w3.org/TR/xag#cp2_5

The injunction to provide "chunks of reasonable size" motivates
my venture into link count and time-to-speak.

But in fact it is not enough for the sizes of the chunks to be well
balanced.  The chunks have to have recognizable (by the UA) and
effective (for the user) orientation properties.  Automatic extraction
of a Table of Navigation should result in a highly effective product.


>    
>     Where it's going is "what does it take to provide an
>     accessible structure?"
>    
>     What the author was thinking, as indicated by what the page
>     looks like, is one obvious place to start.
>+1. Identified by some sort of vocabulary, not a verbal description?
>That was the intent as I took it.
>
>
>     What it looks like may not be enough structure.  But it's
>     where to start, for sure.
>
>Not intended to be a structure, I thought we were to start
>with agreeing a vocabulary? Then move on from there?

Not so fast. _Start_ by drafting a vocabulary from visual
appearance... But not end agreeing on it from visual appearance
alone. We shouldn't agree on the vocabulary without assessing if the
vocabulary makes about the right balance of increased burden on
authors and reduced burden on PWD web wanderers. The reduced PWD
burden is achieved through its contribution to structural navigation
inside web pages.

There is no accessibility need for a vocabulary
without that vocabulary being selected for its contribution
to intra-page navigation.

The breadth and depth of the vocabulary is a design choice
in the structural-navigation solution.

The dictionary of page parts starts with what is obvious
from looking at, but has to migrate to

- capture enough of what makes structural nav work well or badly
so the pages that do what we say are usable via structural nav

- is still close enough to the graphical design so that a brief
interactive dialog in authoring will get from the author's graphic
design to a *marked* structure that works in a variety of nav modes.

>     But we don't want to stop short of an accessible structure.
>
>What do you mean by structure.

I exemplified that in my narrative explanations of the two campaign sites.

I mean there is an abstract graph [often tree] of parts that a) the UA can
extract by algorithm and b) the user can navigate by next, previous,
down, up and efficiently perceive what parts they
want to skip and what parts they want to explore in depth.

For the user to know if they want to skip or explore a part, we
shouldn't rely on the types of the parts alone. There may be multiple
parts of the same type. The orientation for navigation should
distinguish these. But it can draw on headers and other
instance-specific labeling and content mining in the document to
achieve this.

it takes
a combination of typology and part-instance-specific labeling.  We
don't have to make the type system contain enough find distinctions
to make the part-orientation (virtual 'table of navigation' entry)
distinguish this part from the other parts around it.  We can rely
on headers and other labels for some of this.

In tree regions, up and down are parent and firstChild, respectively.

In table regions up and down are previousRow, subsequentRow steps
which keep the column position constant.


>I'm thoroughly confused now.
>
>
>
>regards DaveP
>
>--
>DISCLAIMER:
>
>NOTICE: The information contained in this email and any attachments is
>confidential and may be privileged.  If you are not the intended
>recipient you should not use, disclose, distribute or copy any of the
>content of it or of any attachment; you are requested to notify the
>sender immediately of your receipt of the email and then to delete it
>and any attachments from your system.
>
>RNIB endeavours to ensure that emails and any attachments generated by
>its staff are free from viruses or other contaminants.  However, it
>cannot accept any responsibility for any  such which are transmitted.
>We therefore recommend you scan all attachments.
>
>Please note that the statements and views expressed in this email and
>any attachments are those of the author and do not necessarily represent
>those of RNIB.
>
>RNIB Registered Charity Number: 226227
>
>Website: http://www.rnib.org.uk

Received on Monday, 8 November 2004 15:22:52 UTC