<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Quick tips for accessible headings</title>
	<atom:link href="http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/</link>
	<description></description>
	<pubDate>Thu,  4 Dec 2008 21:06:39 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Henny</title>
		<link>http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/#comment-84731</link>
		<dc:creator>Henny</dc:creator>
		<pubDate>Mon, 07 Jul 2008 18:40:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.rnib.org.uk/wacblog/?p=199#comment-84731</guid>
		<description>Hi Folks,

Many thanks for your comments; questions raised have flagged some interesting points about the nitty gritty of applying headings which is great.  So without further ado I'll address these chronologically:

&lt;strong&gt;@Martin Kliehm&lt;/strong&gt;, Yes, the placement of an H1 in the code and hidden headings for navigation can be a tricky one and often needs to be thought about on a case by case basis. With regards to having the H1 appearing first in the code you could consider, where feasible, moving things around in the underlying HTML code so that the H1 heading comes first. Then you can use CSS to position things the way you want them visually. This will also solve the problem of having hidden headings for navigation coming before the H1 in the overall structure. Have a look at this page for example. Visually you see content in a traditional layout with the main navigation at the top, section navigation at the left-hand side and main body of content to the right of the section navigation and under the main navigation. In the underlying code however the H1 in the main content follows immediately after the two "Skip links" and all other content then follows sequentially. The result is a logical underlying structure for those who rely on it while it makes visual sense for those who rely on layout and positioning to understand content. 

You'll notice that we also have headings for section navigation (visible rather than hidden). Again if you check the underlying code you'll see that they are coded as H2 but are clearly separate from the main content and so can't be mistaken for subtopics of the main content's H2 or H3 (if there were any H3's in the main content on this page) headers. 

Your point about home pages is also a very good one. A home page often has a unique layout to the rest of the site making "traditional" rules hard to apply. It's not always obvious what the main heading is so frequently the site logo is wrapped up in a heading. On the home page and only the home page, it's acceptable to code a logo as H1, this is semantically logical, as the home page is about the whole site.  But we would not encourage it throughout the site as a logo has nothing to do with the structure of a page.  Ideally, though,  a natural H1 should be added to the start of the main part of the page and coded as H1 even if it's then hidden using CSS absolute negative positioning. This lets screen reader users know when they've reached the readable part of the page. 

&lt;strong&gt;@smitty&lt;/strong&gt;, thanks for sharing this. Using CSS to place Flash at the foot of the page and making use of a hidden H1 is one solution as long as it is truly accessible. 

&lt;strong&gt;@Jim&lt;/strong&gt;, I can see how point 6 "Headings should not be coded around content" may have been a bit misleading. As you've identified this refers to is the practice of coding a piece of text as a heading when it is not followed by any content that relates to it. This might have been done to give a piece of text visual emphasis or the text is a heading but no content has been added under it yet. But until it heads up some subordinate content, it isn't a heading. So saying "headings should not be coded on their own" is exactly right.

Apologies for your comment being mangled. We have had problems and are continually fixing what we unearth on an ongoing basis. I think adding some instruction beside the comment box as to how to input text is a good one so it's now on the list of things to do so watch this space, thank you :-). Our Web Team is also looking into the escape issue when submitting comments (we have no control over the blog).

Finally there is a link to "Why PDFs suck at the foot of the page because it refers to the previous post. We have this feature added at the foot of all pages so people can browse chronologically if they want to.

&lt;strong&gt;@naud&lt;/strong&gt;, you are correct in that WCAG does not state, one way or another, how many H1's are on the page and this is a debate that is still out for discussion. At RNIB we don't encourage the use of multiple H1's, as our experience of working with screen reader users is that multiple H1's can be confusing and misleading. Headings are often the only feedback screen reader users have to let them know how a page is structured. They can't see how many columns there are, how wide the margins are, what colours are used or what size the text is. Imagine a page with no visual structure at all, a solid block of edge-to-edge text. How would visual users know where the meat of the page starts?  

Visually users have positioning, column widths, white space, text size and colour and background shading to guide their eye to help them recognise where the unique page content starts. If there's more than one H1 heading it's not clear to a screen reader user where the content starts sequentially, especially if the headings are not sequential in the code (see my response to Martin's comments).

In addition screen reader users with conditions like autism may find it impossible to overcome the illogicality of having more than one top level heading. 

It's worth noting that &lt;a href="http://www.w3.org/" rel="nofollow"&gt;W3C&lt;/a&gt; only use one H1 in their web pages. I'd also say that if you had a page that had multiple H1's then you may need to review your content and perhaps think about breaking it out into multiple pages. 

HTML 5 has a proposed set of new elements that will address this issue to some extent. The specification is proposing adding header, nav, section, article, aside and footer elements which will introduce a whole new way of structure web pages. See &lt;a href="http://www.alistapart.com/articles/previewofhtml5" rel="nofollow"&gt;A Preview of HTML 5&lt;/a&gt; on A List Apart by Lachlan Hunt for more details.

Overall I would say that as with all of the guidelines they are just guidelines and need to be applied pragmatically with the end user in mind. It seems to me that it would be worth expanding some of the discussion here and the original "Tips post" into a longer post if that would help.</description>
		<content:encoded><![CDATA[<p>Hi Folks,</p>
<p>Many thanks for your comments; questions raised have flagged some interesting points about the nitty gritty of applying headings which is great.  So without further ado I&#8217;ll address these chronologically:</p>
<p><strong>@Martin Kliehm</strong>, Yes, the placement of an H1 in the code and hidden headings for navigation can be a tricky one and often needs to be thought about on a case by case basis. With regards to having the H1 appearing first in the code you could consider, where feasible, moving things around in the underlying HTML code so that the H1 heading comes first. Then you can use CSS to position things the way you want them visually. This will also solve the problem of having hidden headings for navigation coming before the H1 in the overall structure. Have a look at this page for example. Visually you see content in a traditional layout with the main navigation at the top, section navigation at the left-hand side and main body of content to the right of the section navigation and under the main navigation. In the underlying code however the H1 in the main content follows immediately after the two &#8220;Skip links&#8221; and all other content then follows sequentially. The result is a logical underlying structure for those who rely on it while it makes visual sense for those who rely on layout and positioning to understand content. </p>
<p>You&#8217;ll notice that we also have headings for section navigation (visible rather than hidden). Again if you check the underlying code you&#8217;ll see that they are coded as H2 but are clearly separate from the main content and so can&#8217;t be mistaken for subtopics of the main content&#8217;s H2 or H3 (if there were any H3&#8217;s in the main content on this page) headers. </p>
<p>Your point about home pages is also a very good one. A home page often has a unique layout to the rest of the site making &#8220;traditional&#8221; rules hard to apply. It&#8217;s not always obvious what the main heading is so frequently the site logo is wrapped up in a heading. On the home page and only the home page, it&#8217;s acceptable to code a logo as H1, this is semantically logical, as the home page is about the whole site.  But we would not encourage it throughout the site as a logo has nothing to do with the structure of a page.  Ideally, though,  a natural H1 should be added to the start of the main part of the page and coded as H1 even if it&#8217;s then hidden using CSS absolute negative positioning. This lets screen reader users know when they&#8217;ve reached the readable part of the page. </p>
<p><strong>@smitty</strong>, thanks for sharing this. Using CSS to place Flash at the foot of the page and making use of a hidden H1 is one solution as long as it is truly accessible. </p>
<p><strong>@Jim</strong>, I can see how point 6 &#8220;Headings should not be coded around content&#8221; may have been a bit misleading. As you&#8217;ve identified this refers to is the practice of coding a piece of text as a heading when it is not followed by any content that relates to it. This might have been done to give a piece of text visual emphasis or the text is a heading but no content has been added under it yet. But until it heads up some subordinate content, it isn&#8217;t a heading. So saying &#8220;headings should not be coded on their own&#8221; is exactly right.</p>
<p>Apologies for your comment being mangled. We have had problems and are continually fixing what we unearth on an ongoing basis. I think adding some instruction beside the comment box as to how to input text is a good one so it&#8217;s now on the list of things to do so watch this space, thank you :-). Our Web Team is also looking into the escape issue when submitting comments (we have no control over the blog).</p>
<p>Finally there is a link to &#8220;Why PDFs suck at the foot of the page because it refers to the previous post. We have this feature added at the foot of all pages so people can browse chronologically if they want to.</p>
<p><strong>@naud</strong>, you are correct in that WCAG does not state, one way or another, how many H1&#8217;s are on the page and this is a debate that is still out for discussion. At RNIB we don&#8217;t encourage the use of multiple H1&#8217;s, as our experience of working with screen reader users is that multiple H1&#8217;s can be confusing and misleading. Headings are often the only feedback screen reader users have to let them know how a page is structured. They can&#8217;t see how many columns there are, how wide the margins are, what colours are used or what size the text is. Imagine a page with no visual structure at all, a solid block of edge-to-edge text. How would visual users know where the meat of the page starts?  </p>
<p>Visually users have positioning, column widths, white space, text size and colour and background shading to guide their eye to help them recognise where the unique page content starts. If there&#8217;s more than one H1 heading it&#8217;s not clear to a screen reader user where the content starts sequentially, especially if the headings are not sequential in the code (see my response to Martin&#8217;s comments).</p>
<p>In addition screen reader users with conditions like autism may find it impossible to overcome the illogicality of having more than one top level heading. </p>
<p>It&#8217;s worth noting that <a href="http://www.w3.org/" rel="nofollow">W3C</a> only use one H1 in their web pages. I&#8217;d also say that if you had a page that had multiple H1&#8217;s then you may need to review your content and perhaps think about breaking it out into multiple pages. </p>
<p>HTML 5 has a proposed set of new elements that will address this issue to some extent. The specification is proposing adding header, nav, section, article, aside and footer elements which will introduce a whole new way of structure web pages. See <a href="http://www.alistapart.com/articles/previewofhtml5" rel="nofollow">A Preview of HTML 5</a> on A List Apart by Lachlan Hunt for more details.</p>
<p>Overall I would say that as with all of the guidelines they are just guidelines and need to be applied pragmatically with the end user in mind. It seems to me that it would be worth expanding some of the discussion here and the original &#8220;Tips post&#8221; into a longer post if that would help.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim</title>
		<link>http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/#comment-84457</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Sun, 06 Jul 2008 21:00:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.rnib.org.uk/wacblog/?p=199#comment-84457</guid>
		<description>I submitted two comments here the other day.

The first was mangled because apparently this comment box expects quasi-HTML, where it isn't plain text because you have to escape less-than signs, and it isn't HTML, because whitespace is preserved between paragraphs.

The second noted that the first was mangled and corrected the escaping.  Sadly, the moderator for this page deleted the second one and approved the mangled first one.  Is it too much to ask that the person in charge of approving these comments actually &lt;em&gt;reads&lt;/em&gt; them before deleting them?

For the record, when I said:

&#62; You mean “around” in the sense that and are “around” the element’s contents, right?

I actually meant:

&#62; You mean “around” in the sense that &#60;h1&#62; and &#60;/h1&#62; are “around” the element’s contents, right?</description>
		<content:encoded><![CDATA[<p>I submitted two comments here the other day.</p>
<p>The first was mangled because apparently this comment box expects quasi-HTML, where it isn&#8217;t plain text because you have to escape less-than signs, and it isn&#8217;t HTML, because whitespace is preserved between paragraphs.</p>
<p>The second noted that the first was mangled and corrected the escaping.  Sadly, the moderator for this page deleted the second one and approved the mangled first one.  Is it too much to ask that the person in charge of approving these comments actually <em>reads</em> them before deleting them?</p>
<p>For the record, when I said:</p>
<p>&gt; You mean “around” in the sense that and are “around” the element’s contents, right?</p>
<p>I actually meant:</p>
<p>&gt; You mean “around” in the sense that &lt;h1&gt; and &lt;/h1&gt; are “around” the element’s contents, right?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: naud</title>
		<link>http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/#comment-84110</link>
		<dc:creator>naud</dc:creator>
		<pubDate>Sat, 05 Jul 2008 09:44:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.rnib.org.uk/wacblog/?p=199#comment-84110</guid>
		<description>hi,

good article.

Though I don't agree with you when you say :
"Pages should only have one main heading, H1, which is the main title of the page and should be positioned at the start of unique page content."

The HTML specifications never say that. They only say that a heading should be used to entitle a section of a page. 

That means that you should always put the title in the...TITLE tag, not the h1. 

It also means that you can have many h1 tags in your page.Screen reders (Jaws...) deal with it whithout any problem.

JF NAUD</description>
		<content:encoded><![CDATA[<p>hi,</p>
<p>good article.</p>
<p>Though I don&#8217;t agree with you when you say :<br />
&#8220;Pages should only have one main heading, H1, which is the main title of the page and should be positioned at the start of unique page content.&#8221;</p>
<p>The HTML specifications never say that. They only say that a heading should be used to entitle a section of a page. </p>
<p>That means that you should always put the title in the&#8230;TITLE tag, not the h1. </p>
<p>It also means that you can have many h1 tags in your page.Screen reders (Jaws&#8230;) deal with it whithout any problem.</p>
<p>JF NAUD</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim</title>
		<link>http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/#comment-83800</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Fri, 04 Jul 2008 15:13:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.rnib.org.uk/wacblog/?p=199#comment-83800</guid>
		<description>I was really confused when you said:

&#62; Headings should not be coded around content that is by itself, they should always be followed by associated content.

I had to re-read it a few times to figure out what it meant.  "Coded around" isn't exactly normal lingo, I first assumed it meant "coded in the vicinity of", but that didn't make sense because you can't code in the vicinity of something that is by itself, it wouldn't be by itself then, would it?

You mean "around" in the sense that  and  are "around" the element's contents, right?  Those are the tags, not the heading.  The heading isn't "around" the content, or anything else for that matter.  The content and the tags together *are* the heading.  A reasonable way of wording it would be to say something like:

&#62; Headings should not be on their own, they should always be followed by associated content.

Two other things:

There is absolutely no indication on this form of what input it accepts.  Do I have to escape the less-than signs above?  Do I have to add paragraph tags?  There's not the slightest hint.

Why is a random "Why PDFs suck!" link below this comment box?</description>
		<content:encoded><![CDATA[<p>I was really confused when you said:</p>
<p>&gt; Headings should not be coded around content that is by itself, they should always be followed by associated content.</p>
<p>I had to re-read it a few times to figure out what it meant.  &#8220;Coded around&#8221; isn&#8217;t exactly normal lingo, I first assumed it meant &#8220;coded in the vicinity of&#8221;, but that didn&#8217;t make sense because you can&#8217;t code in the vicinity of something that is by itself, it wouldn&#8217;t be by itself then, would it?</p>
<p>You mean &#8220;around&#8221; in the sense that  and  are &#8220;around&#8221; the element&#8217;s contents, right?  Those are the tags, not the heading.  The heading isn&#8217;t &#8220;around&#8221; the content, or anything else for that matter.  The content and the tags together *are* the heading.  A reasonable way of wording it would be to say something like:</p>
<p>&gt; Headings should not be on their own, they should always be followed by associated content.</p>
<p>Two other things:</p>
<p>There is absolutely no indication on this form of what input it accepts.  Do I have to escape the less-than signs above?  Do I have to add paragraph tags?  There&#8217;s not the slightest hint.</p>
<p>Why is a random &#8220;Why PDFs suck!&#8221; link below this comment box?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: smitty</title>
		<link>http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/#comment-83778</link>
		<dc:creator>smitty</dc:creator>
		<pubDate>Fri, 04 Jul 2008 12:54:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.rnib.org.uk/wacblog/?p=199#comment-83778</guid>
		<description>Th'at's a cool article. We usually don't think enough about titles and headers. My practice to handle accessible headers:
- With a flash header: give your #page element a padding or margin-top. Include your flash at the bottom of the page (after the usual footer links), then place it with an absolute position on top, with a higher z-index. Place your h1 at the first place of the page, then give it following CSS: "height:0; padding:my_padding_top; background:my_flash_animation_rendered_in_gif; z-index: lower_value;". It works perfectly.
- Without a flash header, do it the same way: you place your banner in the background of the h1 element and hide the h1's text with the CSS. And hop: you have a h1, an image, and it's accessible.
Excuse my bad english ;)</description>
		<content:encoded><![CDATA[<p>Th&#8217;at&#8217;s a cool article. We usually don&#8217;t think enough about titles and headers. My practice to handle accessible headers:<br />
- With a flash header: give your #page element a padding or margin-top. Include your flash at the bottom of the page (after the usual footer links), then place it with an absolute position on top, with a higher z-index. Place your h1 at the first place of the page, then give it following CSS: &#8220;height:0; padding:my_padding_top; background:my_flash_animation_rendered_in_gif; z-index: lower_value;&#8221;. It works perfectly.<br />
- Without a flash header, do it the same way: you place your banner in the background of the h1 element and hide the h1&#8217;s text with the CSS. And hop: you have a h1, an image, and it&#8217;s accessible.<br />
Excuse my bad english ;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin Kliehm</title>
		<link>http://www.rnib.org.uk/wacblog/headings/quick-tips-for-accessible-headings/#comment-83760</link>
		<dc:creator>Martin Kliehm</dc:creator>
		<pubDate>Fri, 04 Jul 2008 10:05:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.rnib.org.uk/wacblog/?p=199#comment-83760</guid>
		<description>Thanks Henny for sharing that. But how do you handle when the h1 is not the first headline in a document?

Usually there's the header with a navigation before the content, sometimes a breadcrumb path. Some people like to add hidden headlines for those, but then you have h2 h2 h1...

Or in other cases there's no real h1 on a home page. There's a logo and a bunch of equally important boxes / applications, so we ended up embedding the logo in a h1.

What do &lt;em&gt;you/em&#62; recommend in those cases?&lt;/em&gt;</description>
		<content:encoded><![CDATA[<p>Thanks Henny for sharing that. But how do you handle when the h1 is not the first headline in a document?</p>
<p>Usually there&#8217;s the header with a navigation before the content, sometimes a breadcrumb path. Some people like to add hidden headlines for those, but then you have h2 h2 h1&#8230;</p>
<p>Or in other cases there&#8217;s no real h1 on a home page. There&#8217;s a logo and a bunch of equally important boxes / applications, so we ended up embedding the logo in a h1.</p>
<p>What do <em>you/em&gt; recommend in those cases?</em></p>
]]></content:encoded>
	</item>
</channel>
</rss>
