Archive for the 'SVG' Category

Meet NEWT: New Exciting Web Technologies

As professionals, we need to keep our jargon accurate. That’s why I hate hearing “HTML5″ used as an umbrella term for any web technology, especially when people confuse HTML5 (mark-up and APIs) with CSS 3 (eye-candy). Repeat after me: HTML5 != CSS 3.

So we need a buzzword, as “HTML5 and related technologies” is unwieldy (and inaccurate). I prefer “NEWT” which stands for New Exciting Web Technologies and can thus safely encompass real-HTML5, CSS 3, SVG, XHR2, Geolocation, Web Sockets, WOFF, Web DB, IndexedDB, WebGL and the like.

Because new acronyms need a logo, the talented and generous Rob Winters made a cute newt.

various sizes of cute newt on Flickr

(Other sizes, Transparent-background version.)

Please, use the logo and term in your presentations, and wave goodbye to misery of I.B.E. (Inaccurate Buzzword Embarrassment)!

(Be nice if you attributed Rob, and even me, but no compulsion.)

Microsoft joins the SVG Working Group

From the IE Blog:

As a part of Microsoft’s continued commitment to interoperability and standards support, yesterday we submitted our request to join the Scalable Vector Graphics (SVG) Working Group of the World Wide Web Consortium (W3C). We’re excited to take part in ensuring future versions of the SVG spec will meet the needs of developers and end users.

Our chums in Redmond sponsored the SVG Open conference earlier in the year too.

All this snow? It’s hell freezing over.

Canvas, accessibility and SVG

Since watching Steve Faulkners’s standards.next presentation about HTML 5 accessibility, I’ve become more interested in the accessibility of the canvas element. canvas is a method of producing dynamic graphics with JavaScript:

The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.

As a nice illustration, here’s an example of Super Mario in 14K of JavaScript.

No matter how sexy they are, however, they’re just graphics, with the accessibility complexities that can entail. In the specification, there is a very basic way of providing "fallback content":

When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element’s fallback content.

This is as basic as

<canvas>
You're too damn blind to use this bit
</canvas>

Now, this is all well and good if you’re just drawing a simple image whose contents you know and can describe in advance, or using jQuery to dynamically draw graphs of data from a data table, but what happens if you’re using it as a text editor like Bespin, or even making UI controls like tools.mozilla.com? Note the latter has a simple link at the bottom "plain HTML version". In 2009, parallel "screenreader pages" are unnacceptable.

(I’m not really blaming the developers of these pages; the lack of accessiblity fallback is inherent in the specification, although the second example could be done with SVG, an image map, or with good old fashioned HTML, CSS transforms/ transitions and JavaScript).

Indeed, the spec does warn against misusing the canvas element:

Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies.

I’m pleased to see that the HTML 5 cabal are discussing this and the HTML 5 editor, Ian Hickson, is seeking advice from the W3C‘s Web Accessibility Initiative. The Mighty Steve Faulkner has been giving it some deep thought. Here’s a very thorough investigation of accessibility issues problems in canvas.

canvas or SVG?

There is another, longer-established standard for drawing graphics on the screen, Scalable Vector Graphics (SVG). This is supported on the same browsers that support canvas (that is, all except Internet Explorer) but is a much more mature technology. As it’s an XML-based language, it is text-based and thus is inherently accessible. Screenreaders don’t support it yet, probably because the big screenreaders have traditionally sat on top of Internet Explorer, and also because they are the Netscape 4 of assistive technologies—last I heard screenreaders don’t support strong or em.

I expect in the coming months we’ll see lots of unnecessary uses of canvas over SVG, in the erroneous belief that “Canvas is cooler than SVG" and it’ll be like Flash was in 1999. Ah well. At least we can hope that the Working Group can make this new "skip intro" accessible.

Update Monday 20 July:

The [W3C‘s] Protocols and formats working group discussed the issues of canvas accessibility in their HTML caucus meeting last friday (17/07/09). It has been decided to form a task force to work on specifying additions to the CANVAS API, that will result in canvas content being natively accessible.

http://lists.w3.org/Archives/Public/public-html/2009Jul/0562.html