E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 41 (In chronological order)

From: Greg Gamble
Date: Fri, Mar 07 2014 5:03PM
Subject: Multiple H1 tags in an HTML5 web page
No previous message | Next message →

The HTML5 Section tag has the ability to "Reset the headers" of a page, which allows the use of multiple H1 tags.

With this in mind, how is an AT user going to handle this? Will they have any problems traversing the page?




Greg

From: Jared Smith
Date: Fri, Mar 07 2014 6:30PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

In theory, if the sectioning elements are structured correctly, the
outline presented to the end user will automatically adjust to ensure
a (supposedly) correct heading structure, so multiple H1s would be
acceptable. Of course this assumes that everything is done correctly
and that the algorithm properly reflects the intended structure. And
there is no present day support for the outlining algorithm anyway.
And there's a good chance this algorithm may change or be dropped from
HTML5 entirely.

As such, I would strongly urge the continued use of proper heading
structure as has always been recommended.

Jared Smith
WebAIM.org

From: Duff Johnson
Date: Fri, Mar 07 2014 6:59PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

> In theory, if the sectioning elements are structured correctly, the
> outline presented to the end user will automatically adjust to ensure
> a (supposedly) correct heading structure, so multiple H1s would be
> acceptable. Of course this assumes that everything is done correctly
> and that the algorithm properly reflects the intended structure.

You make it sound as if this is all very unlikely. Is that fair? I have no opinion; I'm just wondering why you feel the way you do. You aren't known for casual statements, Jared. :-)

> And
> there is no present day support for the outlining algorithm anyway.
> And there's a good chance this algorithm may change or be dropped from
> HTML5 entirely.

Fascinating. How would one track this question?

Also, if it was dropped from HTML5 how would that affect EPUB3?

> As such, I would strongly urge the continued use of proper heading
> structure as has always been recommended.

Just to be clear: you are referring to HTML 4.01, which specifies <H1> - <H6>, right?

So, if the author needs to go deeper (H7, H8…) - which was actually the point of Greg's question - you are saying they out of luck?

Duff Johnson

p +1.617.283.4226
e = EMAIL ADDRESS REMOVED =
w http://duff-johnson.com
l http://www.linkedin.com/in/duffjohnson/

From: Jared Smith
Date: Fri, Mar 07 2014 7:37PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Duff Johnson wrote:
>> Of course this assumes that everything is done correctly
>> and that the algorithm properly reflects the intended structure.
> You make it sound as if this is all very unlikely. Is that fair?

Considering the general abuse and mis-use of HTML5 sectioning elements
(particularly <section>), I have seen very few instances where if the
HTML5 outlining algorithm were applied it would result in improved
accessibility.

>> And there's a good chance this algorithm may change or be dropped from
>> HTML5 entirely.
>
> Fascinating. How would one track this question?
>
> Also, if it was dropped from HTML5 how would that affect EPUB3?

These are better questions for Steve Faulkner or others. I know that
due to very limited implementations there has been some rumors of
changing or dropping it.

> Just to be clear: you are referring to HTML 4.01, which specifies <H1> - <H6>, right?

Yes.

> So, if the author needs to go deeper (H7, H8...) - which was actually the point of Greg's question - you are saying they out of luck?

The answer to that question would be "yes". Greg was, I believe,
instead referring to the fact that you could give each sectioning
element its own independent heading structure beginning with an <h1>
(or really any heading level for that fact) and the outline presented
to the user would be 'reset' and adjusted to reflect a proper outline
regardless of the heading levels actually used in markup. If fact, you
could use <h1> for EVERY heading and just wrap each section in
appropriately nested <section> elements - and this would result in a
proper outline for the document, assuming the outlining mechanisms
were actually implemented, which they presently are not.

Here's a slide I've used that demonstrates that the heading levels
used wouldn't really matter that much if the outlining mechanisms
actually worked -
http://webaim.org/presentations/2013/ariahtml5/sectionarticle3

Jared

From: Steve Faulkner
Date: Sat, Mar 08 2014 2:02AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Hi all,

Jared is correct. There are no implementations of the outline algorithm in
browsers or other user agents and there is unlikely to be as there is no
requirements on user agents to implement it. There are a few 3rd party
implementations in JavaScript (demos) and one in XSLT in ePub. (this is
used to produce a table of contents for a book).

It will probably not be dropped from the spec as features are dropped when
they have implementation requirements but no implementations, this is not
the case for the outline algorithm (there are no requirements).

There are requirements on user agents to map heading levels in acc APIs
based on the headings outline depth
http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics

These have not been implemented because they rely on the outline algorithm
being implemented (which is not a requirement and browser vendors have
shown no intention to implement) I am in the process of talking with
browser acc implementers to drop these requirements from the html spec.

this article may be helpful
http://blog.paciellogroup.com/2013/10/html5-document-outline/

The advice in the HTML
specification<http://www.w3.org/html/wg/drafts/html/master/sections.html#headings-and-sections>;is
clear on this:

Sections may contain headings of any rank, and authors are strongly
encouraged to use headings of the appropriate rank for the section's
nesting level.


ePub also advocates use of correct heading levels
http://www.idpf.org/accessibility/guidelines/content/xhtml/headings.php



--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 8 March 2014 02:37, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> Duff Johnson wrote:
> >> Of course this assumes that everything is done correctly
> >> and that the algorithm properly reflects the intended structure.
> > You make it sound as if this is all very unlikely. Is that fair?
>
> Considering the general abuse and mis-use of HTML5 sectioning elements
> (particularly <section>), I have seen very few instances where if the
> HTML5 outlining algorithm were applied it would result in improved
> accessibility.
>
> >> And there's a good chance this algorithm may change or be dropped from
> >> HTML5 entirely.
> >
> > Fascinating. How would one track this question?
> >
> > Also, if it was dropped from HTML5 how would that affect EPUB3?
>
> These are better questions for Steve Faulkner or others. I know that
> due to very limited implementations there has been some rumors of
> changing or dropping it.
>
> > Just to be clear: you are referring to HTML 4.01, which specifies <H1> -
> <H6>, right?
>
> Yes.
>
> > So, if the author needs to go deeper (H7, H8...) - which was actually
> the point of Greg's question - you are saying they out of luck?
>
> The answer to that question would be "yes". Greg was, I believe,
> instead referring to the fact that you could give each sectioning
> element its own independent heading structure beginning with an <h1>
> (or really any heading level for that fact) and the outline presented
> to the user would be 'reset' and adjusted to reflect a proper outline
> regardless of the heading levels actually used in markup. If fact, you
> could use <h1> for EVERY heading and just wrap each section in
> appropriately nested <section> elements - and this would result in a
> proper outline for the document, assuming the outlining mechanisms
> were actually implemented, which they presently are not.
>
> Here's a slide I've used that demonstrates that the heading levels
> used wouldn't really matter that much if the outlining mechanisms
> actually worked -
> http://webaim.org/presentations/2013/ariahtml5/sectionarticle3
>
> Jared
> > > >

From: Steve Faulkner
Date: Sat, Mar 08 2014 2:04AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

this current discussion on the public HTML mailing list is relevant:
http://lists.w3.org/Archives/Public/public-html/2014Mar/0000.html

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 8 March 2014 09:02, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:

> Hi all,
>
> Jared is correct. There are no implementations of the outline algorithm in
> browsers or other user agents and there is unlikely to be as there is no
> requirements on user agents to implement it. There are a few 3rd party
> implementations in JavaScript (demos) and one in XSLT in ePub. (this is
> used to produce a table of contents for a book).
>
> It will probably not be dropped from the spec as features are dropped when
> they have implementation requirements but no implementations, this is not
> the case for the outline algorithm (there are no requirements).
>
> There are requirements on user agents to map heading levels in acc APIs
> based on the headings outline depth
> http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics
>
> These have not been implemented because they rely on the outline algorithm
> being implemented (which is not a requirement and browser vendors have
> shown no intention to implement) I am in the process of talking with
> browser acc implementers to drop these requirements from the html spec.
>
> this article may be helpful
> http://blog.paciellogroup.com/2013/10/html5-document-outline/
>
> The advice in the HTML specification<http://www.w3.org/html/wg/drafts/html/master/sections.html#headings-and-sections>;is clear on this:
>
> Sections may contain headings of any rank, and authors are strongly
> encouraged to use headings of the appropriate rank for the section's
> nesting level.
>
>
> ePub also advocates use of correct heading levels
> http://www.idpf.org/accessibility/guidelines/content/xhtml/headings.php
>
>
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>
>
> On 8 March 2014 02:37, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Duff Johnson wrote:
>> >> Of course this assumes that everything is done correctly
>> >> and that the algorithm properly reflects the intended structure.
>> > You make it sound as if this is all very unlikely. Is that fair?
>>
>> Considering the general abuse and mis-use of HTML5 sectioning elements
>> (particularly <section>), I have seen very few instances where if the
>> HTML5 outlining algorithm were applied it would result in improved
>> accessibility.
>>
>> >> And there's a good chance this algorithm may change or be dropped from
>> >> HTML5 entirely.
>> >
>> > Fascinating. How would one track this question?
>> >
>> > Also, if it was dropped from HTML5 how would that affect EPUB3?
>>
>> These are better questions for Steve Faulkner or others. I know that
>> due to very limited implementations there has been some rumors of
>> changing or dropping it.
>>
>> > Just to be clear: you are referring to HTML 4.01, which specifies <H1>
>> - <H6>, right?
>>
>> Yes.
>>
>> > So, if the author needs to go deeper (H7, H8...) - which was actually
>> the point of Greg's question - you are saying they out of luck?
>>
>> The answer to that question would be "yes". Greg was, I believe,
>> instead referring to the fact that you could give each sectioning
>> element its own independent heading structure beginning with an <h1>
>> (or really any heading level for that fact) and the outline presented
>> to the user would be 'reset' and adjusted to reflect a proper outline
>> regardless of the heading levels actually used in markup. If fact, you
>> could use <h1> for EVERY heading and just wrap each section in
>> appropriately nested <section> elements - and this would result in a
>> proper outline for the document, assuming the outlining mechanisms
>> were actually implemented, which they presently are not.
>>
>> Here's a slide I've used that demonstrates that the heading levels
>> used wouldn't really matter that much if the outlining mechanisms
>> actually worked -
>> http://webaim.org/presentations/2013/ariahtml5/sectionarticle3
>>
>> Jared
>> >> >> >>
>
>

From: Jukka K. Korpela
Date: Sun, Mar 09 2014 4:19AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

2014-03-08 3:59, Duff Johnson wrote:

> So, if the author needs to go deeper (H7, H8…) - which was actually
> the point of Greg's question - you are saying they out of luck?

I didn't read the question that way, but if that's the practical
problem, then the best you can do seems to be

<div class=h7 role=heading aria-level=7>...</div>

(naturally with some styling).

Yuccz

From: Greg Gamble
Date: Mon, Mar 10 2014 11:43AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Jared Smith Wrote:
" Greg was, I believe, instead referring to the fact that you could give each sectioning element its own independent heading structure beginning with an <h1> (or really any heading level for that fact) and the outline presented to the user would be 'reset' and adjusted to reflect a proper outline regardless of the heading levels actually used in markup."

Yep, that's what I was talking about ... so what's shown below would be valid mark up, but how would this be interpreted by a user using a screen reader. When I listen in NVDA "browse" mode and listen to the headings it works fine. What would a real user expect to hear? How would having multiple H1's be a problem? :

<!doctype html>
<html>
<head>
<meta charset='utf-8' />
<title>Multi H1 Test</title>
</head>
<body>

<h1>Top of page</h1>
<p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>

<section>
<h1>Some Section header text</h1>
<p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>

<h2>Secondary Header</h2>
<p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>

<h3>Third Header</h3>
<p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
</section>

<section>
<h1>Some Section header text</h1>
<p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>

<h2>Secondary Header</h2>
<p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
</section>

<h2>Main Page subheader</h2>

</body>
</html>

Found an interesting article too:
http://blog.adrianroselli.com/2013/12/the-truth-about-truth-about-multiple-h1.html


Greg

From: Lisa Snider
Date: Mon, Mar 10 2014 11:48AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Hi Greg,

You may have already seen this before, but I found it interesting to see
what screen reader users said (albeit a couple of years ago and pre HTML 5)
about multiple H1s:

http://webaim.org/projects/screenreadersurvey3/
under heading structures

Might apply?

Cheers

Lisa


2014-03-10 12:43 GMT-05:00 Greg Gamble < = EMAIL ADDRESS REMOVED = >:

> Jared Smith Wrote:
> " Greg was, I believe, instead referring to the fact that you could give
> each sectioning element its own independent heading structure beginning
> with an <h1> (or really any heading level for that fact) and the outline
> presented to the user would be 'reset' and adjusted to reflect a proper
> outline regardless of the heading levels actually used in markup."
>
> Yep, that's what I was talking about ... so what's shown below would be
> valid mark up, but how would this be interpreted by a user using a screen
> reader. When I listen in NVDA "browse" mode and listen to the headings it
> works fine. What would a real user expect to hear? How would having
> multiple H1's be a problem? :
>
> <!doctype html>
> <html>
> <head>
> <meta charset='utf-8' />
> <title>Multi H1 Test</title>
> </head>
> <body>
>
> <h1>Top of page</h1>
> <p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
> eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
>
> <section>
> <h1>Some Section header text</h1>
> <p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed
> do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
>
> <h2>Secondary Header</h2>
> <p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed
> do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
>
> <h3>Third Header</h3>
> <p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed
> do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
> </section>
>
> <section>
> <h1>Some Section header text</h1>
> <p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed
> do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
>
> <h2>Secondary Header</h2>
> <p> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed
> do eiusmod tempor incididunt ut labore et dolore magna aliqua</p>
> </section>
>
> <h2>Main Page subheader</h2>
>
> </body>
> </html>
>
> Found an interesting article too:
>
> http://blog.adrianroselli.com/2013/12/the-truth-about-truth-about-multiple-h1.html
>
>
> Greg
>
>
>


--
Lisa Snider
Electronic Records Archivist
Harry Ransom Center
The University of Texas at Austin
P.O. Box 7219
Austin, Texas 78713-7219
P: 512-232-4616
www.hrc.utexas.edu

From: Greg Gamble
Date: Mon, Mar 10 2014 12:05PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Lisa ... that's good to see. Those answers tell me that the use of multiple H1's is the way to go.

Thanks for the link.


Greg Gamble
SBCTC - Olympia | Information Services
p - 360-704-4376
 think before printing

From: Jared Smith
Date: Mon, Mar 10 2014 12:17PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Greg Gamble wrote:
> Those answers tell me that the use of multiple H1's is the way to go.

That's not how I would interpret the survey response. The survey asked
about having the site name/logo and the document title both be <h1>s.
Just 1/2 of respondents thought this optimal. This is quite different
from your scenario where each section has its own H1.

What you presented would be acceptable in HTML5, and would present an
appropriate outline if the outlining mechanism were implemented. But
because it's not, your heading structure is not optimal for most
documents. It's not "inaccessible", but most users expect one first
level heading for a document and sub-headings representing each
sub-section. Having <h1>s for each section could cause confusion.

Jared

From: Greg Gamble
Date: Mon, Mar 10 2014 1:04PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

I understand, but the numbers pointing to the use of a single H1 on a page as less desirable then having multiple H1's. The idea that a single H1 on a page is correct has changed with HTML5. And as you said, not all pages would need to do this and I get that, but a FAQ or Blog page would benefit from its use.

So adding them per the HTML5 spec seems to me the way to go, if it makes sense to do so.

Another survey with HTML5 markup and multiple H1's in sections would be interesting to read ...

Greg

From: Steve Faulkner
Date: Mon, Mar 10 2014 1:12PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

On 10 March 2014 19:04, Greg Gamble < = EMAIL ADDRESS REMOVED = > wrote:

> So adding them per the HTML5 spec seems to me the way to go, if it makes
> sense to do so.


Hi Greg,

As i pointed out previously the HTML5 spec strongly encourages using
headings as per their outline depth. It does not encourage authors to use
H1s to represent anything other than a H1, if that is unclear it is a bug
and needs to be fixed. Feel free to file a bug
https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=&product=HTML%20WG&component=HTML5%20spec



--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;

From: Jared Smith
Date: Mon, Mar 10 2014 1:23PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Greg Gamble wrote:
> I understand, but the numbers pointing to the use of a single H1 on a page as less desirable then having multiple H1's.

No, the data doesn't indicate this at all. It only indicates that 13%
more users prefer the site name/logo AND the document title as being
<h1>s, over just the document title.

> The idea that a single H1 on a page is correct has changed with HTML5.

No, not really. I refer back to Steve's quoting of the
recommendations: "Sections may contain headings of any rank, and
authors are strongly encouraged to use headings of the appropriate
rank for the section's nesting level."

> So adding them per the HTML5 spec seems to me the way to go, if it makes sense to do so.

It doesn't make sense, at least from an accessibility perspective. You
can present a heading structure that could cause confusion and that
relies on functionality that doesn't exist, or you can use a
properly-leveled heading structure that always has and always will
work. Assuming there is no barrier to you shifting the heading levels
appropriately, I can see no advantage to maintaining the structure
you've presented over properly-leveled headings.

> Another survey with HTML5 markup and multiple H1's in sections would be interesting to read ...

Yes, but only if the outlining mechanism is put in place and
supported. In the meantime, please refer to
http://webaim.org/projects/screenreadersurvey4/#levels which clearly
indicates a strong preference for properly-leveled headings.

Jared

From: Jukka K. Korpela
Date: Mon, Mar 10 2014 1:29PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

2014-03-10 21:12, Steve Faulkner wrote:

> As i pointed out previously the HTML5 spec strongly encourages using
> headings as per their outline depth.

I'm not sure I have quite followed the discussion, but at
http://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements
the W3C HTML5 CR presents two approaches, one using heading elements by
nesting depth and one using <h1> inside <section>, and adds: "Authors
might prefer the former style for its terseness, or the latter style for
its convenience in the face of heavy editing; which is best is purely an
issue of preferred authoring style." I cannot see this as encourageing,
even mildly, the use of the former approach (which is surely much more
practical).

> It does not encourage authors to use
> H1s to represent anything other than a H1, if that is unclear it is a bug
> and needs to be fixed.

Well, the question is what an H1 is. The old definition is simple and
understandable: it is a 1st level heading in a document. The HTML5
definition is less simple, but consistent as such: it is a 1st level
heading relative to something defined by HTML5

Personally, I don't like this modern style of speaking about "bugs".
Long ago, I learned that a bug was a software error or, more exactly,
failure to work by a specification. A specification, by this definition,
cannot have bugs; it can have inconsistencies or just something that
someone regards as wrong.

In this case, I don't think it's a matter of "bugs" in any useful sense.
People may disagree on what a specification should say. We can debate
over such things, rationally or irrationally, but it is confusing, and
probably an accessibility issue too, to cognitively challenged people at
least, to call differing opinions "bugs".

Yucca

From: Steve Faulkner
Date: Mon, Mar 10 2014 1:50PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 10 March 2014 19:29, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:

> 2014-03-10 21:12, Steve Faulkner wrote:
>
> As i pointed out previously the HTML5 spec strongly encourages using
>> headings as per their outline depth.
>>
>
> I'm not sure I have quite followed the discussion, but at
> http://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-
> h4,-h5,-and-h6-elements
> the W3C HTML5 CR presents two approaches, one using heading elements by
> nesting depth and one using <h1> inside <section>, and adds: "Authors might
> prefer the former style for its terseness, or the latter style for its
> convenience in the face of heavy editing; which is best is purely an issue
> of preferred authoring style." I cannot see this as encourageing, even
> mildly, the use of the former approach (which is surely much more
> practical).


thanks for pointing this out, it needs to be reworked I have filed a bug
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24992


>
>
> It does not encourage authors to use
>> H1s to represent anything other than a H1, if that is unclear it is a bug
>> and needs to be fixed.
>>
>
> Well, the question is what an H1 is. The old definition is simple and
> understandable: it is a 1st level heading in a document. The HTML5
> definition is less simple, but consistent as such: it is a 1st level
> heading relative to something defined by HTML5
>
> Personally, I don't like this modern style of speaking about "bugs". Long
> ago, I learned that a bug was a software error or, more exactly, failure to
> work by a specification. A specification, by this definition, cannot have
> bugs; it can have inconsistencies or just something that someone regards as
> wrong.
>

this is a term the editors of the HTML (including myself) spec use refer to
aspects of the advice and requirements on implementers and authors in the
spec that are at issue.

>
> In this case, I don't think it's a matter of "bugs" in any useful sense.
> People may disagree on what a specification should say. We can debate over
> such things, rationally or irrationally, but it is confusing, and probably
> an accessibility issue too, to cognitively challenged people at least, to
> call differing opinions "bugs".
>

Call them whatever suits you, I call them bugs and file bugs on the issues,
when a resolution involves a change in what the specification advises or
requires i consider that a bug has been resolved.

>
> Yucca
>
>
>
> > > >

From: Chagnon | PubCom
Date: Mon, Mar 10 2014 2:02PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

"you can use a properly-leveled heading structure that always has and always
will work."

Interesting discussion, but there's one factor that yet hasn't been
mentioned.

What kind of document are you discussing? An entire webpage? One story on a
webpage? A Word document? A magazine? Or what?

If this is a webpage with multiple stories on it, like a portal webpage for
a newspaper, our testers have requested that each story get its own H1 tag.
The stories are independent from each other on different unrelated topics.
They have nothing in common other than that they are news at that point in
time. In an hour, the webpage's structure will change.

If this is a document (Word or PDF) with sidebars, or a webpage with
sidebars, sometimes it's not so easy to wrangle everything into a strict
hierarchical heading structure. Some sidebars are directly related to the
main story, so they're pretty easy to fit into the structure as <H2> or
<H3>. But other sidebars are not so clearly related to the main story.

What if the sidebar is only remotely related to the main story? An <H2> tag
gives the connotation that it's more directly related than it really is. Or
what if the publisher just wants to include another topic on the page, as in
"if you're reading Topic A, then you might be interested in Topic X in this
sidebar." Tagging it as part of the main hierarchy could be incorrect.

Most webpages and many document pages (like brochures, magazines, and
newspapers) have so many different pieces of content on them that don't fit
the hierarchy.

How do you propose handling heading structure and hierarchy in these common,
but complex, situations?

-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2014 - www.Workshop.Pubcom.com

From: Greg Gamble
Date: Mon, Mar 10 2014 2:16PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Well, considering the cats already out of the bag ... If the relevant content in a section deserves an H1, as per the current specification (spec), how would this be a problem for a user?

All I've heard is that it's not correct. OK, fine ... but why is it not correct? And I'm not talking about a missing "outlining algorithm " or a unknown bug ... I'm talking about a user with current technology.

What difficulties, if any, would they have navigating a page? Is there anyone on this list, who is a user of AT , that can give me first hand knowledge?

I try to create pages that work for all users, and that includes users who are accessing my pages via AT. If doing something by a current spec causes problems for the majority of the users, I'm not going to follow that spec. Conversely, if a spec is deemed by some as incorrect, but works ... I'm going to use it.

Just trying to do what's right for my end users.

Greg

From: Jukka K. Korpela
Date: Mon, Mar 10 2014 2:32PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

2014-03-10 22:16, Greg Gamble wrote:

> Well, considering the cats already out of the bag ... If the relevant
> content in a section deserves an H1, as per the current specification
> (spec), how would this be a problem for a user?

Deserves in which sense? Just because it is a top-level heading in the
context of a section does not mean it "deserves" to be H1. Over the
centuries, such headings have been regarded as 2nd, 3rd, etc., level
headings, according to the nesting og sections.

> I'm talking about a user with current technology.

Almost all current user agents deal with an H1 element as the top-level
heading of the page. Any claims to the contrary need hard evidence, as
this has been the meaning and treatment of H1 since the early days of
the web.

Yucca

From: Greg Gamble
Date: Mon, Mar 10 2014 2:53PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

What about a blog page? A page with several different stories or unrelated articles?

Doesn't a blog entry deserve an H1, if it's in an appropriate <article> or <section> element?

Same for a page with multiple stories or articles.

And I'm questioning only HTML5 pages. I don't see this issue with non HTML5 pages, where the document outline is top down with no resetting.


Greg

From: Jared Smith
Date: Mon, Mar 10 2014 2:59PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Greg Gamble wrote:

> If the relevant content in a section deserves an H1, as per the current specification (spec), how would this be a problem for a user?
> What difficulties, if any, would they have navigating a page?

Really what you're asking is, "Do heading levels matter?" I argue that
they do. And our survey results strongly support this.

When visually browsing a page, the biggest, boldest heading (an <h1>)
typically indicates the document title. The next-smaller headings
(typically <h2>s) indicate the major document sections. Visually, one
can quickly scan the document to determine what the document as a
whole is about and what the major document sections are.

If the main document heading and each section's headings visually
appeared identical, it would suggest that the document heading and the
section headings are equal/parallel in meaning and importance. How
would one know that a document title applies to the document as a
whole as opposed to only the text immediately below it if it appears
exactly the same as all sub-headings? Of course one can easily address
this visual issue with CSS (just make section H1s smaller). Not so for
screen reader users.

By using <h1>s for each section, you are semantically stating to
screen reader users that the sub-sections are equal to and parallel to
the document title. This is just not correct. Now if the outlining
mechanisms worked, the browser would appropriately present the section
H1s as second level headings. But it doesn't work. There is no
difference in how a heading structure would be presented in an
HTML4/XHTML document headings and in an HTML5 document with sectioning
elements (excepting that one version of JAWS that tried and failed
miserably to implement the outlining mechanism). So at present, using
<h1>s everywhere results in an incorrect document structure as
presented to screen reader users regardless of the flavor of HMTL
used.

You asked how this impacts users...

It is a common strategy for screen reader users to quickly navigate to
the first <h1> in a document (typically by pressing the 1 key) to
quickly determine the document title. This almost always places focus
directly at the beginning of the main content area. They can also then
navigate the <h2>s in a document (typically by pressing the 2 key),
etc. to determine the major page sections and sub-sections.
Additionally, the user can open a list of the headings and can
navigate/filter those headings by level.

If H1s are used to begin each sub-section, this functionality becomes
much more difficult as they cannot differentiate document and section
headings (and potentially sub-section and sub-sub section). The
ability to quickly jump to the document title and beginning of the
main content is diminished. How can they know which of all the <h1>s
is the document title and which are section headings if they are
presented identically?

This can also impact users that use keyboard enhancement extensions or
voice control to navigate by headings. They would expect that headings
that appear smaller and below larger headings to be sub-headings, when
in your presented structure they would be parallel headings.

Also, search engines use heading levels to determine content
importance. An h1 is assumed to be the site or document title.
Multiple h1s could negatively impact search engine rankings.

So, there are several ways that users would be impacted by using this
approach. Can you name one way in which users would be benefited by
using your approach? I can't.

I apologize for the long response; I didn't have time to write a short reply.

Jared

From: Olaf Drümmer
Date: Mon, Mar 10 2014 3:19PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Sorry to get into just one aspect of this diuscussion but… :

Am 10 Mar 2014 um 21:59 schrieb Jared Smith < = EMAIL ADDRESS REMOVED = >:

> When visually browsing a page, the biggest, boldest heading (an <h1>)
> typically indicates the document title.

I always wondered what the Title tag in the HEAD element of an HTML document is for?

And: Why repeat the title in a first heading?

Furthermore: HTML pages are the only context where according to my observations one might expect the H1 or top level heading to be the one and only container for the HTML page's identification or overall description. In just about any other document - just think of books or magazines - there would be several or even many top level headings - and they tend to be listed in the table of contents (if one is present). I never saw the title of a document listed in its table of contents.

Olaf

From: Jennifer Sutton
Date: Mon, Mar 10 2014 3:25PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Greg:

I'm an screen reader user (since AT doesn't *always* mean screen
readers), so perhaps I'll pass your requirements and be deemed "credible."

Maybe users of other AT can also chime in, here.

In my view, what should be right for your end-users is to manage
their expectations. And it seems to me that if the outline algo.
hasn't been implemented, then no users would expect you to do
something like what it proposes.

Your users would expect you not to change things just for the sake of
a new spec, which (if I've followed the myriad of experts who've
responded already) is under reconsideration.

Just because you *can* have more than one h1, doesn't mean you should.

Yes, if you do that, I will be able to use the site, but you will not
be managing my expectations of how you are using levels, and I will
have to traverse the page via all headings (I do assume we're talking
about the Web) to get a sense of what you are trying to convey via
*multiple* h1s. Should I have to work that hard?

Maybe you can't help it if you've got some kind of CMS over which
you've got limited control, but that doesn't sound like that's your issue.

Headings convey meaning, and for as long as I've been using the Web
(maybe 1995 or so) and paying attention to Web standards (2000 or
so), we have been focusing on the notion of one h1 identifying the
most important (dare I introduce the idea of "main?") item on the
page, and then, the other headings following an outline-progression.

Now, I hope I've passed the audition.
<smile>

Jennifer

At 01:16 PM 3/10/2014, you wrote:
><snip>

What difficulties, if any, would they have navigating a page? Is
there anyone on this list, who is a user of AT , that can give me
first hand knowledge?

>I try to create pages that work for all users, and that includes
>users who are accessing my pages via AT. If doing something by a
>current spec causes problems for the majority of the users, I'm not
>going to follow that spec. Conversely, if a spec is deemed by some
>as incorrect, but works ... I'm going to use it.
>
>Just trying to do what's right for my end users.
>
>Greg

From: Duff Johnson
Date: Mon, Mar 10 2014 3:27PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

On Mar 10, 2014, at 4:59 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> Really what you're asking is, "Do heading levels matter?" I argue that
> they do. And our survey results strongly support this.

Yes! What a given piece of text "deserves" is *not* the issue. Document structure is the issue.

If headings are about "importance" then longer documents in HTML become an impossibility from the accessibility point of view because they are un-navigable, pure and simple.

<H1> is not about winning a popularity contest. It was defined as "importance" in HTML 4, but that was a flat-out error (from the accessibility point of view), one that's explicitly corrected in HTML 5.

I wrote a semi-decent blog post about this in 2012 while I was at NetCentric:

http://www.commonlook.com/The-Definition-of-Heading

Duff.

PS: PDF got this one right from the outset, as the blog-post explains.

From: Jennifer Sutton
Date: Mon, Mar 10 2014 3:41PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Oh, well. Based on Duff's response, I guess the idea of "important"
for the h1 isn't viable/has been corrected in HTML5 (though I wold
argue that sometimes, it does make sense to frame the issue this way
in everyday discussions, outside of "theoryland").


But I stand by my general ideas; just because you can, doesn't mean you should.

Jennifer



Duff wrote, in part:

<H1> is not about winning a popularity contest. It was defined as
"importance" in HTML 4, but that was a flat-out error (from the
accessibility point of view), one that's explicitly corrected in HTML 5.

From: Greg Gamble
Date: Mon, Mar 10 2014 3:47PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Jared ... your long response is much more appreciated then any short one would have been ;-)

But you mentioned h1 as the biggest and boldest. I can do the same with a span tag, but I get what you're saying ... I just don't see site structure/markup and site presentation as the same thing.

As for my being such a pain for you and Steve:

http://goo.gl/hAIJOR

Google SEO and Multiple H1's:
http://youtu.be/GIn5qJKU8VM

and lastly, but first a quote:
I would in fact prefer, instead of <h1>, <h2> etc for headings [those come from the AAP DTD] to have a nestable <section>..</section> element, and a generic <h>..</h> which at any level within the sections would produce the required level of heading.
- Tim Berners-Lee

http://goo.gl/rQlJb


This is what makes me question the validity of the old school? view of headings, pertaining to HTML5. As for the one way in which users would be benefited ... read a properly formatted HTML5 blog. I did with NVDA, and it made sense to me. But I don't rely on AT, so what I think works means very little.

Greg

From: Greg Gamble
Date: Mon, Mar 10 2014 3:51PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Jennifer ... Would you mind if I contacted you off list?


Greg Gamble
SBCTC - Olympia | Information Services
p - 360-704-4376
 think before printing

From: Duff Johnson
Date: Mon, Mar 10 2014 3:52PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

> Oh, well. Based on Duff's response, I guess the idea of "important" for the h1 isn't viable/has been corrected in HTML5 (though I wold argue that sometimes, it does make sense to frame the issue this way in everyday discussions, outside of "theoryland").

I just find it hard to read the respective specifications in any other way.

I will, of course, grant the desirability of an "importance" concept, but if that's what Headings are for then how can they *also* fill a "structure" role? It seems like an impossible burden.

Duff.

From: Chagnon | PubCom
Date: Mon, Mar 10 2014 4:07PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

The HTML <TITLE> tag was a nice thought, but wasn't implemented well circa
1990 and still isn't today.

From my experience, the only people who "see" it are those using screen
readers because it's voiced to them automatically.

For sighted users, the title tag appears in the browser bar, the colored bar
or thumb tab above the actual webpage which is totally overlooked and
ignored by sighted users. In other words, it's there but sighted users never
look at it. Instead their eyes are focused below all the top visual clutter
and are looking at the main web content on the page.

The <TITLE> tag is also used by search engines and is what appears in a
search engine results page (SERP), where everyone, sighted or not, sees it.

I have to go back and remember that in the 1990s, I was (and still am) a
technology specialist for publishing. It was traditional publishing then,
books, journals, newspapers and magazines, because the World Wide Web hadn't
yet been developed.

My kudos to Tim Berners Lee & Company who developed what we now know as the
Internet and the beginnings of HTML. But I often wonder if they had any
knowledge of publishing and communication protocols and requirements, or
were they just imaginative code jockeys and theoreticians who put this
together by the seat of their pants.

Every single piece of published information has a title. Or should have a
title. But it's not the <TITLE> tag they invented for HTML. Instead I have
to shoehorn my content into heading tags that often don't do the job well
enough, especially for people who are blind.

Example right now, this minute, from the website www.washingtonpost.com. How
would you tag this story? Note to those using screen readers, there are 5
pieces in this series of headings and teasers.

Opinions
Is this the proof Obama’s health-care law is working?
Greg Sargent
A new Gallup survey shows the number of uninsured falling again.
Samuelson: Obama’s new gamble

If I was designing the printed version of this in the newspaper, not the
website, the labels on these 5 pieces would be as follows:

Opinions (kicker heading or department heading)

Is this the proof Obama's health-care law is working? (Title of the first
story)

Greg Sargent (by-line)

A new Gallup survey shows the number of uninsured falling again. (Deck head,
which is a little summary or teaser between the main story title and the
actual narration of the story)

Samuelson: Obama's new gamble (another author by-line and another story
title, both on one line)

In print design, I have a bazillion ways to make each piece of information
distinctive and convey its hierarchy and purpose. My sighted readers will
understand all this in less than a second, point 8 seconds according to user
research.

But in HTML and accessibility, I have only <H1>, <H2> through <H6> heading
tags plus <P> tag to work with. How do I convey the meaning, purpose, and
hierarchy of these 5 pieces of information with such a limited tag set?

And right now, on the Washington Post homepage, there are dozens of
individual stories. What gets an <H1> tag?

And what do I do when I have a complex, compound title for a story, a main
title and a sub-title? What tags do I use?

It was a shame that the originators of HTML and the WWW didn't look use the
hundreds of years of publishing as their model for Internet information.
They went about an created a new wheel. To me, they invented a dysfunctional
half-assed wheel rather than taking the existing, functional wheel and
making it better.

We have a very long way to go before we can begin to provide equal access to
information for disabled users. This discussion about tags is just the tip
of the iceberg!

—Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com — Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2014 — www.Workshop.Pubcom.com

From: Duff Johnson
Date: Mon, Mar 10 2014 4:17PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Well said, Bevi!

> It was a shame that the originators of HTML and the WWW didn't look use the
> hundreds of years of publishing as their model for Internet information.

Ha! You mean, all that prehistoric print-era thinking! What did they know… :-)

> They went about an created a new wheel. To me, they invented a dysfunctional
> half-assed wheel rather than taking the existing, functional wheel and
> making it better.

From the perspective of the creators of the web nothing "existed" at all. They had to write software, and they wanted it to do something useful as soon as possible. Supporting all that stuff that printers and publishers were doing would have meant turning HTML into SGML… and HTML was invented more-or-less to get away from SGML!

> We have a very long way to go before we can begin to provide equal access to
> information for disabled users. This discussion about tags is just the tip
> of the iceberg!

That is for sure. :-(

Duff.

From: Jennifer Sutton
Date: Mon, Mar 10 2014 4:21PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

I (again speaking only as a screen reader user) really appreciate
title usage as it helps me stay oriented when I have several windows open.

I have found that it also helps in terms of bookmarking sites.

Jennifer

From: Chagnon | PubCom
Date: Mon, Mar 10 2014 6:26PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Duff wrote:
" From the perspective of the creators of the web nothing "existed" at all.
They had to write software, and they wanted it to do something useful as
soon as possible. Supporting all that stuff that printers and publishers
were doing would have meant turning HTML into SGML. and HTML was invented
more-or-less to get away from SGML! "

Yeh yeh yeh, those poor innocent college boys.

I know. SGML was and still is a bear. It's overkill. Like saying "here's the
dot on the lower case letter "i", that's in the word "idiotic", in the
sentence "this is idiotic nonsense", in the third paragraph of the second
section of the first article in the book ...
Some XML schemas and DTDs are like that, too.

I'd run away from it too, if I could! <grin>

But we could develop a happy medium between the ridiculously skimpy tag set
we now have for accessibility, and the anal-retentive nonsense of SGML and
some XML.

WebAIM is one group that could address this and get the problem fixed for
everyone. That would be a wonderful accomplishment for this group, wouldn't
it?

-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2014 - www.Workshop.Pubcom.com

From: Jared Smith
Date: Mon, Mar 10 2014 6:44PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Greg Gamble wrote:

> http://goo.gl/hAIJOR

This is an interesting article. One should read the comments
(especially Steve's).

I think what this boils down to is that there are often differences
between what HTML5 says you can do and what is optimal for
accessibility. Despite what HTML5 says you *can* do here (and again, I
note that it recommends AGAINST doing this), having h1s in each
section is not optimal for accessibility in the ways that have been
outlined.

> Google SEO and Multiple H1's:
> http://youtu.be/GIn5qJKU8VM

It's nice to hear this verified by Google. But I think most of what
Matt says backs up my opinion, not yours. Use headings where it makes
sense. A few <h1>s isn't going to break SEO and it won't make a page
"inaccessible". Using <h1>s for every section, however, would probably
be bad on both fronts.

> As for the one way in which users would be benefited ... read a properly formatted HTML5 blog.

Yes, in the case of a blog homepage where individual posts are
presented, having multiple h1s in sections (I'd argue that <article>
is better here) would be advantageous for the author so they don't
have to re-structure headings. But it isn't at all better for the end
user. Still, it may be a reality that one has to deal with. But in
this presentation, if you also used section h1s in your blog entries,
there would be at least 3 levels of <h1>s. This would truly be a
nightmare for any user hoping to decipher or navigate via the actual
heading structure of the blog homepage.

Jared

From: Jared Smith
Date: Mon, Mar 10 2014 6:53PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Chagnon | PubCom wrote:

> But we could develop a happy medium between the ridiculously skimpy tag set
> we now have for accessibility, and the anal-retentive nonsense of SGML and
> some XML.
>
> WebAIM is one group that could address this and get the problem fixed for
> everyone. That would be a wonderful accomplishment for this group, wouldn't
> it?

As wonderful as it would be, we're not really the right group to
address things like this - at least not alone. Work in the W3C (and a
few other groups) on HTML5+ (despite the several arguments in this
thread against some of its 'features') and other specifications is
where web standards should be defined and improved.

Screen readers already understand a fairly robust language for
accessibility, but HTML has a very limited accessibility vocabulary
for communicating with them. There is great work going on with ARIA
and with HTML5 to extend the available vocabulary to better match
those defined in accessibility APIs, and in extending those APIs so we
can communicate accessibility in more robust ways.

Jared

From: Chagnon | PubCom
Date: Mon, Mar 10 2014 8:33PM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Jared wrote: "As wonderful as it would be, we're not really the right group
to address things like this - at least not alone. Work in the W3C (and a few
other groups) on HTML5+ (despite the several arguments in this thread
against some of its 'features') and other specifications is where web
standards should be defined and improved."

And that's exactly where WebAIM should be working... with those who set the
standards.

Is WebAIM doing that? I haven't heard any discussion about it so I don't
know.

"There is great work going on with ARIA and with HTML5 to extend the
available vocabulary to better match those defined in accessibility APIs,
and in extending those APIs so we can communicate accessibility in more
robust ways."

Are there tools in Word or Office for creating an ARIA compliant document?
Does Acrobat have them?
Does Dreamweaver and other web authoring software have those tools?
How about Adobe InDesign and other EPUB authoring software?

Until those basic software programs - which are used to create probably 90%
of all documents and information - have tools to make ARIA-compliant
documents and websites, it will not meet the needs of people with
disabilities. At this time, ARIA requires hand programming. Given that the
US Federal government alone creates over one billion information documents
every day, it's impossible to have each of them hand-coded into compliance.

Don't misread what I'm saying: I'm pro-ARIA and think it will someday
provide a good solution for some obstacles. But I have not yet heard any of
the major companies and their software engineering teams even mention ARIA.

It will help when the WC3 finalizes a standard that could be implemented by
software manufacturers. Once that's done, it will take another 18-24 months
to have something in their software programs for users to use, and that's a
very pie-in-the-sky estimate.

But someone is going to have to push the software manufacturers to build
those tools into their software; they will not do that on their own accord.
WebAIM could be the one to "push" them.

-Bevi Chagnon

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2014 - www.Workshop.Pubcom.com

From: Joe Chidzik
Date: Tue, Mar 11 2014 3:48AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

> The HTML <TITLE> tag was a nice thought, but wasn't implemented well circa
> 1990 and still isn't today.
>
> From my experience, the only people who "see" it are those using screen readers
> because it's voiced to them automatically.

The <title> element is also used when any user bookmarks a webpage, as the default bookmark text. This is why it's useful to have not only the page title contained in the <title> element, but also the site title - it helps users when browsing through their bookmarks.

The <title> element is also used extensively by sighted users when using a tabbed browser; the title is what allows you to quickly switch between relevant tabs.

Joe

From: Steve Faulkner
Date: Tue, Mar 11 2014 3:52AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Hi Jukka,

the example you cited has been modified to align with best practice advice
elsewhere in the spec.
http://www.w3.org/html/wg/drafts/html/master/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements
this will flow through to HTML5 CR when it is next updated.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 10 March 2014 19:29, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:

> 2014-03-10 21:12, Steve Faulkner wrote:
>
> As i pointed out previously the HTML5 spec strongly encourages using
>> headings as per their outline depth.
>>
>
> I'm not sure I have quite followed the discussion, but at
> http://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-
> h4,-h5,-and-h6-elements
> the W3C HTML5 CR presents two approaches, one using heading elements by
> nesting depth and one using <h1> inside <section>, and adds: "Authors might
> prefer the former style for its terseness, or the latter style for its
> convenience in the face of heavy editing; which is best is purely an issue
> of preferred authoring style." I cannot see this as encourageing, even
> mildly, the use of the former approach (which is surely much more
> practical).
>
>
> It does not encourage authors to use
>> H1s to represent anything other than a H1, if that is unclear it is a bug
>> and needs to be fixed.
>>
>
> Well, the question is what an H1 is. The old definition is simple and
> understandable: it is a 1st level heading in a document. The HTML5
> definition is less simple, but consistent as such: it is a 1st level
> heading relative to something defined by HTML5
>
> Personally, I don't like this modern style of speaking about "bugs". Long
> ago, I learned that a bug was a software error or, more exactly, failure to
> work by a specification. A specification, by this definition, cannot have
> bugs; it can have inconsistencies or just something that someone regards as
> wrong.
>
> In this case, I don't think it's a matter of "bugs" in any useful sense.
> People may disagree on what a specification should say. We can debate over
> such things, rationally or irrationally, but it is confusing, and probably
> an accessibility issue too, to cognitively challenged people at least, to
> call differing opinions "bugs".
>
> Yucca
>
>
>
> > > >

From: Steve Faulkner
Date: Tue, Mar 11 2014 4:01AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

On 10 March 2014 21:47, Greg Gamble < = EMAIL ADDRESS REMOVED = > wrote:

> This is what makes me question the validity of the old school? view of
> headings, pertaining to HTML5. As for the one way in which users would be
> benefited ... read a properly formatted HTML5 blog. I did with NVDA,


NVDA like all other users agents provides a document outline based on the
numerical levels of the headings, so if the document used only h1 headings,
relying upon the the outline depth to infer level, the result would be a
flat outline..

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;

From: Jon Avila
Date: Tue, Mar 11 2014 5:29AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

[Bevi wrote] From my experience, the only people who "see" it are those using screen
readers because it's voiced to them automatically.

Titles are displayed in bookmarks and favorites as well as in shortcut titles on the desktop and home screen.

Jon

> On Mar 10, 2014, at 6:07 PM, "Chagnon | PubCom" < = EMAIL ADDRESS REMOVED = > wrote:
>
> From my experience, the only people who "see" it are those using screen
> readers because it's voiced to them automatically.

From: Steve Faulkner
Date: Tue, Mar 11 2014 5:32AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | Next message →

Right and without titles I would have no idea what the many page tabs I
have open in my browser are.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 11 March 2014 11:29, Jon Avila < = EMAIL ADDRESS REMOVED = > wrote:

> [Bevi wrote] From my experience, the only people who "see" it are those
> using screen
> readers because it's voiced to them automatically.
>
> Titles are displayed in bookmarks and favorites as well as in shortcut
> titles on the desktop and home screen.
>
> Jon
>
> > On Mar 10, 2014, at 6:07 PM, "Chagnon | PubCom" < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> > From my experience, the only people who "see" it are those using screen
> > readers because it's voiced to them automatically.
> > > >

From: Bourne, Sarah (ITD)
Date: Tue, Mar 11 2014 7:36AM
Subject: Re: Multiple H1 tags in an HTML5 web page
← Previous message | No next message

(Nostalgia alert!)

The first browser I used (Mosaic perhaps? So long ago...) displayed the TITLE below the address bar. That was a great feature, and I missed it for years after moving along to Netscape. It made it a lot easier to explain the importance of a unique, identifying TITLE to aspiring state agency webmasters. After that, I had to wait for their pages to be crawled by search engines to show them why they shouldn't use their site name as the TITLE on every page.

sb
Sarah E. Bourne
Director of Assistive Technology
Information Technology Division
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/itd