Taking a little time at the W3C Face to Face

I took a few days away from slaving over a hot keyboard to travel a little. I attended the W3C Face to Face (F2F) in San Jose the first half of the week. As one of the editors of the W3C Canvas 2D Context spec the F2Fs are something that we periodically get called out to do. This was my first, though I've been an editor since Oct 2012. While the F2F was really interesting, and I learned a lot about how the W3C does business, and also about technologies outside my realm. Unfortunately, pretty much all the other canvas editors had other things to go to, so we didn't have a session on the spec.

The 2D Context spec is in the final stages of going to Candidate Recommendation (CR), and has accessibility issues that are still being worked on. The canvas editors and the accessibility editors are getting together in a task force to talk about hit testing and focus rings. drawSystemFocusRing, which has been renamed  drawFocusAsNeeded. Focus rings is pretty much set.

Hit regions are still under discussion. They're a cool feature that if implemented, lets a developer define controls made of paths on the canvas, and associates them with controls (like buttons) that live in the fallback area between the <canvas> and </canvas> tags.

  Currently if a browser supports canvas, then what's between the tags is ignored, mostly. For example this snippet: 

<canvas id="mycanvas">

   Sorry, this browser or mode does not support canvas.

</canvas>

Obviously, if the browser doesn't support canvas, the fallback code (or text in this case), is displayed. You can also put interactive elements, like buttons in that space, like this:

<canvas id="mycanvas">

   <button id="mybutton">Click me</button>

</canvas>

Visually, if your browser supports canvas you're not going to see the button. If canvas isn't supported, then the button will show. However, there's a third option that only people who use assistive technology might know about. If your browser supports canvas, and it has say a screen reader hooked up, the button is "visible" to the reader.

Hit regions lets you put your button inside the canvas tags, create a button on the canvas (say using fillrect()), and link the two together as a hit region. The idea is that when the control gets focus, it can optionally alert the accessibility equipment. Additionally there's some updates (still discussing it) to mouse events so when you click on an area of the canvas that has a hit region, it sends a mouse message to the associated control that's between the canvas tags.

Now this will go a long way to making canvas accessible. But, if we can get the mouse events in, that's a win for everyone. You'll be able to easily create an interface by using elements in the fallback area, put some splashy graphics on the canvas, and have it work just like a regular UI. That would be cool.

We're still talking about hit regions, but hopefully we'll get the last things nailed down this week and move the spec back to CR. More later.