Re: HTML 5 Authoring Guidelines Proposal the use of the section element and its potential impact on screen reader users

On Nov 27, 2007, at 14:41, Joshue O Connor wrote:

> First of all apologies to Michael as he did suggest we work on a local
> copy for contributing to the guidelines for authors document but I  
> would
> just like to raise (resurrect) something here.

(It is no longer called "guidelines" to steer clear of the  
implications of "guidelines".)

> According to the document the section element represents "a generic
> document or application section". [1]
>
> Ok, fine. but when I read the example:
>
> <body>
>  <h1>Top Level Heading</h1>
>  <section>
>    <h1>Second Level Heading</h1>
>    <section>
>      <h1>Third Level Heading</h1>
>    </section>
>  </section>
> </body
>
> My first though, is why would anyone want to do this?

It allows the author (or CMS) to aggregate and move stuff around  
without having to recompute heading levels.

> Also (I hope) authors still write the following and produce a  
> conformant
> HTML5 document?
>
> <body>
>  <h1>Top Level Heading</h1>
>  <p>Some content</p>
>    <h2>Second Level Heading</h2>
>    <p>Some content</p>
>    <h3>Third Level Heading</h3>
>  <p>Some content</p>
> </body>

Yes, the old way will still work and be allowed.

> when there is a disconnect between what the heading elements are  
> stating
> <h1> and what the contents of the elements are explicitly stating. For
> example, <h1>Second Level Heading</h1>,  <h1>Third Level Heading</h1>.

It is a bit ugly, but it's more backwards compatible with e.g.  
VoiceOver than <h>.

> Also has there been any consideration about how users of AT could be
> effected by this?

Until AT (or the UA depending on implementation details) is updated to  
be HTML5 outline algorithm-aware, the heading levels will be indicated  
wrong (tested with Safari/VoiceOver on Leopard) to the user in the  
<h1>/<section> case. This is still better than <h>/<section> scenario  
where headings aren't reported as headings at all by existing <h>- 
unaware software (VoiceOver again).

> For example, to follow on from the example above a
> valid conformant HTML5 document could have 10 <h1> elements embedded
> within the semantically neutral <section> element.

As James already pointed out, the point of <section> is that it is  
*not* neutral.

> It *may* not but it could. Apart from flying in the face of how  
> current
> HTML documents are written, this means that the screen reader user  
> when
> they use their page virtualisation controls, and extract the page
> headings, they will be presented with a list of 10 <h1> headings?

With current HTML5-unaware software, the extracted heading tree would  
be wrong but the headings still count as headings. With future HTML5  
outline algorithm-aware software, the heading tree would make sense.

> This does not confer a sense of hierarchy, or document structure to  
> the user
> at all and my concern is that this method of marking up a document  
> using
> the <section> element could engender bad authoring practices.

Some people believe that explicit sections and implied heading levels  
would be good for authoring once supported by clients. If no one saw  
value in the XHTML2 <h>/<section> model, we wouldn't see requests for  
it in HTML5 from time to time. (In fact, the idea is so popular that  
it still gets requested even though it's already in the spec--the  
element is just called <h1> instead of <h>. :-)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 27 November 2007 17:09:17 UTC