RE: Block level elements (navigate by)

Granted it isn't tested, and granted that I don't know how to implement it
robustly, but I see, as a cognitively straight forward navigation model, the
"Find the next thing like this one" model.

A browser would allow moving by chunk as the basic navigation scheme.
Chunks would be defined dynamically by the user.  At the highest level, the
entire page would be a chunk.  If the user decided that the chunk seemed
interesting, then there would be a command to burrow into the chunk, into
sub-sets.  This might mean burrowing down to the H1 elements of the page,
and allowing the user to navigate by those.  When an interesting H1 element
is found, the user could burrow down into that.

The user would also have the option of "popping" up out of a chunk into it's
enclosing chunk, all the way to the top level.

From a programmatic view point, this might be the same as walking the
document tree, except that you don't have to know what a document tree is.
You just think that this sounds interesting, and render what is under it, or
skip over it to the next block.

From a markup point of view, this works fine for a lot of HTML, where
everything between a start tag and an end tag can be defined as a chunk.
However, headers, which are one of the logical divisions, don't actually
enclose their content.  For Headers and <P> chunks, you'd have to use an
algorithm that assumed that the next <hx> or <p> (<Hx> implies the same
level of header or higher) acts as the end of the chunking unit.

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: Friday, March 12, 1999 9:18 AM
To: WAI UA group
Subject: RE: Block level elements (navigate by)


At 08:47 AM 3/12/99 -0500, Denis Anson wrote:
>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.

A possible knock on "walk the BLOCK elements" is that it is untested.
Scott had a negative experience trying the "walk the tree" hypothesis with
users.  Is there objective user-testing experience with this strategy?

If this is effective for users, it could be viewed as competing for
programmer time with "walk the headers."  It has the advantage of
robustness over the latter.

Are we converging on a "walk the BLOCK element tree" checkpoint?  Just
stepping through the BLOCK element-starts is a depth-first walk of this
tree, no?

Al

Al
>
>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
>>
>

Received on Friday, 12 March 1999 10:03:54 UTC