[whatwg] Clarify how to indicate document hierarchy

Benjamin Hawkes-Lewis bhawkeslewis at googlemail.com
Mon Feb 12 06:10:55 PST 2007


Spartanicus wrote:
> You need to input something and post the result for that to work.

This is true. :) Let's try that again...

SimpleBits quiz: http://tinyurl.com/237rgp

and

SimpleBits quiz conclusion: http://tinyurl.com/3clao2

> IIRC no current AT AU facilitates navigating for example from one <h2> to the
> next <h2>, they only allow navigating to the next or previous header.

Even being able to skip from heading to heading is vast improvement, but
I'm delighted to say you're wrong about current AT capabilities. This
isn't a full survey but:

JAWS does:

http://www.freedomscientific.com/fs_products/JAWSkeystrokes.asp

Window-Eyes does:	

http://tinyurl.com/2d8m8j

And Fire Vox does:

http://www.firevox.clcworld.net/tutorial/tut1.html

As far as I can tell from the HAL manual, it lists headings and moves
between them, but does not distinguish levels:

http://www.dolphincomputeraccess.com/manuals/UKHalManual_MSWord_v701.zip

Thunder doesn't seem to skip or list headings:

http://www.screenreader.net/downloadlibrary/Screenreader%20Hotkeys.doc

It's simply not clear from the VoiceOver manual whether headings form
part of its HTML grouping algorithm:

http://www.apple.com/accessibility/voiceover/manual.html/

AFAIK neither Orca nor NVDA lists headings yet, but they're both still
in early development, so I suspect they will in the future.

> But IMO the real killer is the chicken and egg situation
> that very few pages have been marked up to facilitate useful header
> navigation. 

Seems to me a lot of pages uses header navigation. (Hixie will
presumably have some statistics on this.) 

> Consequently as a user you'd have to be something of a
> masochist to try and use header navigation whilst surfing.

A lot of web surfing is pretty masochistic (e.g. endless requests to
download Flash player cause no end of confusion to screen reader users,
judging by the various lists I subscribe to). Whether people actually
know about the features of their screen reader is another issue. The
existing studies of what people know and use are paltry at best, and
their results are somewhat ambiguous.

A 2003 study of 16 blind users revealed that found that most tried to
scan the page in various ways, but while a few used the headings
features many were unaware they existed:

http://www.redish.net/content/papers/interactions.htm

http://www.stcsig.org/usability/newsletter/0304-observing.html

(These links write up the same study, but with somewhat differently.)

A 2005 study of 8 screen reader users found that all participants said
headings for different levels of navigation were very useful:

http://www.usability.com.au/resources/ozewai2005/#section34

Peter Krantz studied screen reader users in 2005 and reported that the
list of headings was one of the most used features of JAWS:

http://www.standards-schmandards.com/2005/browsing-habits

> >WHATWG's specifications should establish clear guidelines about how
> >document hierarchy can be indicated.
> 
> Should a specification also be an authoring course? 

You mean should a specification indicate best practice or only required
practice? It should indicate both IMHO, and in many places both the
HTML4 specification and the WHATWG drafts do just that.

> This, combined with the fact that, as you noted, there are differing
> views on what constitutes best authoring practice is another argument
> that this is not something a specification should get involved with.

At least half the arguments involved are not useful discussions about
"what is good for users" but cul-de-sac debates about "what does the
HTML4 spec imply". I suggest cutting out the second half of the
arguments by making clear and reasoned suggestions. If this forces a
more clearly focused discussion of usability, all the better. :)

--
Benjamin Hawkes-Lewis




More information about the whatwg mailing list