Last year, I put together a talk called “Invisible Visualization” on making accessible data visualizations. Several people have asked me about it, so I thought I’d write a post about it.
By “accessible”, I mean able to be consumed and understood by people with a variety of sensory needs, including people with visual limitations, cognitive impairments, mobility challenges, and other considerations. I provided a few simple ways to expose the data in SVG images, but mostly I described different constraints and suggested ways of thinking about the problems.
I didn’t want to lecture people about the need for making their content accessible; I wanted to excite them about the possibilities of doing so. It’s great that there are legal regulations addressing the needs of people with disabilities (like the “Section 508” laws here in the US), but that’s not going to empower and motivate developers and designers to want to meet these kinds of design constraints and solve these kinds of technical challenges. I sought to avoid the “threat and guilt” trap that I’ve seen too many accessibility talks fall into.
This week is our first Geek Week at W3C. The idea is to have a week where we improve our skills, collaborate with each other on prototypes and fun projects that help W3C, and to come up for air from our everyday duties. I’m working on a few projects, some small and some larger.
One of my projects is to make a plugin for Thunderbird, my email client of choice, which exposes the Archived-At email message header field, normally hidden, as a hyperlink. This is useful for W3C work because we often discuss specific email messages during teleconferences (“telcons”), and we want to share links to (or otherwise find or browse to) the message in W3C’s email archives. It’s also handy when you are composing messages and want to drop in links referring to other emails. (I do way too much of both of these.)
I’ve made extensions for Firefox before, but never for Thunderbird, so this was an interesting project for me.
There has been a heated argument recently on the W3C Canvas API mailing list between accessibility advocates and browser vendors over a pretty tricky topic: should the Canvas API have graphical “objects” to make it more accessible, or should authors use SVG for that? I think it’s a false dichotomy, and I offer a proposal to suggests a way to improve the accessibility potential of the Canvas 2D API by defining how SVG and the Canvas 2D API can be used together.
This brings together some ideas I’ve had for a while, but with some new aspects. This is still a rough overview, but the technical details don’t seem too daunting to me.
Last week, I published the first draft (and subsequent updates) of the Web Interface specification, which defines touch events. This is the first spec from the new W3C Web Events Working Group.
Peter-Paul Koch (PPK) gave it a positive initial review. Apparently, others thought it was news-worthy as well, because there were a few nice write-ups in various tech sites. Naturally, cnet’s Shank scooped it first (he has his ear to the ground), and it was fairly quickly picked up by macgasm, electronista, and Wired webmonkey.
I thought I’d go into a few of the high-level technical details and future plans for those who are interested.
I was involved in rolling out the new HTML5 logo for W3C; I wasn’t the person in charge, but I helped out with some aspects of it.
The interesting thing to me was the reaction to the logo, aesthetics aside. (I like the logo personally, but I also like the retro-futurism of Soviet Realist art, like the statuary in Memento Park in Budapest, and comic books.) I loved the parodies and jokes about the logo, but I was both unsurprised and disappointed at the some of the negative dialog (and in some cases, monolog) about what the logo is meant to represent.
Text in SVG is text. Visually, you can use webfonts like WOFF or SVG Fonts (where they are supported, like in Opera or the iPhone) to make it look cool, and you can style both the stroke and fill to make it all fancy, or apply filters to pop it out or make it glow or give it a dropshadow, but it’s not just a raster image like many text headers… it’s human- and machine-readable text, as nature intended.
So, SVG is translatable, right?
Mozilla is holding an Open Web Games competition. I expect that many of the games will be use the Canvas API, since many programmers are more familiar with the imperative programming mode, and there are some games libraries that have been developed for Canvas or adapted from existing drawing or gaming libraries.
But I’m calling for SVG developers and designers to step up to the plate, as well. SVG has a lot of features that make it easier out of the box to build interfaces, animations, and even games. There is a scene graph, and the DOM event model that gives you free hit detection for pointer events, for example. And I’d love to see someone make an open-web game that’s both accessible and fun…
To help developers along, I thought I’d share a few free, open-source SVG resources that could be useful in building games:
With SVG being integrated more and more into HTML5, both included via
<img> elements, and inline in the same document, some natural questions about SVG and CSS are receiving more focus. This includes box model questions like background and border, and pointer events.
I’m interested in comments from the community on what direction SVG should take.