Redesigning with HTML 5 and WAI-ARIA

For the past few months, I’ve been lucky enough to tour places like Indonesia talking about cutting-edge web development languages like HTML 5 and WAI-ARIA.

My new year resolution was to actually start using them, so made an HTML 5 test page to show that at least some those useful new elements can be used now.

But a test page isn’t real world, so the logical next step was to redesign this site to use the new technologies. While my blog is a set of old-school static documents with none of the “Web 2.0″ Ajax sexiness that would best show off these technologies, it has one thing in its favour: it’s five years worth of often-dodgy markup (I was learning!) with 3000 or so comments, some containing unsanitised code. It’s a reasonable road-test for HTML 5, which was specifically designed for backwards compatibility. This is still a test; validation errors are part of that, although if you see any post with broken layout or unreadble content, please let me know.

When I announced this project, I had no idea how long it would take or how enormous this write-up would be. So I’m doing it in parts. This part deals with the structural markup of the major page elements, and how to style it.

In Part 2, I’ll show that Web Fonts can enhance accessibility by being “real text” instead of requiring images of text, I’ll make some of the headings follow my “ransom note” theme with a Web Font.

Lastly, I’ll do some work on the guts of the page, using HTML 5′s article elements to better mark up blog posts and comments and show how to use the section elements to better structure accessible hierarchical headings on sites that are CMS-driven.

Please note that I’m not trying to persuade you to use HTML 5; the spec is unfinished and liable to change; this is an experiment. Neither do I claim that it’s the best thing ever; I’ve had my doubts about HTML 5. But I do believe that it’s the only game in town for marking up documents and web applications in the (imminent) future, so it’s sensible to start understanding it and kicking the tyres. Testing it out like this and giving feedback to the HTML 5 lists will also help improve the language.

With those caveats out of the way, let’s begin.

HTML 5 WordPress theme

All I’m doing is hacking markup, so you need nothing other than a text editor and a web brower to duplicate what I’m up to. However, this blog uses a modified version of WordPress’ default Kubrick theme, so where appropriate I’ll tell you which file I’m hacking or you can download my HTML 5 WordPress theme.

Please note the small print (marked up using the small element, sensibly redefined in HTML 5 to “represent small print (part of a document often describing legal restrictions, such as copyrights or other disadvantages), or other side comments” but which, absurdly, must go around each item in the list rather wrap around the whole ul regardless of the fact that it works in all browsers):

Setting the DOCTYPE

HTML 5, when used as plain HTML rather than its XHTML 5 sibling doesn’t need a DOCTYPE. But all browsers do, otherwise they go into Quirksmode, which you don’t want: the collision of HTML 5 and Quirksmode is like matter and anti-matter meeting, and will cause a negative reality inversion that will make your underwear catch fire.

You’ve been warned, so at the top of your document, you need the line <!DOCTYPE html>. (In WordPress, this is at the top of header.php).

Some sites “use” HTML 5, when in actual fact all they’ve done is take their existing code and change the DOCTYPE. That’s fine and dandy if you’ve been using valid, semantic code as HTML 5 is very similar to valid HTML 4.01. Eric Meyer mentions small differences like “not permitting a value attribute on an image submit”, and there are a few differences between the languages, summarised in the document HTML 5 differences from HTML 4.

However, I didn’t want to simply rebadge my existing code, but show that you can use some of the new structural elements now.

Using some new structural elements

My blog – like millions of others – has a header denoted by <div id="header">, a footer <div id="footer">, some articles (wrapped by an area called “content”, <div id="content">) and some navigation (wrapped up in an area called “sidebar” <div id="sidebar">).

Although these all have very different functions within the page, they use the same generic div in the markup. as HTML 4 has no other way to code them. HTML 5 has new elements for distinguishing these logical areas: header, nav, footer and aside. (There’s more on this in an artice by Lachlan Hunt on A List Apart: A Preview of HTML 5.)

It’s a simple matter to change the HTML divs into the new elements. (In WordPress, the relevant files are header.php, footer.php, sidebar.php and index.php.) The only difficulty I had was deciding which element to use to mark up my sidebar, as it also includes a search field and “colophon” information as well as site-wide navigation.

I decided against the aside element, as the spec says it “represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content”, but it’s nevertheless content rather than navigation. So I decided to go for the nav element as the closest fit.

However, there’s no equivalent structure to the grouping “content” div in HTML so I’ve left that there.

The overall aim is to replace this structure:

structure chart before redesign

with this:

structure chart before redesign

Note that I’ll be coming back the individual posts inside the content div next week, using some clever HTML 5 tricks to mark up sections, comments and headings that can dynamically change their “level” in the hierarchy depending on where the CMS puts them.

New form attributes

As well as the main structural item on the page, I’ve added some new attributes on input elements in the comments form.

HTML 5 was designed to reflect what developers actually do, rather than to reflect a philosophical purity, and that’s very clearly manifested in the new attributes which mean the browser takes up much of the work currently done by developers re-inventing validation routines in JavaScript. (Extending forms functionality was how the HTML 5 spec began).

So I amended the email input field in the comments to be input type="email" which means that when the user submits the form, an HTML 5-aware browser will use built-in validation routines to check that it’s in the correct format, without any JavaScript. (Check it out in an experimental implementation in the current version of Opera, as that’s my employer who is paying for me to do this, and note that it also adds a “mail” icon in the input field as a cue to the user.)

There are similar input validation routines triggered by some of the new input types, such as url (which I use on the field that asks for the user’s web address), number and pattern which compares the input with an arbitrary regular expression.

Another good example is input type="date", which pops up a calendar widget/ date picker when the user focusses on the input field. You can test the date picker, or here’s a screenshot from Opera 9.6:

date picker pops up next to input field

A very useful new attribute I used on both input fields for commenter’s name and email address, and the comment textarea was type="required" which generates a message on submission if the fields are left blank. I suppose each different localisation of a browser would need to have a different message, and it’s not (as far as I know) customisable by the developer.

red-bordered browser message 'You have to specify a value'

The good thing with all these new form geegaws is that they’re all attributes on an exisiting element, so people using older browsers just see a plain old input field.

A note on screenreaders and HTML 5

I hope screenreaders are ready for these new interactions; I asked the html 5 group to formally invite screenreader vendors to participate in the specification; to my knowledge, none have done so.

Laying out the new elements

It’s not too hard to layout the new elements (although I wasted half a day wrestling with IE 6 until Andy Higgs pointed out that dropped floats were an IE 6 problem, not an HTML 5 problem, so IE 6 users just get a fixed width site. Thanks Andy; wish I’d thought of that four hours before you did!)

In all the non-IE browsers, you can lay out anything using CSS – even a nonsense element. One gotcha that wasted a whole day is when I forgot that the current crop of browsers have no “knowledge” of these elements.

All browsers have default settings for the elements they “know about”—how much padding, margin they element gets, does it display as a block or inline?. (Here’s a sample default stylesheet.) Unless over-ridden by CSS, these defaults apply. But the browsers don’t know about header, nav and the like, so have no defaults to apply to them.

I got terrible rendering oddities until I explicitly told the browsers

header, footer, nav, article {display:block;}

IE layout

There’s one gotcha about styling HTML 5 pages in IE: it doesn’t work. You can force it to quite easily with a JavaScript hack document.createElement('element name'). (Lachlan Hunt gets to the bottom of why IE needs this.)

For your convenience, Remy Sharp has written an HTML 5 enabling script which I use in the header to conjure all the missing elements into existence all at once.

But let’s be clear: this won’t work if your IE user doesn’t have JavaScript turned on. How much of that’s a big deal that is for you to decide. Pragmatically, it seems to me that the sites that will benefit the most from HTML 5’s new “Ajax”-style features, such as drag-and-drop, are the sites that currently have no hope of working without JavaScript.

Firefox 2 and Camino 1 layout

Firefox 2 and Camino 1 both use Gecko 1.9 which has a bug and so gets grumpy if you don’t serve the page as XHTML. (Go figure; that’s almost enough to trigger a negative reality inversion and you know how bad that can be). Nice Mr Zeppelin (can I call you “Led”?) provided some PHP for content negotiation, to send that errant rendering engine the wrong DOCTYPE while the good boys get the sweeties.

I decided not to use it, because Firefox 2 immediately choked on the first piece of code it found that wasn’t well-formed XML, and one purpose of this experiment is to see how current browsers behave with backwardly-compatible HTML 5. My conscience is reasonably clear; Firefox and Camino users (while not having the grace, charm and irresistable sexual magnetism of Opera users) are a clever lot who upgrade frequently (I’ve never heard of a corporate lock-in to Firefox 2).

What’s the point of those new structural elements

Well, they add semantics to the page. The browser now knows which area of your site is the header or the footer because there are header and footer elements, whereas div might be called “branding” and “legal”, or even “en-tete” and “pied-de-page” or “kopfzeile” and “fusszeile“.

But so what?

Robin Berjon expressed it beautifully in a comment on A List Apart:

Pretty much everyone in the Web community agrees that “semantics are yummy, and will get you cookies”, and that’s probably true. But once you start digging a little bit further, it becomes clear that very few people can actually articulate a reason why. So before we all go another round on this, I have to ask: what’s it you wanna do with them darn semantics?

The general answer is “to repurpose content”. That’s fine on the surface, but you quickly reach a point where you have to ask “repurpose to what?” … I think HTML should add only elements that either expose functionality that would be pretty much meaningless otherwise (e.g. canvas) or that provide semantics that help repurpose for Web browsing uses.

In my view, there are a couple of things I want to do with those semantics. The first is for search engine use; it’s easy to imagine Messrs Google or Yahoo! giving lower weighting to content in footer elements, or extra weight to content in the header. The second reason is to make the site navigable for people with disabilities. People with learning difficulties might instruct their browser always to put the articles before the navigation, for example. User agents might very well have a keyboard shortcut which jumped straight to the nav for example, or jumped straight past the navigation, in a programmatic implementation of “skip links“.

Which brings me to…


WAI–ARIA is new W3C specification (see Gez Lemon’s Introduction to ARIA) which is expected to become a standard in 2009. It’s the Accessible Rich Internet Applications Suite, which allows developers to make web 2.0 applications more accessible by extending HTML 4 for all the bolt-ons that that web applications require such as sliders, date pickers and Ajax-updated dynamic regions.

Until HTML 5 is widespread, such Ajax widgets can only be made through scripting and are pretty much invisible to assistive technologies unless extra information is added to the HTML and manipulated by the scripts. That’s what ARIA does, and it’s being supported by all the browsers, the main screenreader manufacturers and JavaScript libraries such as Dojo, the Yahoo! User Interface Library and (partially) jQuery.

There’s a lot of overlap between WAI-ARIA and new elements and attributes in HTML 5, and there are many political mailing list yawnfests about which is better, what will supersede what, but the fact is that ARIA has some support now, while most browsers are just beginning to support HTML 5—so to make my site as accessible as possible, I’m adding ARIA attributes, too.

Firstly, on the main structural areas of the page, I’ve added what ARIA calls “document landmark roles” which are pre-defined keywords that assistive technologies look out for. Steve Faulkner has a useful list of equivalences between HTML 5 elements and landmark roles, although I disagree with him on one aspect, as I believe header to be fucntionally the same as ARIA’s banner role, so have marked up that element header aria-role="banner".

I’ve also added ARIA information to the comments form. The ARIA equivalent of the HTML 5 input attribute required is aria-required="true".

Relations between ARIA and HTML 5

The HTML 5 validator gives errors when it encounters ARIA information.

In an email conversation about this with Gez Lemon, Gez said

ARIA is intended to bridge accessibility issues with HTML 4.01, XHTML 1.0 (and every other markup language), which wouldn’t validate. As HTML 5 is being developed at the same time as ARIA (although ARIA is likely to reach recommendation status before HTML 5), HTML 5 is likely to include some of the benefits afforded by ARIA natively, so are explicitly stating what parts from ARIA are allowed.

Henri Sivonen, who made the HTML 5 validator told me

I chose not to support landmarks for the time being, because a year ago, it seemed that the introduction of landmark roles could have been avoided by moving to corresponding HTML 5 elements directly.

Eventually, there needs to be a spec that covers the integration of ARIA and HTML 5 both from the point of view of document conformance and from the point of view of processing in browsers. There’s no such spec yet.

I don’t mind; HTML 4 won’t validate with ARIA information, either, but for me, accessibility trumps validation.

The biggest worry, perhaps, is if the ARIA and HTML 5 information contradict each other. The ARIA spec says

If the host language incorporates ARIA support and there is a conflict between a host language feature and an ARIA feature, assistive technologies should assign preference to the ARIA feature.

What, exactly “if the host language incorporates ARIA support” means is unclear to me.

The end

Phew, this has turned out to be War and Peace, hasn’t it?

Read Part 2


Thanks to my colleagues and bosses at Opera for indulging me and allowing me the time to figure this out. Lachlan Hunt was patience personified, answering my endless HTML 5 questions. Also to Gez Lemon and Henri Sivonen for advice about the relationship between ARIA and HTML 5, and for letting me quote them. Finally, thanks to all those kind people on Twitter who helped me with IE and other pesky browsers (IE Tester was sometimes inaccurate, while browsershots was down. But I don’t really trust emulators, anyway). You’re not all named above because you’re so numerous. But thanks all the same.

38 Responses to “ Redesigning with HTML 5 and WAI-ARIA ”

Comment by Eric Meyer

Very nice. Possible problem, depending on one’s views: the post layout is completely shattered in Camino 1.6.6 (and probably earlier). The sidebar stuff lines up horizontally across the top of the content area, and “Leave A Reply” sits next to them, and then all the content is below the sidebar pieces.

The home page is the same except there’s no “Leave A Reply”, of course.

As I say, whether one considers it a problem is a personal-view thing. Everyone has some set of browsers about which they simply do not care. Just thought I’d mention it for those who might care. And who knows, maybe there’s a simple fix!

Comment by Eric Meyer

Followup: ALL of the comment area shows up to the right of the sidebar pieces in Camino, except for the commenting form, which is all the way at the bottom of the page, just above the footer and your sociable little hamster guy. Fun, wot?

Comment by Bruce

Thanks Eric – Camino is a problem that Jeremy Keith alerted me to (see the test page

Apparently it’s cos Camino pre-version 2 uses the same rendering engine as Firefox 2, which similarly borks the page.

It’s cured in Firefox 3 and Camino 2.

I could serve the page as XHTML for those browsers, but then the page would probably break; in five years-worth of blogging, there’s bound to be malformed code there.

(It’s also my opinion that serving sites as XHTML isn’t an option for those which allow any kind of markup in comments, or any corporate sites with lots of authors with different markup skills.)

As I said, Firefox and Camino users are the type of swicthed-on folk who upgrade their browsers regularly, so by the time HTML 5 becomes more mainstream (eg, outside the realm of browser employees farting around on their personal blogs in company time) only IE 6 will be a problem.

Comment by Jeremy Keith

Just a small point on the Camino issue. I agree that Camino users are likely to upgrade to the newest version quickly. But the current version is 1.6.6. From what you say above, it sounds like you’re saying Camino 2 is the current version (the equivalent of Firefox 3) but that isn’t the case. Camino 2 is currently a beta release that comes with the usual warnings: “may be unstable and may not be suitable for day-to-day use.”

But, as you say, by the time HTML5 becomes more mainstream, I’m sure most Camino users will be on at least version 2.

Comment by Andrew Brewster

Interesting…that explains why this posting is shot to pieces in my favourite browser, Konqueror. For Linux noobs, that’s part of the KDE desktop, mine’s on v3.5.10.

At the top of the page I see the site title, then four columns, left to right they are
search box
lowlights, categories, pages etc.
responses to the post

The main article appears about one third down the page and takes up about 85% of the screen width, shoved across the right. Under that is two columns: the response box (left) and the colophon (right). .png screenshots available if you’re interested.

Guess that just proves your point: some browsers don’t understand the semantic replacements for

Oddly, it seems to understand the element and as far as I can tell most of the usual styling is present.

Hell, I don’t know if it’ll even post this when I press the Submit button with all those geegaws on it…. but at least I can fire up Opera and see all the HTML 5 goodness as intended

Comment by Andrew Brewster

Oops, HTML not allowed, so that was

… semantic replacements for the div element


… understand the small element …

Comment by John Faulds

After reading quite a bit about HTML5 recently (here and on other sites), I’ve just been working on a site for which I decided to use some HTML5 flavours for the first time. As it’s a small business site, I haven’t been able to make use of the new structural elements, but have taken the cue from Andy Clarke and Jon Tan about using HTML5-inspired classnames, and have also added landmark roles.

Comment by » Switched

[...] its own set of problems; I’ve been seeing a lot of the same blog posts you have regarding the difficulty of implementation today, and the working group issues plaguing its development. It’s got a long ways to go. But [...]

Comment by Switched |

[...] its own set of problems; I’ve been seeing a lot of the same blog posts you have regarding the difficulty of implementation today, and the working group issues plaguing its development. It’s got a long ways to go. But [...]

Comment by A Detailed Look at HTML5 for UX Designers

[...] There is another standard out there that attempts to solve this same problem of communicating the purpose of content to assistive technologies. It’s called ARIA (or WAI-ARIA), which stands for Accessibility of Rich Internet Applications. This specification describes semantic structures known as roles, states, and properties that can be integrated into HTML elements in order to communicate the purpose of those elements to assistive technologies, which can then present them in a meaningful manner to the user. While it is not part of the HTML5 spec per se, ARIA is going to have an impact on it because it is supported by current browsers and is already in use. Decisions are going to have to be made on how ARIA structures relate to the semantic elements of HTML5 in order for content to render reliably. Bruce Lawson describes this issue in detail here. [...]

Comment by

Wow, awesome weblog format! How lengthy have you been blogging for?
you made running a blog glance easy. The whole glance
of your web site is fantastic, let alone the content!