Bruce Lawson’s personal site

HTML5 video, canvas accessibility, microdata

As I sit here in Austin, Texas munching a breakfast of bafflingly-termed foodstuffs like “eggs medium over-easy”, “white omlette” and incorrectly-pronounced tomatoes, I thought I’d update you on a few HTML5 tidbits.

The first is the news that Google will start indexing content marked up using microdata. No browser does anything with data it finds in pages, but the voodoo magicians that do SEO will presumably find the chance of extra googlejuice compelling.

You can have a play using @foolip‘s JavaScript microdata implementation (work in progress; the lad has other things on his mind). I was chatting to Tantek Çelik last night, and he said he’s looking to add some microdata support in microformats.

I’m a lurking member of two W3C subgroups that work on the accessibility of video and canvas. We recently had two internal votes. The first was on what type of captioning format should be supported, and asked us to choose between the .srt format (a plain text file with time markers and text) or the W3C standard DXFP which, although minging, allows markup. (.srt seems to me to be as limited alt text on an image; it can’t contain markup or styling information). I voted for DFXP because, at its most basic it doesn’t need to be more complex than plain .srt, but has the potential for extensibility when browser implementations become more sophisticated. (My vote was a personal opinion and not an official Opera vote, by the way.)

The second vote that’s taking place is about extensions to canvas. There are two main proposals, one is for a new attribute called adom (for “accessibility DOM”) that constructs a “shadow DOM” for assistive technologies can hook into – and which the author must ensure is in sync with the visual rendering. I’m uncomfortable with this proposal for reasons that I’m not quite able to articulate at the moment (but its author is at South By Southwest so I hope to be able to catch up with him for a chat).

The proposal that I like is to extend canvas is “Improve image maps, don’t use @adom” which I favour because it uses familiar markup and reuses ideas from (and browser implementations of) HTML4. (Disclosure: the proposal was made by Chaals, Head of Standards at Opera, but that’s not why I prefer it.)

The Mighty Steve Faulkner also has a proposal Provide accessibility implementation for focus rectangle and caret, which I haven’t read yet. But it’s Steve, and his shit is solid.

Anyway, gotta go and shower my pits before booth-bunnying the Opera South By Southwest booth. It’s in row 300 of exhibition room 4. Why not stop by a chat, especially if you’re a gorgeous Web Standards babe, or have a black coffee for me? Alternatively, I’m first speaker at an HTML5 extravaganza on Sunday from 2 to 6 pm.

7 Responses to “ HTML5 video, canvas accessibility, microdata ”

Comment by steve faulkner

hi bruce,
in regards to canvas, the adom idea has gone it has been replaced with a navsubtree proposa = still being written up. Rich is working with chaals to merge the the navsubtree and image map prposals.

The substance of third 3rd proposal, which you attribute to me is Rich Schwerdtfegers work. This work is not an alternative to chaals. What it does is address the vagueness of the current spec in relation to interoperability with assistive technology, it clearly specifies that browsers must expose caret and focus information, on a canvas, via an accessibility API (e.g. msaa, iaccessible2).

Comment by AlastairC

“a ‘shadow DOM’ … I’m uncomfortable with this proposal for reasons that I’m not quite able to articulate”

Perhaps because invisible aspects like this (virtually) never get added.

Take any Flash site where accessibility wasn’t a prime concern and check the tab-order of elements. It is basically random, as people don’t specify it.

Could the structure aspect needed be used for other things as well? Things that people attend to more, e.g. SEO.

Comment by steve faulkner

alastair wrote:
“Perhaps because invisible aspects like this (virtually) never get added.

Take any Flash site where accessibility wasn’t a prime concern and check the tab-order of elements. It is basically random, as people don’t specify it.

Could the structure aspect needed be used for other things as well? Things that people attend to more, e.g. SEO.”

the canvas API provides no means to add focusable content or add semantics, it is only a drawing API. everything must be done using scripting. allowing elements in the canvas subtree to be focusable provides a method for developers to add interaction using html elements which provide the focus, name, role,state and value information to accessibility APIs that would otherwise have to be totally scripted ie not possible, so it will be a method for developers to add interaction for all users, not just for accessibility. Allowing image maps to be defined for canvas also does this, but it does not provide the same scope of interaction. i envisage that for most purposes defining an image map will suffice, but for those cases it does not, adding elements to the subtree will provide that extra richness. the mix of image map and subtree are the closest we can get, considering the limitations imposed by the canvas API.

Comment by AlastairC

Thanks Steve, I haven’t been following HTML5 (and related stuff) closely, but what I do notice has obvious parallels with Flash issues a few years ago.

Building accessibility into the default path that developers would use (e.g. for interactivity) always seems to be the best approach, so having something called ‘accessible DOM’ rings alarm bells..

Comment by Daniel

Yes, I have problems with anything that reads “Ghetto special-edition content” – even if it is rated as “Platinum Premuin Edition”.

As we all know, Accessibility should be no add-on: it’s an assumed.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.