I’ve known Molly since 2001. She was a journalist covering a Wrox XML conference I was helping run in Las Vegas. A colleague of mine, Karli Watson had a quickie, tacky Vegas wedding and Molly and I attended.
Two years later, I was searching for someone to co-author a book with me about usability, and found Molly. We were both unaware that we’d met before until halfway through our collaboration. Usability: the site speaks for itself sold poorly (and taught me some vital lessons about web developers and how they differ from programmers) but it cemented my friendship with Molly. She’s been to my house, eaten my evil chicken, charmed my children (“a real American!”) and helped me drink a bottle of vodka.
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.
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&hl=en&fs=1">
<param name="movie" value="http://www.youtube.com/v/8-pFwbHMuwA&hl=en&fs=1" />
<param name="allowFullScreen" value="true" />
<param name="allowscriptaccess" value="always" />
<embed src="http://www.youtube.com/v/8-pFwbHMuwA&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344" />
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.
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)”
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?