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

Joshue O Connor wrote:
> Hi Olaf,
>
> Dr. Olaf Hoffmann wrote:
> > 1. more semantical structure [...]
> > User agents can simply derive the hierarchical structure of the headings
> > (and their styling) from the hierarchical structure of section elements
> > automatically.
>
> Is this from their placing within the document? Does it happen by the UA
> counting the nodes in the DOM or similar?
>

This answered already Lachlan Hunt, it is mentioned in the working draft
how to derive an index.

> >If a screen reader or a viewer can make a difference
> > between h1 and h2, it should be possible too to count section levels
> > while reading/displaying it.
>
> Ok, but please clarify exactly how.

Well, I only tried once an audible presentation of text from a computer
in german (the native language I speak and understand), but I did not
understand a word, therefore I'm surely not familar, how screen reader 
give notes to the audience about the importance of a heading.
Even with a human reader (for example if someone read out a fairy
tale to children) I think there is no standard way, what to do, how to
style the presentation of hierachical structures. But if a reader has a
method to 'style' audible a difference between h1 and h2, it 
should be possible to count headings outside sections and 
sections nested in each other with heading to derive the numbering
as specified in the working draft. Then it is the same problem as
to style h1 and h2 differently in an aural stylesheet. 
If the document only uses section structures and no h2...h6,
I think, it is simple to create a default aural CSS stylesheet.
But if both systems are mixed, indeed, this gets more difficult,
but as far as I can see (from an author point of view) not
impossible.
And as we all know, this will happen, authors will not really care
much about the intentions of the authors of a specification or
about 'best practice',  therefore they will use h1-h6 inside and 
outside of nested section elements in an almost arbitrary 
combination. 
From this point of view of course it would be simpler for
implementors to separate the two methods either using
section+h or using h1-h6. Separation of different functionalities
is mostly a good idea to avoid more difficulties as necessary.
From the point of backwards compatibility it is an advantage
to have at least h1-h6 as known heading elements inside
section, but this is paid with more complex rules for
implementation.


...

>
> > 3. it is simpler to reuse content in different environments as done
> > very often for example with server sided scripting or with chapters
> > from different authors in one document or in anthologies.
>
> Yes. I can see how that could be very useful for content that is put
> together on the fly - print on demand publishing etc.
>
> > This is an advantage for users, because now the user agent can
> > derive the hierarchical structure, even if the author or the script
> > did not care about it, author or script have only to use sections
> > to get a sufficient structure in quite different environment without
> > changing the content of text fragments.
>
> Again, I would really like to know how before I can "trust" that this is
> the case. As I stated earlier I am trying to understand how this will
> work for users of AT. If there was a "Sections List" in the JAWS or
> other screen readers virtualisation features then this will be fine. For
> example the number of <section> elements could be listed (Indexed from
> 1) and then the document structure could be inferred and navigated by
> the user in a dialogue box but then this kind of feature will need to be
> implemented/supported by UA vendors. The <section> element would then
> take the place of numbered H tags and remove the load on authors to have
> to think about how their content could be structured. Also a real
> benefit of this method is for dynamically generated content documents
> can then be structured correctly on the fly by the UA reading how the
> DOM has been constructed or similar.
>
> However this is a little "Tomorrows world" at the moment, I guess.
>
> Josh

Well, HTML5 is today just a working draft. Looking at working drafts for
other formats (CSS, SVG, XHTML2) it may take some years going 
forward and backward between WDs and WDs and CR and so on, 
depending on comments to the drafts, until it gets a recommendations. 
And there are maybe even more interests on HTML as on CSS2.1, 
therefore probably many comments and conflicts to solve, before it 
becomes usable. 
Therefore there is still much time for implementors to care about 
new elements before a large amount of authors will really use it ;o) 
And larger parts of HTML5 are still very similar to HTML4, not a completely
new approach as XHTML2 is.

Received on Wednesday, 28 November 2007 10:58:14 UTC