E-mail List Archives

Re: page should contain no more than two h1 elements


From: John Foliot
Date: Jun 16, 2009 12:15PM

Korpela Jukka wrote:
> >
> > Explanation: This appears to be generated by the Firefox Accessibility
> > Toolbar
> Thanks, I think this greatly helps us to evaluate that evaluator.
> > It is an excellent evaluator tool, and one
> > that I use often.
> Its other features must then be superb, to compensate for the absurd
> warning that has misled people so much (at least many people who have
> participated in this discussion).

Hello Jukka, long time no hear...

Yes, actually, it is a very useful toolbar as part of the overall "kit"
that I use. Yes, some of the 'warnings' are unusual, and I had at one
time a very spirited discussion with Jon Gunderson regarding some of the
warnings and failures being reported, but on balance, the functionality it
puts in my hands to both evaluate and also demonstrate (in the teaching
mode) some key concepts out-weigh the 'controversy' of some of the reports
- which I take with a serious grain of salt based upon my 10+ years doing
this stuff.

Features: the toolbar allows me to replicate the inter-page navigation
methods that screen-readers use to navigate: I can visually pull up a list
of links (allowing me to *show* link text out of context) - it also allows
for ordering these links as found in source-code order, or re-order
alphabetically (helps to quickly point out duplicate link text). It also
allows for visualizing a list of the page headings (the topic of this
thread), again in source-code order, or re-ordered by hierarchy (again
useful - and by clicking on any of those headings, it visually places a
visual border on that element in the page, again visually demonstrating
how headings are used for navigation). It also can display a list of
accesskeys (no comment - save that it can also 'disable' accesskeys), and
has a very useful ARIA Widget inspector. It has two 'built in'
alternative style sheets, and links to both W3C validators as well as WDG
- it also links directly to WAVE, FAE, Cynthia Says, and TAW. There are
also the standard image inspection functions (alt text, list of
abbreviations, disable images, etc), as well as some other keyboard
enhancement tools that I don't use. Oh, and it's free.

> > However, the 'warnings' noted by the tool are somewhat
> > subjective, and they represent the opinion of the toolbar creators.
> Being subjective is one thing, being absurd is another thing.

As web accessibility professionals who have been doing this for a very
long time, this type of guidance may indeed seem 'absurd', however, as a
general blanket statement it causes very little real harm, as it *is*
generally a best practices guidance - if nothing else it also started this
extremely useful thread where-by we've (hopefully) informed newer
practitioners of accessible web development of some key concepts that us
old guys take for granted. Given the plethora of "web accessibility
testing tools" out there, I can forgive it this small controversy.

> In the past, there have been many discussions on whether a document
> have exactly one (or at most one) h1 element. The expert consensus has
> been that normally a document should have one first-level heading, but
> there are exceptions, such as a bi- or multilingual edition of a
> (It is almost always best to present each language version as a separate
> document, but that's a different issue, and there are exceptions to that
> as well, such as scientific purposes and some documents for bilingual
> audiences.)

Right, so a warning that suggest that having multiple <h1>s is just that -
a warning. It says to the content author: go, double check, is this in
fact appropriate? Is there a better way? Does it make real sense? It
effectively says "use your brain here". I personally cannot see this as
anything but positive overall.

> So it would be OK to say that a document should normally have just one
> element, please check whether this is a justified exception.
> But the warning
> a) does not refer to any exceptions
> b) makes the upper limit arbitrarily _two_ and not one
> c) does not seem to refer to any reasons or arguments
> d) requires that h1 element content should "match" all or part of title
> element content; there is no ground for this justification - the content
> might be the same, or somewhat different, or completely different, as
> as both elements serve their purposes.
> (For example, the title element content should be understandable even
> without any context. There is no such requirement for h1.)

All good points, but more data-points that belong in a background
document, rather than a quick checklist of 'issues'. Any tool is simply
that, a tool. **LEARNING** how to use that tool is of course key, be it
this tool bar or any other tool.