I'm working for the public sector and I had to take over a web project from my superior. The page is already made accessible to people with disabilities.
While making some changes I thought about changing from HTML4 to HTML5 because I heard it has some new, better aspects for the accessibility.
Does the change really pay off? Or is it just wasted time to convert the code?
HTML5 brings with it a large array of semantic elements that give the user agent further insight into how the page is laid out. It is definitely worth it and shouldn't be too time consuming especially if your styles are decent and don't rely on tag types. You will basically be replacing a bunch of <div>s with their semantic counterparts.
For example, here are some of the new tags in HTML5:
<section>
<nav>
<article>
<aside>
<hgroup>
<header>
<footer>
<time>
<mark>
The other parts of HTML5 like CSS3, local storage, etc. don't really have accessibility benefits.
I suggest reading up more about what all these tags actually mean to make sure you're using them correctly. There were also other changes like clear meanings for the <b>, <em> and <strong> tags.
Support
Some browsers like IE6 (not sure about IE7) don't like these new tags and will mangle the page when used. You can include a polyfill library like Modernizr to fix this up, simply include the script and everything works!
Further reading
Dive into HTML - Semantics
HTML5 Doctor
While html5 is a great standard to aim for, many browsers still don't support the newer tags/markup....enter ARIA or WAI-ARIA (Accessible Rich Internet Applications Suite).
Clarissa Peterson's website gives a nice real-world example of html5 v ARIA. See the section titled HTML5 & ARIA.
Related
Why would one use <header> tags or <footer> or <address> tags? Is it just for SEO, or another reason?
I ask this question because IE8 and older doesn't support many of these elements.
These are all tags introduced with HTML5. They are part of an evolution of HTML. They're not supported in IE8 because they were introduced after support for IE8 ended. They were introduced to provide more logical elements that were commonly used in web page designs.
If you need to support IE8, you can do so by not using these tags and sticking with <div> tags with classes, such as:
<div class="header"></div>
<div class="footer"></div>
<div class="address"></div>
accompanied, of course, by CSS styles for each.
They have nothing to do with SEO.
The tags you describe, such as a header tag, are what is known as 'syntactic sugar'. That is, it makes it easier to read and know what the intent of the tag is. This is good for human readers, but it is especially useful for automated systems.
Compare these examples that all could mean exactly the same thing:
<header>...</header>
<div class="header">...</div>
<div class="hdr">...</div>
Note that header is easy to differentiate from the two div tags. Only if you know what the class attribute means will you understand what the div tags are defining. Because the class attribute value is free-form, it means there is no standard definition.
SEO is one example of an automated system that might need to read the tag directly and understand that it has a semantic meaning. A particularly observant SEO engine might understand that the above three tags all refer to the same semantic definition, but you will agree that writing an engine that would presciently know all three mean 'header' would be difficult. In fact, there is nothing to disambiguate the latter two from <div class="zebra">.
Having automated systems be able to read your code and understand the semantic meaning goes well beyond SEO: it can make automated handling of mobile versions easier, for instance. You no longer have to hand-roll code for your specific implementation. You can use Javascript libraries that might do handy things with your headers, such as allow them to be sortable or auto-link them. Anyone writing those libraries has an easier time doing it.
You also ask why you would use something not supported by older browsers that are still widely used. That is a question of demographic: what is your app targeting? If you need the 6% of the world that is using an old browser to utilize your application, then you should absolutely use backwards compatible techniques. If, on the other hand, you want to make the UX the best possible for a set of users likely to be using a modern browser, then you should use the new tags. (Note that having bad UX or long development time as you roll your own solutions to things may cost you more than 6% of your application's userbase...)
I'm still trying to familiarize myself with HTML5, and there's this stuff which feels a bit confusing....
I once read in Jeremy Keith's book and HTML5 Doctor (via this question) which say that HTML5 makes it possible to use multiple h1s. In HTML5, each section can have its own heading element so it is okay to have more than one h1. I've seen a Wordpress theme framework, "underscores", which seem to apply this in the fullest.
However, this may seem to pose problem for older browsers (yet to support HTML5) in defining the site structure/document outline. Also, it poses problem for SEO.
I stumbled upon Matt Cutts's (from Google) video and re-read Keith's book which recommend limiting the use of h1 and use the conventional document outline (only use one or two h1 per page, followed by multiple h2, h3, etc). Matt Cutts also imply that multiple h1 is not too good for SEO.
However,
I previously never paid serious attention to site structure/document outline. So I never know how old browsers (pre-HTML5) read a site structure/document outline. There exists a HTML5 outliner, but I can't find outliner for HTML4.
Matt Cutts's video (regarding HTML5 and SEO) is published in 2009. I
don't know if Google already support the new HTML5 way of outlining
document.
So my question is, if I want to:
Support older browsers (e.g. Firefox 3.0 and IE 6) to display correct site structure/document outline
Have a good result in SEO
Which one should I use: multiple h1s (the way it is done in HTML5) or the conventional way?
This HTML5 one (example taken from HTML5 Doctor):
<h1>My fantastic site</h1>
<section>
<h1>About me</h1>
<p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
<section>
<h1>What I do for a living</h1>
<p>I sell enterprise-managed ant farms.</p>
</section>
</section>
<section>
<h1>Contact</h1>
<p>Shout my name and I will come to you.</p>
</section>
or the conventional way?
<h1>My fantastic site</h1>
<h2>About me</h2>
<p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>
<h3>What I do for a living</h3>
<p>I sell enterprise-managed ant farms.</p>
<h2>Contact</h2>
<p>Shout my name and I will come to you.</p>
Use the new format.
Plenty of people will use h3s or h2s, and that's perfectly fine as well.
In fact, they'll use the section or article or header or footer elements offered by html5, and then use h3 or h4 as headings for that document-segment (for fear of SEO penalties / legacy styling|layout quirks).
And that's fine, too.
If you watch Cuts' video again, he says to keep the h1 use to a minimum -- only using multiples when they're really warranted.
That hasn't really changed at this point.
Google isn't going to murder you for having multiples.
Google IS going to expect each one to mean that there was a fundamental change in content.
That's true whether or not you have the sectioning (section/article/etc) elements in there or not.
Google has also gotten to the point where they're properly spidering AJAX-only, or JavaScript-dependent websites, and have their own rich-content metadata system... ...they're sophisticated enough to parse section or article.
Worry more about the quality of the content, and if you're ready to take it on, the Google-specific metadata which they use for search-results, etc...
...and let Google worry about navigating the semantics (as long as you're using them well, and not doing anything shady).
Lesser crawlers, who knows... ...but that's on a per-crawler basis, and most people only need to be concerned with Google and Bing and Yahoo, with other crawlers either feeding off of Google, or being very domain-specific (like if you want to rank highly on an opt-in, car-rental crawler for some reason... ...at which point you should be supplying an XML/JSON feed of some sort, anyway).
deathlock, your second example doesn't contain any sectioning elements. However, you could use sectioning elements with headings other than h1. I think that's the point of your question:
h1 in every sectioning element
<section>
<h1>…</h1>
<section>
<h1>…</h1>
</section>
</section>
or "calculated" heading level
<section>
<h2>…</h2>
<section>
<h3>…</h3>
</section>
</section>
Semantically/technically, they are the same.
SEO shouldn't be a problem, because "h1 everywhere" will be (and already is) used all over the web, and the major search engines know this. If they want to support HTML5, they have to understand the outlining algorithm. I bet that their crawler/APIs already correctly calculate the real heading level, like the HTML5 outliner does, for example.
The only reason why you'd want to use h2-h6 as sectioning element heading would be old accessibility software, e.g. screenreaders. They usually offer an outline menu, so the user can jump directly to a certain heading. So if you always use h1, older screenreaders, that don't know HTML5, would announce all headings as h1, because they don't calculate the correct outline levels. However, Jaws 13 for example (current version of a screenreader), only gets "h1 everywhere" for HTML5 correct in IE, AFAIR, and it gets confused if you use other heading levels in a HTML5 page. This is, of course, a bug, but it's a nice example that sticking to the "old way" will not always work for newer software.
So you might get problems either way.
In my opinion you should stick with what the HTML5 spec recommends, and this would be: use h1 for all sectioning element headings. Because this specification is what future user-agents, accessibility tools, search engines and other services/softwares use to build their product.
However, it depends on your use case, of course. If you know your visitor statistics, you should use them to make the right decision for your special case. E.g. if your site will not live for many years in the future, use what is now best supported.
The best way is to use HTML5 and use this link to make them work in the old browser since Google is ready your website way better and consider you use new technology (so that your site is better) if you use the new tags.
<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
Put it in the head section of your site and it'll work fine for old IE versions
HTML5 introduced 22 new markup tags. W3C still recommends we stick to the old tags, because IE exists. I think adding JavaScript for this purpose is over the top. HTML5 also features the less known role, comparable with the ARIA role of XHTML 2. The great advantage of the markup tags is that search engines like Google know which is which. Do search engines also support these?
Hard to tell, but I would say Google understands them in the same way as it understands HTML5 tags. And even support for HTML5 will take some time, since new sites could take too much vantage from old HTML4 sites.
For example a <div role="main">...</div> would be like the main <article>...</article> of your page.
Please keep in mind that it is important to make your document at least ARIA valid. For example, use more than one role="main" in your site is invalid and could be considered as blackhat SEO.
Worth using role where appropriate. Remember that it improves the accessibility of your site.
Everyone is now talking about HTML5, i dont really understand what is the difference between it and the normal .xhtml
could you please solve some of my doubts:
What are the differences?
What are the advantages and disadvantages?
Is HTML5 considered a markup language or an scripting language?
What are the differences?
HTML 5 is just the next version of HTML. It takes HTML 4 and adds more stuff to it (while throwing out a few bits that shouldn't be used and changes the rules on how to parse it (to what browsers have been doing for the last decade anyway)).
What are the advantages and disadvantages?
It lets you do more stuff.
It doesn't have any disadvantages (other than that the new stuff isn't well supported yet).
Is HTML5 considered a markup language or an scripting language?
It is a markup language with a bunch of DOM APIs.
I guess the confusion is that HTML4 and HTML5 don't do much (on their own). You need javascript and css and that is when the party really starts.
When people are talking about HTML5 I guess they are talking about HTML5+ CSS3 + Javascript (compared to HTML4 + CSS2 + Javascript).
For a good example of the adventures you can have in the new world check this out:
http://slides.html5rocks.com/
Remember this isn't using .NET or PHP or any thing, its "just" HTML5 + javascript + css
pro
fancy new options
more elements to better define your content
video without flash
con
not supported by all browsers
Not a lot of good quality docs available (yet)
And it is still a markup language as it has no dynamic elements in it that are scriptable.
basically html5 is just like html, with some extra tags added,
like the canvas element for drawing, the video and audio elements for media playback, some new content specific elements, like article, footer, header, nav, section. it has also better support for local offline storage. and also some new form controls, like calendar, date, time, email, url and search
So actually not much you couldn't do earlier with some JavaScript (or jquery, as some people like to call it now :p), but it's designed to make those (nowadays) common tasks a lot easier
What are the differences?
See HTML5 differences from HTML4
What are the advantages and disadvantages?
That's going to depend to a certain extent on what you're trying to achieve, but it might help to understand the rationale behind the spec. Basically, backwards compatibility is one of the main goals so, if you avoid using any of the new features like video or canvas, there should be no disadvantages over the previous standards.
Is HTML5 considered a markup language or an scripting language?
From the WHATWG FAQ:
HTML5 is a new version of HTML4,
XHTML1, and DOM Level 2 HTML
addressing many of the issues of those
specifications while at the same time
enhancing (X)HTML to more adequately
address Web applications. Besides
defining a markup language that can be
written in both HTML and XML (XHTML)
it also defines many APIs that form
the basis of the Web architecture.
Some of these APIs were known as "DOM
Level 0" and were never documented
before. Yet they are extremely
important for browser vendors to
support existing Web content and for
authors to be able to build Web
applications.
I have seen HTML 5 coming up in near future. How does it differ from HTML 4, which has been 'in' for so many years in web development?
thanks
Difference between HTML 5 and HTML 4
And as per W3C
Consider these images (from www.alistapart.com), the structure of a page is hugely different:
HTML4
HTML5
This is just an example, take a look on other comments for articles about this subject
Broadly speaking, there are four main areas of change:
Semantic markup, including the following tags:
<section>
<article>
<header>
<footer>
<nav>
<aside>
<hgroup>
This also covers changes to the <doctype>, <html> and <meta> tags, as well as link relations (the rel attribute on an <a> tag).
Improved form support - mainly semantic additions to input types, and a few neat things like field autofocus and placeholder text.
Multimedia tags - <video>, <audio> and <canvas>. <video> and <audio> are intended to improved better support for embedded media in the page; <canvas> is for programmatic two-dimensional bitmap drawing on the page through JavaScript.
Changes to the DOM that are just accessible through JS - navigator.geolocation, window.localStorage (storing user data offline), window.applicationCache (storing app data offline), web workers (multithreaded JavaScript, with some caveats)
Different parts of HTML are in different stages of specification and implementation - the form changes are poorly supported outside of Safari, the <video> tag is basically unusable in a cross-platform environment (without multiple video formats), and IE has built-in support for next to none of these changes.
The best place to read up on HTML5 that I've seen is Mark Pilgrim's excellent book in progress, Dive into HTML5
HTML 5 differences from HTML 4 by W3C
If you are hesitant to read through a thousand pages of HTML5 specification, take a look at this article. It will give you a good overview of what HTML5 is all about, and it goes to explain how you can use HTML5 right now, since most A-grade browsers actually supports most of the new goodies; like the new HTML-elements and embedded video/audio.