Future Web Accessibility Updates

It’s been two months since my first Future Accessibility article, and less than a week since my most recent one, yet several exciting new developments have already made some of the things discussed in the series outdated or incorrect. Here, briefly, are some of those recent changes.

For reference, HTML5 <video>, HTML5 Semantic Elements, New <input> Types in HTML5, HTML5 <input> Extensions, SVG, and canvas.

HTML5 <video>

When I wrote about HTML5 video, the biggest accessibility concern was the lack of any caption or subtitle support in the HTML specification itself, requiring anyone who wanted captions to hack their own system on top of the native video playing capabilities. Work has been progressing somewhat rapidly in that front, and although the solution is still a work in progress, we at least know that it will be present and have a pretty good idea of what it will look like.

Well, sort of. The solution described below is currently only part of the WHATWG’s HTML5 spec, not the W3C’s, so it remains to be seen if some sort of a compromise will yet be worked out to bring both versions of the specification into alignment on this issue.

Specifically, the HTML5 media caption format is called WebSRT, and is a superset of the existing popular SRT format for media subtitles. WebSRT extends SRT by adding some style and mutilingual support not present in the original SRT, while maintaining compatibility with existing SRT files. To go along with this, a new <track> element (and corresponding script API) has been added to HTML5, allowing an arbitrary number of multilingual captions, subtitles, descriptions, and other text-based meta-data to be attached to a specific HTML5 <audio> or <video> element.

No browser has support for any of this yet, since the specification is still being written and debated, but it’s definitely progress.

SVG

In my article on Scalable Vector Graphics, I wrote that “each [user agent] implements a different subset of the spec—no browser (that I know of) has complete support for the full SVG syntax”. Several readers notes in the comments that the current situation is slightly better than this makes it sound: although it is true that each browser implements a different subset of the SVG spec, all major browsers (including the latest preview edition of Internet Explorer 9) implement correctly all (or almost all) of the “core” important things, with the unimplemented features usually being the fringe stuff nobody cares about anyway. (I’m paraphrasing them a bit, but that’s the general idea). In other words, using SVG on the open web in a cross browser way will definitely be a possibility very soon.

Canvas

The most exciting update of all happened just last night, when Microsoft released the newest “Platform Preview” of the upcoming Internet Explorer 9, which contains (happy surprise) nearly complete support for the <canvas> element! Not only that, their hardware accelerated graphics support result in what I’ve been told is the smoothest, fastest <canvas> implementation to date. This means that full cross-browser canvas on the open web will be a reality in the next few years, not a hypothetical.

In the accessibility world, the “extend image map” canvas accessibility proposal has been endorsed by all the major browser vendors, but there are still some objections to it in the HTML5 world. If it is accepted into the spec, it is apparently being planned as an addition to, not a replacement for, the other “shadow DOM” proposal. It’s still too early to tell how this will be resolved, but the discussion is very active (this was all being discussed yesterday), so it’s certainly on track to be figured out sooner rather than later.