There is much to digest, but one figure really caught my attention: only 1.6% of respondents had JavaScript disabled. Turning that round, 98.4% of screenreader users had JavaScript enabled.

Hopefully this will finally bury the WCAG1-era myth that JavaScript is automatically bad for accessibility or that pages that depend on scripting are inaccessible to assistive technologies.

This myth came about from the early days of screenreaders, which took a snapshot of the rendered page into a buffer and, when a user was navigating a page, he was really navigating that snapshot. If a page was changed with script the user wouldn’t know because another snapshot wasn’t triggered. (Even in this model, some JavaScript was fine. If, for example, your page contained lots of document.writes that executed immediately, and wrote HTML to the page, that would be available.)

As the Web made more use of “Ajax”, screenreaders became more sophisticated and now can handle most scripted interactions. This doesn’t mean that JavaScript is always fine to use; just as you can write inaccessible HTML and CSS, it’s possible to script away accessibility. An understanding of WAI ARIA is vital to professional JavaScripters.

(It’s also important to understand that not all accessibility needs are assistive technology needs. Christian Heilmann and Antonia Hyde showed that some scripting can be empowering for people with cognitive problems with their Easy YouTube and Easy Flickr.)

So we know that script doesn’t scare off assistive technologies, and we know from Yahoo! developer Nicholas C. Zakas’ report How many users have JavaScript disabled? that only 1% of visitors to Yahoo! have turned off JavaScript. Does this mean that we can safely forget about those who can’t use JavaScript.

Well, no. But JavaScript-required is not an accessibility problem, it’s a usability problem. As Zakas says

While the percentage of visitors with JavaScript disabled seems like a low number, keep in mind that small percentages of big numbers are also big numbers.

We spend a lot of time making our sites work with old browsers, using JavaScript shivs and polyfills but we don’t talk much about users without JavaScript. The Opera mini browser, for example, is the most-widespread mobile browser out there but, because it renders on a server, interactivity is limited (See Opera Mini: web content authoring guidelines for more information.)

How far can an application that requires Web Sockets, local storage, cross-domain messaging, canvas be expected to degrade gracefully?

Remy and I are guilty too; we talk about Geolocation, Web Workers and Web SQL in our book Introducing HTML5.

Here’s a somewhat tongue-in-cheek handy cut-out-and-keep diagram that shows what is and isn’t HTML5, and also showcases my kick-ass design skills.

If you’re not busy next week, I’m building an HTML5 page from scratch (with Notepad++ and two visual aids) at Future of Web Design in London on Wednesday.

Ultimately, in the heady world of Shakespearian romance, names do matter; if you’re name is Montague, you can’t marry someone called Capulet.

And certainly names matter in the more prosaic (but equally passionate) world of Web Standards. Until Jesse James Garrett coined the term “Ajax” we didn’t really have a phrase to refer to web applications that allowed parts of pages to be updated without refreshing the page. No matter that some Ajax depended neither on JavaScript nor XML; the name was a useful method to describe both the new techniques and the stepping-up of the users’ experience.

I find myself consistently grasping for an umbrella term to describe the new technologies available to us, such as HTML5, CSS 3, Geolocation, W3C Widgets, WAI-ARIA, Web Fonts, Web Storage, Web Sockets, SVG and the like.

I’ve been using “HTML5″ as such an umbrella term for new markup specs and APIs, but it’s inaccurate; Geolocation was never in the HTML5 specification although technologies such as Web Storage used to be until they were split out.

The orginators of the HTML5 specs, the WHATWG, have recently resurrected the term Web Applications 1.0 as a superspec to wrap up HTML5, pre-defined microdata vocabularies, Web Workers, Web Storage, Web Database, Server-sent Events, and Web Sockets.

But that still leaves SVG and CSS. The term “Web 2.0″ is too tainted by marketing BS and synergy-speak to be useful—and also seems to mean social networking, or user-generated content or any number of buzzwords.

Do you have any ideas for a sexy new term? Do we need a sexy new term at all?

Of course, we know that in the real world, most people do not have an iPhone and don’t use a Mac. This is a demonstration of the potentially dangerous belief that “my customers are the same as me”. As everyone wants to make their sites mobile-friendly, and as today sees the release of Opera Mini 5 beta, now is a good time to explain what Opera Mini is and how you design for it and test it.

What is Opera Mini?

Web browsers are hugely complex beasts. Working out the interaction between HTML, CSS, SVG, JavaScript and rendering it all is highly processor-intensive. They rely heavily on Operating Systems (which is why making cross-OS browsers like Opera and Firefox is hard).

World-wide there are 100 million or so smartphones, each of which has an Operating System that can run a full web browser such as Opera Mobile or Safari.

But there is an estimated 1 billion lower-specced phones around the globe, many of them in the developing world (but by no means exclusively so; how many people do you know with featurephones rather than smartphones? A lot, I’ll bet).

Because it’s a world-wide web, and not just a wealthy Western web, we developed Opera Mini, which works on all phones—even on the lower-end ones, as long as they support Java.

There often isn’t enough processing power to render the page on these phones, so the requests are pre-rendered on servers running Opera’s layout engine and the result is sent to the phones from the server as a heavily compressed “snapshot” of the page. It’s by no means uncommon for this to be as small as 10% of the size of the original page.

Because of this heavy compression, displaying pages on the user’s device occurs much faster than if it had processed the page itself, and for those who pay by the amount of data downloaded it’s also a huge cost saving. This compression and data saving also explains why many Western users of smartphones use Opera Mini to reduce bankruptcy-inducing data-roaming charges when they travel to a neighbouring country.

How to ensure your site works in Opera Mini

The same way that you ensure your site works in every other browser: design using Web Standards and make sure your code validates.

A useful technique for cross-browser and cross-device development are to use the Hijax methodology for adding Ajax interactions.

Don’t be immediately tempted to start building a special mobile-only verson of your site (see my ZDNet article Forget the mobile web: One site should work for all). Using CSS Media Queries, you can send reformatted screen layouts to devices according to their display properties.

Leverage those accessibility synergies!

Another secret of developing with mobile devices in mind is to consider accessibility. If you think about it, having a small screen with no keyboard is somewhat like browsing with assistive technologies.

Many people on expensive data plans browse with images turned off, so sensible alternate text gets the content to them. Many older mobile devices have limited fonts and colours, so by not using those as the sole way of giving information makes your sites both accessible and available to mobile devices.

The W3C produced a useful cross-reference that rejoices in the title Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG) which explains this in more detail.

Further resources

• Download Opera Mini 5 beta
• A developer’s look at Opera Mini 5 beta
• State of the Mobile Web reports: a monthly look at the sites and handsets used by people in different territories

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):

• I’m no PHP coder, so it isn’t pretty
• There’s no copyright (the only copyright stuff in this design are the logo and background images which aren’t in the download)
• I’ll change it on Friday and again next week
• I may change it at any time after feedback
• It’s packaged “as is”, and you’ll need to change it, although I’ve noted where it requires a certain plug-in
• It’s for educational purposes only; I make no guarantees for it and will not support it
• If you can improve it, please tell me and I’ll replace it with yours!

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:

with this:

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:

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.

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

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

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.

Therefore, although the specification is still formally in “Working Draft” status, the W3C are encouraging authors to use it now. I plan to; it’s the only game in town to add the necessary semantics to lovable old HTML 4 until HTML 5 is widely implemented.

To encourage adoption, there is a mailing list called the Free ARIA google group which you can read and join.

Opera is taking the message to the Ajax crew at the Ajax Experience conference next week, and Anne Van Kesteren is presenting “Ajax 2.0” in which he’ll introduce and demo ARIA (and other exciting things).

Speaking from my experience as a web author, though, one of the things that might slow adoption is the fact that new semantics like ARIA don’t validate against the old HTML specs. As someone who has spent half a decade badgering people about valid code, I know that lots of enlightened organisations don’t allow invalid code on their websites—and these are just the kind of thought-leaders who I’d like to see adopting ARIA.

The experimental HTML 5 validator has support for ARIA but doesn’t have the kudos of the W3C name.

So, I suggest that the W3C to add ARIA to the official validator. That would send a strong message about its commitment to ARIA, as well as allow codeshops, organisations and individuals who want validation to use it, to the immediate benefit of web users with disabilities.

Added Tues 30 September: Steve Faulkner, of the Paciello Group and member of the W3C‘s Protocols and Formats Working Group has asked if the W3C can build an a validator that can test (X)HTML and ARIA conformance.