Bruce Lawson’s personal site

When I completed the first round of my HTML 5 redesign, some validation errors remained.

Most were due to WAI-ARIA roles being applied to new HTML 5 structural elements, which isn’t currently allowed (both specs are in draft, remmeber). I’m not worried about those; accessibility trumps validity for me, and ARIA doesn’t validate in HTML 4, either.

I was also getting an odd error with Remy Sharp’s groovy HTML 5 enabling script, which I’d surrounded by a conditional comment as only Internet Explorer needs it. Part of the JavaScript has a double hyphen and HTML 5 doesn’t like “--” in comments, so fearphage sent me a rewrite that reversed the JavaScript. You don’t need to do this as you would have the script in an external file; I have it included in the head of each page so that visitors can see what’s happening.

However, none of the embedded Flash movies from YouTube would validate. I was using the default code given by YouTube which nests an embed tag inside an object tag and which doesn’t validate in current flavours of (X)HTML because embed was never in any spec.

Fearphage suggested using just the object tag for the Flash movies, but Patrick Lauke pointed out that there are some problems with that approach:

• Internet Explorer can’t stream videos but must download the full movie before showing it
• screenreaders can’t access accessibility information within the Flash movie (admittedly not likely to be a problem with most YouTube uploads)

One of the HTML 5 design principles is to “pave the cowpaths”. Because everybody uses embed, it’s been added to the spec. So by rearranging some of YouTube’s suggested code (self-closing param elements, escaping ampersands in URLs and repeating the URL for a third time as a data attribute on the object element) I came up with an accessible-as-possible, cross-browser, valid HTML 5 way to embed Flash movies:

<object width="425" height="344" data="http://www.youtube.com/v/8-pFwbHMuwA&amp;hl=en&amp;fs=1">
<param name="movie" value="http://www.youtube.com/v/8-pFwbHMuwA&amp;hl=en&amp;fs=1" />
<param name="allowFullScreen" value="true" />
<param name="allowscriptaccess" value="always" />
<embed src="http://www.youtube.com/v/8-pFwbHMuwA&amp;hl=en&amp;fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344" />
</object>

What we need now is for some kind soul to write a wizard that converts YouTube’s default code into code formatted as above.

It’s with some irony that I write this post, because one of the exciting things about HTML 5 is the video element that allows video to be added to a page with a simple <video src="blah.src" controls>I'm fallback content</video> and then plays it without any plugins or scripting. It allows an open, patent-free video codec to interact with canvas and SVG and it doesn’t require duplication of data twice or three times like the code contortions above.

Unfortunately it’s usefulness is mired in politics—see David Storey’s The future of video on the Web.

I’m too lazy to amend every instance from the last five years, but my home page is now valid apart from ARIA roles and an objection to the feed: protocol on a link to my RSS feed.

Thanks Patrick and fearphage.

Not so much a blog post but a collection of links.

UK government browser guidelines: good sense prevails

The Web Standards community changed some guidelines for government webmasters that would encourage designing to browsers into something that requires valid code, web standards and progressive enhancement. UK government browser guidelines: good sense prevails.

Talking of guidelines, I’m doing a short talk on Wednesday about BS 8878: Web accessibility – Building accessible experiences for disabled people at the Oxford Geek Night. See you there?

How Can I Validate (X)HTML + ARIA?

A while ago I speculated that the lack of a validator for ARIA might slow adoption. Steve Faulkner has written a proof-of-concept HTML4+ARIA Checker and hopes, as I do, that “the W3C validator adds support for (X)HTML +ARIA documents so I when check a document and it contains no errors in the HTML (except for the use of ARIA) and ARIA code, I see a message like this: this document was successfully checked. Passed (1 Warning)”

Should you think that ARIA is just w3c vapourware, there’s a podcast on ARIA by Freedom Scientific (the manufacturers of the JAWS screenreader) available:

Freedom Scientific’s Chief Technical Officer Glen Gordon explains ARIA and its benefits. Jonathan Mosen then demonstrates some applications with ARIA enabled for improved accessibility.

Didn’t see a transcript anywhere, surprise surprise.

More bandaids for microformats

Pat “Herb” Lauke wonders “if we should have an official anniversary each year where the same microformat/accessibility issue is rehashed” and links to an experiment by Andy Clarke. It’s a nice idea, but I think it’s a bandaid. I agree with Isofarro’s diagnosis:

It boils down to this: the title attribute is meant for human consumable content, just the same as the inner text of most of the HTML elements.

Everytime you put machine-formatted data into a container that is for human consumption, then you run the risk of it being exposed to a human being. In microformats this a ‘feature’, in accessibility this a ‘bug’.

I think that’s throwing the baby out with the bathwater to say “the easiest approach right now is to say Microformats are inaccessible, and move along”; it’s just this pattern that’s inaccessible.

Patrick suggests, “why not make a ‘title attribute’ pattern that allows for the use of the most semantically appropriate element? span with title in cases like datetime, abbr when it is actually an abbreviation.”

That makes sense to me. How would those plugins that make use of microformats cope if I marked up hCalendar dates with a span. Anyone know?