RE: Block level elements (navigate by)

The things we want to do seem to be these:

Navigate active elements.

By active elements I mean any with which some kind of interaction is
possible - links, form controls, elements which have associated event
triggers of some kind.

There is a checkpoint for this already.

The other thing we want to do is skip around 'chunks' of a document. One
way to do this is to navgiate the DOM tree. In well-formed HTML, this
means going through each heading, paragraph, list, form, table,
blockquote. (More or less - I'll deal with the exceptions shortly)

In a table, you could then go into rows, and from those into cells. In a
In a list, you could go down, and then across the list items.

FORMs and DIVs allow grouping of elements, so you could explicitly chuck a
document using DIV - within the DIV the same things apply.

Another way to do it is to use what I have referred to as a semantic tree
- a tree where an H1 is considered the parent of every element which is in
fact a sibling, until the next H1. H2, which becomes a child of an H1, is
then considered a parent of each of its newly restricted siblings up until
the next H2, and so on. This is the 'Outline' view from MSWord, or the
Table of Contents view from Amaya, and a bunch of document processing
tools.

Navigation of the DOM tree, while not a wonderful experience, does allow a
remarkable degree of power to the user. (It also allows access to
individual table cells - again not wonderful access, but access
nonetheless)

Navigating a semantic tree is an improvement on this. (Assuming that it is
possible to find out how the semantic tree is created)

In the current document I propose that we merge 6.2.2, 6.2.4 and 6.2.5,
and move the discussion of how to create a structured tree (other than
that provided by the DOM) to the techniques document.

I would like to raise the issue that navigation of such a structure tree
could be seen as navigation of a tree structure which is, or is an
'enriched' version of (and I am not at all happy with a definition that
loose, but it will do for an issue) the DOM tree, which could well become
a single requirement. However this may not be wise, and I don't want to
propose it yet.

Charles McCN

On Fri, 12 Mar 1999 thatch@us.ibm.com wrote:

  
  
  A big problem with assistive technology browsing (and screen readers too)
  is that there are too many commands, no one can remember them all. I cringe
  at every suggestion of yet another navigation method or yet another
  setting.
  
  IBM Home Page Reader has a read function. We also have table cell, table
  and heading jumps. But our (previous, current, next) structure jump is one
  that hasn't been mentioned here. "Next structure" jumps to the first text
  in a structure different from the current containg block. For this jump
  here are the  blocks we consider:  Lists, Maps, select menus, forms, table
  rows, other (body).
  
  While I am at it, I will mention the most useful suggestion I have seen for
  navigation with a speech (or braille) only browser. (This belongs in the
  content discussion.) "skip over navigation links" is a local anchor at the
  top of www.acb.org. The user hears it, follows that link, and is placed at
  the "important part" of the page. In our new site we are developing for IBM
  Special Needs Systems, we have that link associated with the top most
  decorative graphic with alt-text, "skip over navigation links."
  
  Jim Thatcher
  IBM Special Needs Systems
  www.ibm.com/sns
  thatch@us.ibm.com
  (512)838-0432
  
  
  
  "Denis Anson" <danson@miseri.edu> on 03/12/99 07:47:25 AM
  
  To:   "Al Gilman" <asgilman@iamdigex.net>, "WAI UA group"
        <w3c-wai-ua@w3.org>
  cc:    (bcc: James Thatcher/Austin/IBM)
  Subject:  RE: Block level elements (navigate by)
  
  
  
  
  
  Al,
  
  The "read" function is not part of the browser, but part of the AT.  No
  general purpose browser "reads" the page, but being able to move the point
  of regard (since many of the blocks don't take focus) to logical places is
  essential.  Beginnings of blocks are good, logical places to begin reading.
  
  Denis Anson, MS, OTR
  Assistant Professor
  Computer Access Specialist
  College Misericordia
  301 Lake Street
  Dallas, PA 18612
  
  RESNA
  The International Organization of Assistive Technology Professionals
  
  Member since 1989
  
  
  
  -----Original Message-----
  From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
  Behalf Of Al Gilman
  Sent: Thursday, March 11, 1999 8:54 AM
  To: WAI UA group
  Subject: Re: Block level elements (navigate by)
  
  
  
  I am confused.  Is there a "read forward from here" or equivalent command
  in the command repertoire as you see it?  I suspect I have been assuming
  the availability of such a function.  To me this is the function which gets
  to all the content.  Because this process can be too slow, we add
  requirements for navigation to get quickly to good starting points.
  
  Maybe we should call it "linear readout."  The way I ususally interpret
  "navigation," I would not call this linear readout activity navigation, but
  limit navigation to stepwise motion without reading.
  
  Al
  
  At 05:29 PM 3/10/99 -0600, Jon Gunderson wrote:
  >Thank you for your contribution to this section.
  >
  >I disagree though about removing the checkpoint.  I think we need a way
  for
  >users to navigate sequentially through each block of the document.
  >Especially naive users need a means to easily move through all the content
  >of the document.   I think this is a checkpiont for AT and its priority
  >should be raised to priority 1.  This complements the sequential active
  >element checkpoint.  If both these checkpoints are implemented the user
  has
  >a means with two keyboard commands to access all the active elements and
  >the contents of the document.
  >
  >Jon
  >
  >
  >
  >At 06:27 PM 3/9/99 -0500, Charles McCathieNevile wrote:
  >>I took an action to exmine the definition of Block-level elements in HTML
  >>4, and discovered that they are defined at
  >>http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.3 as
  >>
  >> 7.5.3 Block-level and inline elements
  >>
  >>   Certain HTML elements that may appear in BODY are said to be
  "block-level"
  >>   while others are "inline" (also known as "text level"). The
  distinction is
  >>   founded on several notions:
  >>
  >>   Content model
  >>          Generally, block-level elements may contain inline elements and
  >>          other block-level elements. Generally, inline elements may
  contain
  >>          only data and other inline elements. Inherent in this
  structural
  >>          distinction is the idea that block elements create "larger"
  >>          structures than inline elements.
  >>
  >>   Formatting
  >>          By default, block-level elements are formatted differently than
  >>          inline elements. Generally, block-level elements begin on new
  >lines,
  >>          inline elements do not. For information about white space, line
  >>          breaks, and block formatting, please consult the section on
  text.
  >>
  >>   Directionality
  >>          For technical reasons involving the [UNICODE] bidirectional
  text
  >>          algorithm, block-level and inline elements differ in how they
  >>          inherit directionality information. For details, see the
  section on
  >>          inheritance of text direction.
  >>
  >>   Style sheets provide the means to specify the rendering of arbitrary
  >>   elements, including whether an element is rendered as block or inline.
  In
  >>   some cases, such as an inline style for list elements, this may be
  >>   appropriate, but generally speaking, authors are discouraged from
  >>   overriding the conventional interpretation of HTML elements in this
  way.
  >>
  >>   The alteration of the traditional presentation idioms for block level
  and
  >>   inline elements also has an impact on the bidirectional text
  algorithm.
  >See
  >>   the section on the effect of style sheets on bidirectionality for more
  >>   information.
  >>
  >>In an appendix to the CSS2 entitled a sample style sheet for HTML 4 to
  >>following elements are given as block-level:
  >>
  >>ADDRESS, BLOCKQUOTE, BODY, DD, DIV, DL, DT, FIELDSET,
  >>FORM, FRAME, FRAMESET, H1, H2, H3, H4, H5, H6, IFRAME,
  >>NOSCRIPT, NOFRAMES, OBJECT, OL, P, UL, APPLET, CENTER,
  >>DIR, HR, MENU, PRE, LI, TABLE, TR, THEAD, TBODY, TFOOT,
  
  >>COL, COLGROUP, TD, TH, CAPTION
  >>
  >>from http://www.w3.org/TR/REC-CSS2/sample.html
  >>
  >>The context was the checkpoint "allow the user to navigate among block
  >>elements" (6.2.5 in the 9 march 1999 draft).
  >>
  >>My suggestion would be to remove this checkpoint since the required
  >>functions are already covered by other checkpoints in the same section.
  >>
  >>Charles McCN
  >>
  >>--Charles McCathieNevile            mailto:charles@w3.org
  >>phone: +1 617 258 0992   http://www.w3.org/People/Charles
  >>W3C Web Accessibility Initiative    http://www.w3.org/WAI
  >>MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
  >>
  >Jon Gunderson, Ph.D., ATP
  >Coordinator of Assistive Communication and Information Technology
  >Division of Rehabilitation - Education Services
  >University of Illinois at Urbana/Champaign
  >1207 S. Oak Street
  >Champaign, IL 61820
  >
  >Voice: 217-244-5870
  >Fax: 217-333-0248
  >E-mail: jongund@uiuc.edu
  >WWW:     http://www.staff.uiuc.edu/~jongund
  >    http://www.als.uiuc.edu/InfoTechAccess
  >
  
  
  
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Friday, 12 March 1999 19:06:27 UTC