RE: About tests 37-41 (headers)

Hello Jim,
  Yes a Web page may have different areas: navigation bar, side bar, main content etc. So that is kind of a structure for the Web content. Some designs remind me of frames at times. Within every area the headings should be hierarchical from h1 to h6. In the content section  for instance, there can be multiple h1 and they should signify  items at the same level.
  Another important issue is consistency in use of headings from page to page. Else it can be confusing for the user. In the sidebar for instance, one could use say h5 and h6 throughout the site. After all   content in the sidebar is meant to be secondary to the main content. 
   
  Sailesh Panchang
  Deque Systems 
  Reston, VA 20191
  sailesh.panchang@deque.com


Jim Thatcher <jim@jimthatcher.com> wrote:  
I don't know what Ben's Navigation bar example is, but I suspect it is
related to what I want to say. I believe that any restriction on allowed
order of heading tags is wrong and based on an old fashioned (linear) view
of a web page as a paper document. But web pages have many levels (areas) of
structure, Navigation bars, left or right navigation or advertising areas or
link areas, and, say, main content area(s). Different visually styled "area
headings" and "section headings" will/should appear in any and all of these
(perhaps in each area well structured). When you put these major sections
together, there is no requirement and no predicting how the last heading in
one area relates to the first in another area. With CSS positioning the
areas can be in any order. So I think it is reasonable to expect headings to
appear an any order what so ever.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Loretta Guarino Reid
Sent: Sunday, February 19, 2006 8:25 PM
To: Gregg Vanderheiden; 'Vicente Luque Centeno'; 'Chris Ridpath'
Cc: WCAG
Subject: Re: About tests 37-41 (headers)


I thought we came down against requiring strict application, based on Ben's
navigation bar example.


On 2/19/06 6:17 PM, "Gregg Vanderheiden" wrote:

> 
> Good work on codifying this.
> 
> There was a question though about whether this strict an application of
the
> headers was required by the success criterion or even by the HTML spec.
> 
> Does someone remember where we came down on this at the meeting?
> 
> Gregg
> 
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
> Professor - Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center
> University of Wisconsin-Madison
> The Player for my DSS sound file is at http://tinyurl.com/dho6b
> 
> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf
> Of Vicente Luque Centeno
> Sent: Sunday, February 19, 2006 6:23 PM
> To: Chris Ridpath
> Cc: w3c-wai-gl@w3.org
> Subject: About tests 37-41 (headers)
> 
> 
> Hi,
> 
> I have improved the formalization rules for headers. The following XPath
> expressions address all headers that skip a downward sequence, according
to
> tests 37-41.
> 
> For all of them (except for h1):
> 
> * The preceding header is calculated. If none, current header is badly
> placed.
> 
> * We take the closest preceding header to the current one (we get that
with
> the [1]).
> 
> * We check if that closest header is OK:
> H6's closest preceding header must be a h5 or h6.
> H5's closest preceding header must be a h4 or h5 or h6.
> H4's closest preceding header must be a h3 or h4 or h5 or h6.
> H3's closest preceding header must be a h2 or h3 or h4 or h5 or h6.
> H2's closest preceding header must be a any header.
> For all: otherwise, current header is badly placed.
> 
> Comments?
> 
> The rules are the following:
> 
> //h6[not(preceding::*[self::h1 or self::h2 or self::h3 or self::h4 or
> self::h5 or self::h6][1][self::h5 or self::h6])]
> 
> //h5[not(preceding::*[self::h1 or self::h2 or self::h3 or self::h4 or
> self::h5 or self::h6][1][self::h4 or self::h5 or self::h6])]
> 
> //h4[not(preceding::*[self::h1 or self::h2 or self::h3 or self::h4 or
> self::h5 or self::h6][1][self::h3 or self::h4 or self::h5 or self::h6])]
> 
> //h3[not(preceding::*[self::h1 or self::h2 or self::h3 or self::h4 or
> self::h5 or self::h6][1][self::h2 or self::h3 or self::h4 or self::h5 or
> self::h6])]
> 
> //h2[not(preceding::*[self::h1 or self::h2 or self::h3 or self::h4 or
> self::h5 or self::h6][1])]
> 
> //h1[not(true())] (which is //h1[false()], which is () )
> 
> Vicente Luque Centeno
> Dep. Ingeniería Telemática
> Universidad Carlos III de Madrid
> http://www.it.uc3m.es/vlc
> 
> On Thu, 16 Jun 2005, Vicente Luque Centeno wrote:
> 
>> 
>> All these examples also work with my rules :-)
>> 
>> On Wed, 15 Jun 2005, Chris Ridpath wrote:
>> 
>>> These tests are designed to detect when header levels are skipped in
>>> a downward sequence. For example:
>>> h1 followed by an h2 is OK
>>> h1 followed by an h3 is bad
>>> 
>>> Another example:
>>> h3 followed by an h4 is OK
>>> h3 followed by an h5 is bad
>>> 
>>> Header levels can be skipped in an upward sequence. For example:
>>> h4 followed by an h2 is OK
>>> 
>> 
>>> On Wed, 15 Jun 2005, Vicente Luque Centeno wrote:
>>>> Those h2 having no preceding h1 are an error:
>>>> 
>>> The group does not have a test for whether the first header in the
>>> document must be an h1.
>> 
>> Neither of my expressions say that explicitly. However, by proper
>> deduction and combination of my rules, you will implicitly obtain that
>> there is no other possibility. So, yes, the first header in the
>> document must be an h1 (or there should be no header at all) if tests
>> 37-41 should be followed. There is no explicit rule for that, but it
>> is derived from tests 37-41.
>> 
>>> There are no tests that check for multiple h1s in the same document.
>> 
>> That's why I did not include a rule saying:
>> 
>> count(//h1) <= 1
>> 
>> Cheers.
>> 
>> Vicente Luque Centeno
>> Dep. Ingeniería Telemática
>> Universidad Carlos III de Madrid
>> http://www.it.uc3m.es/vlc
>> 
>> 
> 
> 










		
---------------------------------
 Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.

Received on Wednesday, 22 February 2006 03:42:42 UTC