Re: [navigation] headers vs. nesting

al,

Have you considered assigning nomenclature to the headingss and then  
writing a style guuide for them?  Sometimes, in audio, we don't want  
speech for this value. we want to hear a bong or a tick followed by  
the information producing it.  In braille, there are myriad ways to  
presented nested information and as well visually, there might be  
something unique.  I for example can see asking for just the heading  
types with their associated info to be displayed something like an  
outline but flat.  In fact, I can do this with jaws, just list the  
headings, I can also listt certain heading levels.  In summary then,  
just pproviding the hierarchy and a guide should be enough?

On May 17, 2007, at 2:08 PM, Al Gilman wrote:

>
>
> ** Question: how to integrate levels explicit in html:h1 etc. with the
> nesting discovered from the parse tree, in creating a "best practice"
> Table of Contents for a page?
>
> ** Discussion:
>
> Authors will use HTML header elements and ARIA @aaa:labelledby
> in weird and wondrous ways, and AT won't be able to provide
> the highest and best structural navigation to their users unless we
> say something about how these two techniques combine.
>
> * Layout concept:
>
> I can imagine a visual or braille layout for a Table of Navigation (a
> jump-to-enabled Table of Contents) that is derived from both
> the containment relationships in the parse tree and the header
> levels in header elements that follows the following rules:
>
> Sub-elements are listed after and indented from their super-elements.
>
> The indenting is normalized so that all Hn levels used in the document
> correspond to vertically-aligned staring positions for the headers
> so marked up.  In fact, while not demanding exact metric equivalence
> in the horizontal indenting from H1 to H2, H2 to H3, etc, if the
> use in the page is gapped, such as using H1, H2, H3 and H5 without
> H4, the gap between H3 and H4 alignment lines should be extended
> to allude to the missing level.
>
> This means that there may be fractional indents for containers that
> don't have Hn elements that they are labelled by.  This could become
> a burden in Braille where one- and two-cell indents are the norm.
> Braille presentation might lose the distinction between an Hn and
> a section label hooked by @aaa:labelledby in its presentation effects.
>
> In any modality of styling, section labels that are not Hn elements  
> will have
> either more recessive text effects than the explicit Hn element  
> headers,
> or will be distinguished by a brief prefix category announcement.
>
> Missing indent levels may or may not be indicated by a stub or  
> minimized
> entry in the layout of the Table of Navigation.
>
> Author tools may bark at authors for this "improper" use of header
> levels, but User Agents should cope and extract a tree that is as
> close to what the author gave them as is practical, and affords a
> consistent frame of reference as the user moves around the page.
> Even if the UA has to make some arbitrary decisions in bashing the
> page into a navigable tree, it should do so because the user can
> remember how it was announced the last time they passed by this
> part of the page.
>
> * Voicing concept:
>
> Mostly, the effective section label needs to be voiced.  If the AT
> decides it wants a category name for the current container that has
> that label, it can announce "section labelled ..." or invent any other
> term it wants, but it should be different from the way it announces
> an H3, for example.
>
> ** Comments?
>
> Al
>

Received on Thursday, 17 May 2007 20:51:46 UTC