RE: Block level elements

At 08:36 AM 3/12/99 -0500, Denis Anson wrote:
>It's an implementation level thing, but I'd really like to see a browser set
>up so that you could have a "tab" to next interactive element, and a
>separate command that is "find the next thing like this."

I think that the Hn example shows that "like this" has to be interpreted
more as "at this level of significance or above" in terms of some assumed
pecking order for element types.  For example, one does not want to step
past an H2 going from H3 to next H3, and one does not wish to step to the
next form control if it is in a different FORM without stopping to
introduce the new context.

Maybe add back in explicit 'pop up a level' and you have a pretty good tree
walker.  The tree is an inferred tree based on the hypothesized
significance order of element types.  Better if one makes a pre-pass and
constructs virtual DIV elements that match the Hn usage first.

Al


>
>This would answer many of our checkpoints very nicely.  If you could set the
>point of regard to an control group (form), you could say "Find the next
>like this" to move to the next control group.  Likewise, a table with focus
>could find the next table.  But you could also find the next link, the next
>longdesc, the next JavaScript, or any other identified construct.
>
>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 Jon Gunderson
>Sent: Thursday, March 11, 1999 4:23 PM
>To: Charles McCathieNevile
>Cc: WAI UA group
>Subject: Re: Block level elements
>
>
>JRG response to CMN:
>6.2.3 (9 March 1999 WD) already states a feature for navigating the
>document tree, so it is already there.
>
>We need 6.2.2 since many users do not know what a document tree is and it
>provides a simple function for reading the entire content of the document.
>While it may be considered inefficient, it is also an easy on ramp to the
>WWW for new or less skilled users.
>
>No one checkpoint will solve all of a users needs.  We need both types of
>checkpoints.
>
>Jon
>
>
>At 03:18 PM 3/11/99 -0500, Charles McCathieNevile wrote:
>>I would prefer to rewrite 6.2.2, currently allow the user to view a
>>document outline so that is allowed navigation of the semantic document
>>tree structure - ie headers, paragraphs, lists, etc.
>>
>>I have assumed that this is primarily a concern for HTML and that
>>well-written XML schemata will not have the same split between the
>>semantic and the syntactic structures. Which could well be wrong.
>>
>>Charles McCN
>>
>>On Wed, 10 Mar 1999, 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
>>
>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 09:32:14 UTC