Archive for July, 2009

Accessibility of HTML 5 video

Philosophically, the accessibility of HTML 5 video is a beautiful thing.

There is no fall-back accessibility content; instead, it’s just a link to the video and, perhaps, a transcript:

<video src="movie.ogg">
Your browser is not video-enabled; <a href="movie.ogg">download the video</a> and <a href="movie.txt">transcript</a>.

There is no “alternate text” attribute. Instead, each video is expected to carry its own synchronised captions—not “burned onto” the video, but in some kind of time-stamped text file so the browser can access it and display it over the video for users who require it. As an added bonus, search engines would be able to access this information.

The reason is good. Many videos are hosted in one place (for example, YouTube, DailyMotion etc) and embedded in many other sites. It’s highly unlikely that people embedding those videos would copy accessibility information, so it’s better that the video creator bags it all up together.

But what format to use? Given that discussions about the best video codec at an impasse, discussions about accessibility formats are unlikely to advance. This is not a fault of those who specify the language; it’s a problem of codecs, patents and closed standards vs open standards. (Related: Video of open video codecs discussion at Mozilla, and Mozilla’s General Counsel on Theora patents.)

But the situation is urgent. Sasquatch-wrestlin’ John Foliot writes that in the USA the The Twenty-first Century Communications and Video Accessibility Act of 2009 was introduced last month, and if enacted, big video sites like YouTube would might need to provide captioning (that’s obviously something for the lawyers to work out).

In an excellent post The most pressing Accessibility issue in HTML5 today? <video> (which I urge you to read), John describes how captioning, like video itself, can already be accomplished through plugins.

If HTML 5 video is going to catch on (and we all hope plugin-less video that can be manipulated with scripting, integrate with canvas and SVG will catch on), it needs to be able to compete with plugins, especially if The Twenty-first Century Communications and Video Accessibility Act of 2009 looks close to becoming law.

Meanwhile, Sylvia Pfeiffer is plugging away at adding captioning to HTML 5 video, and is looking for your feedback.

Added January 2010: I made a demo of HTML5 video with accessible captions, taken from a transcript and synchronised with JavaScript.

(Last Updated on 27 January 2010)

Hip hip hooray for San Jose


I flew in, dazed and confused, on Tuesday night and only managed to see the first morning of OSCON before I had to crash for a couple of hours in the afternoon, but I did get to see Jono Bacon present on building communities around Ubuntu – very relevant to my line of work and very interesting.

Tuesday night saw me in an iridescent lime-green t-shirt at the Linux Fund party, where I drank more than I should have (but not as much as Stuart Langridge, so that was alright).


Thursday saw me zipping up to Stanford University with the Sasquatch-wrestling John Foliot, where I gave a lunchtime presentation on HTML 5 (.ODP, 2MB) which was very well-attended. I also got to meet James Craig, after working with him online for a few years.

Then it was back to San Jose for dinner at the invitation of Google. It was odd to be surrounded by giants of the Open Source world, many of whom I’d never heard! Likewise, one guy I was talking to was developing a browser but had never heard of Zeldman—odd how two worlds coincide while rarely touching (Langridge is the only guy I can think of who passes easily between them). Swag was excellent at the Google party: an unlocked developer’s G1 Android phone. I can’t wait to get back to the UK to try it and download Opera Mini for Android.


Having woken up feeling fine, through the clever gambit of not drinking loads the night before, it was time to wander in and give my presentation. I felt fine until I was told that I was moved to the huge space where they do the keynotes because so many people had signed up to see me (about 120 expressions of interest).

My nerves were further shot when I tried to edit out a joke that I decided at the last minute wasn’t going to work, and Open Office crashed—2 minutes before I was due to start, leaving me to do ctrl-alt-delete and go into document recovery mode in front of an audience watching it broadcast on 4 huge screens.

Anyway, the talk went well, with some great instant feedback via twitter, and I didn’t do my usual trick of over-running.

If you’d like to grab my OSCON HTML 5 presentation (.ODP, 2.7MB), please do. Here’s my OSCON HTML 5 presentation video (FLV, 45 mins).

Getting beaten up by Open Source people

I confess that I was nervous, too, about presenting to a lot of very active Open Source coders as the rep of a closed-source company, on a Windows machine. (In my defence, it’s a dual-boot Ubuntu/ Windows machine and I needed to demo Internet Explorer).

I’m delighted to say that I had nothing but friendship and courtesy from all attendees, who applauded the fact that Opera evangelises, develops and follows Open Web Standards. I’d like to thank all those who made me feel so welcome; it was an honour to meet you.

San Jose, Stanford, OSCON photos.

(Last Updated on 30 July 2009)

HTML 5 is a mess

HTML 5 is a mess”, said John Allsopp.

I agree. It is. It’s also several different kind of messes, not all of which are avoidable or bad. Let’s look at them.

The backwards compatibility mess

The first kind of mess is because it builds on HTML 4. I’m sure if you were building a mark-up language from scratch you would include elements like footer, header and nav (actually, HTML 2 had a menu element for navigation that was deprecated in 4.01).

You probably wouldn’t have loads of computer science oriented elements like kbd,var, samp in preference to the structural elements that people “fake” with classes. Things like tabindex wouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, and accesskey wouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.

But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. This page is written in HTML 5, and although your browser doesn’t “understand” it, it it still renders it.

There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.

That’s one reason why HTML 5 a mess. It’s built on a mess.

The process mess

Specifying HTML 5 is probably the most open process the W3C has ever had. Different groups with different interests battle it out over the mailing lists. Competing variant specs are springing up: Manu Sporny is devising a spec that incorporates RDFa in HTML 5, while The Mighty Steve Faulkner is writing one addressing accessibility issues including alt text and summary attributes. I’m hopeful that these will all be merged together, while simultaneusly, parts of the spec are being split out into separate specifications where there are no dependancies, such as Web Storage and Web Database.

This amorphous process is messy. But, in my opinion, infinitely better than the ivory tower of XHTML 2 academia.

The spec mess

Then, of course, there’s the real mess that John Allsopp and Matt Wilcox complain about—imprecise, ambiguous specification or unnecessary restrictions.

Why the restrictions on the time element? Why the overlap between figure and aside?

Why is the nav element so loosely specified? (“Only sections that consist of major navigation blocks are appropriate for the nav element”—define “major”, if you please.) Why can you have nav inside a header and not in a footer?

If these things bother you, you can do something about itemail the Working Group and make your feelings known.

Post-publication clarifications

I should clarify two things after some tweets and a Skype conversation with Lachlan Hunt. The first is in fairness to Hixie: he changed the definition of nav to clarify that there can be more than one per page, and I agreed that the new defintion was an improvement. But, as I’m a self-confessed dimwit, I only realised later that the word “major” leaves ambiguity as well. So that’s my brain parsing slowly, not Hixie’s bad.

Secondly, and most importantly, I haven’t had some kind of damascene conversion to the anti-HTML 5 camp. I firmly believe that it’s the best way forward for an Open Standard that allows us to write richer web pages and applications. And I’m sure that no-one, especially those in the Working Group, believes it’s perfect already. In fact, the Working Group consistently call for developer participation in reviewing the spec.

To reiterate: bitching in blogs (like I’m doing now!) and on twitter is OK, but the best way to be sure that your views are heard is to mail to Working Group.

(Last Updated on 28 June 2010)

The saddest photo I ever took

Leafing through an old photo album last night, I found this old picture.

I was walking through Plymouth Road cemetary, Redditch on a summer evening in 1991 and saw this tiny hand-assembled wooden cross, roughly nailed together, with “RIP Micheal 9 Months” written on it in permanent marker.

Who was he? How did he die? And what were the circumstances of his meagre memorial?

Canvas, accessibility and SVG

Since watching Steve Faulkners’s presentation about HTML 5 accessibility, I’ve become more interested in the accessibility of the canvas element. canvas is a method of producing dynamic graphics with JavaScript:

The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.

As a nice illustration, here’s an example of Super Mario in 14K of JavaScript.

No matter how sexy they are, however, they’re just graphics, with the accessibility complexities that can entail. In the specification, there is a very basic way of providing "fallback content":

When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element’s fallback content.

This is as basic as

You're too damn blind to use this bit

Now, this is all well and good if you’re just drawing a simple image whose contents you know and can describe in advance, or using jQuery to dynamically draw graphs of data from a data table, but what happens if you’re using it as a text editor like Bespin, or even making UI controls like Note the latter has a simple link at the bottom "plain HTML version". In 2009, parallel "screenreader pages" are unnacceptable.

(I’m not really blaming the developers of these pages; the lack of accessiblity fallback is inherent in the specification, although the second example could be done with SVG, an image map, or with good old fashioned HTML, CSS transforms/ transitions and JavaScript).

Indeed, the spec does warn against misusing the canvas element:

Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies.

I’m pleased to see that the HTML 5 cabal are discussing this and the HTML 5 editor, Ian Hickson, is seeking advice from the W3C‘s Web Accessibility Initiative. The Mighty Steve Faulkner has been giving it some deep thought. Here’s a very thorough investigation of accessibility issues problems in canvas.

canvas or SVG?

There is another, longer-established standard for drawing graphics on the screen, Scalable Vector Graphics (SVG). This is supported on the same browsers that support canvas (that is, all except Internet Explorer) but is a much more mature technology. As it’s an XML-based language, it is text-based and thus is inherently accessible. Screenreaders don’t support it yet, probably because the big screenreaders have traditionally sat on top of Internet Explorer, and also because they are the Netscape 4 of assistive technologies—last I heard screenreaders don’t support strong or em.

I expect in the coming months we’ll see lots of unnecessary uses of canvas over SVG, in the erroneous belief that “Canvas is cooler than SVG" and it’ll be like Flash was in 1999. Ah well. At least we can hope that the Working Group can make this new "skip intro" accessible.

Update Monday 20 July:

The [W3C‘s] Protocols and formats working group discussed the issues of canvas accessibility in their HTML caucus meeting last friday (17/07/09). It has been decided to form a task force to work on specifying additions to the CANVAS API, that will result in canvas content being natively accessible.

(Last Updated on 20 July 2009)

On Google OS

I’m a Web Evangelist for Opera, but this post does not represent the official Opera position.

So it’s no surprise that Google announced its Operating System:

we’re announcing a new project that’s a natural extension of Google Chrome ”” the Google Chrome Operating System. It’s our attempt to re-think what operating systems should be…Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks…Speed, simplicity and security are the key aspects of Google Chrome OS. We’re designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds.

As I wrote when they released the Chrome browser,

It seems to me that Chrome is designed to compete with Microsoft Windows as an Operating System and Office as an application: Microsoft’s biggest revenue earners (as far as I know).

For my wife, Dad and daughter, this is sure to be a winner. I already use my family’s Linux netbooks in preference to my own laptop for going on to the Web to check a sports result or train time, as their Acer Aspires take 15 seconds to boot up; my Vista laptop takes minutes.

So now Google dominates search, maps and will be running an Operating System (confusingly named identically with its browser). Why wouldn’t they want to do that? They believe, as I do, “for application developers, the web is the platform”.

Let’s not forget that Google also provides many Web applications – its docs suite, its maps, its analytics tools.

The Google annnouncement goes on to say

All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser.

It would be wrong if Google apps only ran on Chrome and Firefox on the Google OS (will it be possible to install another browser on machines running Google OS?) so I read this announcement as an implied promise that Google’s own apps will be tweaked to run across all standards-compliant browsers, including Safari and Opera. That would be a win for the Open Web.

Better UK citizenship test questions

I tried the UK citizenship test and failed, even though I’m am a history buff and a lifelong UK citizen. In my defence, the questions are crap. How do I know when women got the right to divorce, or whether “Methodist” means Church of England?

I propose these as some better questions:

  • Which avuncular sports presenter was later found to be consorting with prostitutes and snorting coke? Gary Lineker/ Dickie Davis/ Frank Bough/ Jimmy Hill?
  • Do chips come with gravy in Ireland/ North England/ London/ Isle of Man?
  • Fill in the blank: Monty Python’s [blank] [blank]
  • At a pantomime, what is the correct response to a character saying “Oh yes it is”?
  • Which is NOT a genuine Enid Blyton group of fictional child detectives? Famous Five/ Five Findouters/ Six Sleuths/ Secret Seven
  • How long is drinking-up time?
  • Which of these was NOT a Blue Peter presenter? Konnie Huq/ Sophie Ellis Bextor/ John Noakes/ Peter Purves
  • When did England last win the World Cup?
  • Which of these was never a member of the Beatles? Paul McCartney/ Pete Best/ George Best/ Stu Sutcliffe
  • “Neeps and tatties” means what in Scotland? Turnip and potato/ coats and hats/ neat and tidy/ Did you call my pint a pouff?
  • Which series is set in Wetherfield/ Albert Square/ Ambridge?
  • Which is welsh: Thomas the Tank Engine/ Ivor the Engine?
  • Which comedian had “short fat hairy legs”? Bobby Ball/ Syd Little/ Ernie Wise/ Bernard Manning

Got any to add?

(On a serious note: I’m bloody glad my lovely missus got her citizenship before this silly test came out.)

Goodbye XHTML 2

Sing with me! (Midi backing track):

Goodbye XHTML 2, though no-one ever used you at all
you had the grace to hold yourself
when all around you had a fighting chance of getting implemented.
And it seems to me that you lived your life pissing in the wind…

The W3C has pulled the plug on the XHTML 2 specification. This was a philosophically pure specification that was so backwardly incompatible that it nearly deprecated the img element. But this incompatibility, the draconian error handling that XML requires and the fact that XHTML 2 was for documents and ignored web applications doomed it to failure as a method for delivering content to browsers.

What does this mean to you?


Your current XHTML 1.x sites still continue working (except in IE, if you serve them as XML rather than HTML).

You wanna use XML? Then use XML. For those interested in HTML 5, I draw your attention to an article that I presciently wrote yesterday on XHTML 5, for those who worry unnecessarily that XML has been killed.

HTML 5 took some good ideas from XHTML 2 – the idea of deriving the “level” of a heading from its context, although it preserves using h1h6 for backwards compatibility rather than a generic h element. XHTML 2 allowed “href anywhere” so anything can be a link, and HTML 5 has a similar idea, although it preserves backwards compatibility by allowing the a element to surround block-level elements. The XHTML 2 element nl for navigation list is doubled in the HTML 5 nav element that wraps a ul or ol.

The main side-effect of the end of XHTML 2 is that its resources will now be given to HTML 5. It also adds to the pressure to include RDFa into HTML 5 (Microformats, being elements and classes, “work” already). Given that Google (the employers of the HTML 5 spec editor, Ian Hickson) and Yahoo are starting to use microdata, it’s almost certainly untenable to claim there are no use cases for it, and RDFa is already a W3C specification, albeit ugly to write and opaquely documented.

Further reading (with no singalongs)

(Last Updated on 8 July 2009)