The HTML 5 spec was originally called “Web Applications 1.0″. Most of the attention has been on the new markup elements, but in his talk he takes a further look at the applications side of the spec, covering:

1. Dynamic images and graphs with canvas
2. Eliminating much forms validation with webforms 2.0
3. Local storage automagically saving your data
4. Geolocation
5. Building toolbars and menus.

Editor’s Note: We’ll be covering “How HTML 5 is Going to Completely Change your Web App” at The Future of Web Apps in Miami.

You can jump straight to the video, view the slides, read the transcript (thanks @joeloverton for doing this!), or check out the resources he demos in the talk:

• Eye-candy canvas
• canvas first-person shooter
• canvas first-person gifter
• the excanvas library to port canvas to Internet Explorer
• Filament Group’s jQuerty plugin using canvas for graphing data tables
• Raphaël JavaScript Library to make SVG that also works in Internet Explorer
• SVG Web is a JavaScript library which provides SVG support on Internet Explorer (Alpha code: not ready for production)
• My HTML5 forms demo, including range, date, placeholder, regex validation (Try in Opera and Chrome)
• modernizr – A small HTML5 capability detection library
• HTML5demos.com – Remy Sharp’s demos of geolocation, offline storage and web database and many others
• Video demos

Other useful resources:

• SVG vs. Canvas on Trivial Drawing Application: a comparison of canvas and SVG
• HTML5 Authors spec
• A video of Dean Edwards demoing his unreleased JavaScript library that detects and plugs the holes in current browsers’ HTML5 support

There are some great beginner canvast tutorials on the Opera Developer:

1. HTML 5 canvas – the basics
2. Creating an HTML 5 canvas painting application
3. Creating pseudo 3D games with HTML 5 canvas and raycasting
4. Creating pseudo 3D games with HTML 5 canvas and raycasting: Part 2

The video

Full transcription available at joeloverton.com/html5. We’d like to say a HUGE thank you to @joeloverton for doing this transcription!

The slides

So this article is for the suits who care: if you can’t use cutting-edge tools, technologies or techniques, what can you do to ensure that you’re doing all you can for all of your users? My tried-and-tested method is:

1. Get buy-in from the top
2. Some accessibility is better than none
3. Educate your content providers

Get Buy-In From the Top

The last major redesign project I was involved with was successful from an accessibility point-of-view because we had buy-in from the board. Having convinced the top brass of the need for accessibility we wrote a “constitution” for the new site that says all content must be accessible to people with disabilities, and where this clashes with aesthetics or organizational convenience, it trumps them. If you read it, you’ll see that I’ve sneaked in some accessibility-related rules under a different guise.

The CEO then sent this to all the directors. The advantage of this is clear: when a content owner is exasperated at the time you spend marking up a long important document rather than simply linking to a PDF of the Word document they gave you, you can just point out that you’re just doing what you’re told and invite them to complain to the CEO.

Achieving Buy-In

One problem with corporate accessibility is that while corporations generally care about accessibility in the abstract (because they don’t want to get sued, and they don’t want negative publicity), they don’t actually understand how to show that they care. In my own experience, working for a UK legal regulator, accessibility is seen as a legal compliance issue (”does this comply with the DDA?”) which can lead to a grudging attempt to be accessible, because a corporate lawyer will naturally try to do the minimum required to stay in compliance; minimizing risk while minimizing costs.

The way to overcome this is to focus on the customer. I find the following arguments successful in getting accessibility discussed in a positive, “good-to-have” way rather than in a legal compliance “oh-well-if-we-must” way:

• Accessibility is good for Search Engine Optimization (SEO)
• Accessibility enhances usability for everyone. An April 2004 formal investigation into UK web accessibility (PDF) reported "all users, not just disabled people, would benefit greatly from the measures required to make sites accessible and usable by blind people".
• Accessibility has many quantifiable business benefits (PDF). Legal and General, a British financial services company, redesigned its site with accessibility in mind and found:
  • 40% traffic increase
  • Doubled conversion rates
  • Doubled online revenue
  • 100% ROI in 5 months

Some Accessibility is Better Than None

I often see standardistas boast "I don’t care about accessibility" because it’s assumed to be inherent in standards-based development. (I doubt that’s true if you’re making Ajax pages, as you’ll need WAI-ARIA attributes to be added to HTML elements in order to ensure accessibility).

But that is based upon the premise that your web infrastructure and office politics mean that you’re able to do standards-based development. Assuming you have a website that deals with the storing, manipulation and display of company data, you’ll need a CMS of some kind. The best code is produced by the best CMSes, and many of those are unavailable to corporate developers because:

• they’re open source and most corporate IT departments don’t like open source, due to perceived "risk" and lack of someone else to shout at if there’s a problem
• they are free or very cheap (this is why start-ups often have better tools than big corporates with deep pockets: they use the free ones like WordPress, PHP, Rails, Drupal, etc. because they have to)
• they are very new and don’t have a pedigree that reassures those whose job depends upon procuring the right CMS
• there’s a feeling that they can’t possibly compete with costly behemoths like Sharepoint, Teamsite, Vignette (AKA "no-one ever got sacked for buying Microsoft")

We could talk all day about why terrible tools are so prevalent. (In my experience, the reason why a terrible tool isn’t replaced is because someone senior paid $500,000 for it and sure as hell isn’t going to admit a mistake and scrap it.)

Working Around Bad Tools

The terrible tools can hamper your efforts to be accessible in several ways. One of the worst ways it can do this is by having some archaic WYSIWYG editor that allows authors to cheat and make “headings” by choosing size and colors which are translated into font tags on the front end, and therefore there is no structure for an assistive technology user to navigate by.

You can cure this by with a CSS rule that naughtily over-writes the tag: font {color:red; font-size:xx-large; text-decoration:blink; background-color:yellow;} which means content authors see hideous flashing text. It will, I guarantee, encourage them to write proper headings.

Sometimes, terrible tools have to be worked round. You might never be able to get 100% valid code, or remove all the nested tables that you’ve added into pages just to stop them looking atrocious.

But that doesn’t mean that you won’t make a difference if you do what you can. While I was working on The Law Society website we had thousands of pages in the CMS that were full of <font> tags, double-<br>s to separate paragraphs and some table layout. Even if we could have run a script over the proprietary database to change those, it wouldn’t have been good use of our time, as every page would still need to be manually verified.

However, the site-wide header and navigation was controlled by a single include file, so we amended that to change the navigation from elaborate tables with <img alt="bullet"> to be a CSS-styled unordered list. It would be easy, with such an architecture, to add some WAI-ARIA document landmark roles to help screenreader users. These changes were comparatively simple and made screenreader users’ lives much easier. The site will never validate, or win a clean code award, but it’s more accessible than it was.

Incrementally Improve the Code

So you know you have loads of bad markup and “imitation” headings lurking around, but fixing them all will take too much time and effort. Sort out the biggie pages, such as the home page, “contact us” page, “about us” page and the other top 10 high-traffic pages (check your server logs) straight away.

Whenever any other page needs any kind of editorial amend, take a few minutes when the page is open for the editorial change to correct the markup, too. You’ll find that the most commonly updated pages will be corrected first, and they’re very likely to be most-important or most-visited so a sort of "accessibility through natural selection" process takes over.

Educate Your Content Providers

Most big corporates have multiple people throughout the business submitting content for publication. Generally, they aren’t web specialists and submit their content in Microsoft Word format. It’s vital to give them a Word template that defines the styles they can use for bullets and numbering, etc., so they don’t get a nasty surprise when they see that their lovingly-created purple lightning-strike bullets haven’t made it onto the website.

Consider organizing half-day training sessions on how to use Word styles so that headings are methodically created rather than imitated with font size and bold. This pays off as there is no ambiguity if you’re having to mark up their content by hand. (I would have killed for a Word macro that converted documents into HTML with no style information, only the structural information. If you know of one, please tell the world!)

If you have to publish in PDF format, it will be more accessible if it’s made with a proper Word structure. (Adobe has published a useful cheat sheet on how to author Word files for conversion to more accessible PDF.)

Get Your Content Providers Writing HTML

Go mad! Dream big! Turn off the WYSIWYG, throw away Word and train your content providers to deliver you HTML. Most web content (as opposed to headers, navigation, forms, etc.) consists of a few conceptually simple elements:

• headings
• paragraphs (including abbreviations)
• links
• bulleted/ numbered lists

So train people to send you the content ready-marked up. It won’t be perfect, but it’s simple to run it through HTML Tidy to make it validate. It will be shorter and better-structured if they have to consider the heading hierarchy. Of course, you will still need to add the more complex elements like images and data tables yourself, but they are rarer, so your workload will diminish, their control over the content will increase and your users will get a more accessible website.

Accept the Compromises

It’s hard, when you’re a professional, to accept that something you produce is less than perfect. But all web design is a compromise: liquid layouts versus line length, design versus page weight, and so on. Complete accessibility is never completely achievable as there is such a vast range of needs. So, be a zen master and accept the compromises: simply by caring and trying to do what you can, you’ll make your company’s website more accessible and lives of your disabled visitors easier.