"Nigel McFarlane" <nrm@kingtide.com.au> wrote in message
news:418BA2B7.7030803@kingtide.com.au...
> Rather than pick nits over <canvas> or other tags, it would
> be better if the "yea" sayers would defend SVG by explaining
> how it *can* support accessibility, UA content extensions, and
> XForms, and how much CSS it has to lean on to do so. How much
> can it do?
How SVG can support accessibility of a stock graph (something that Ian
stated was better done with a canvas element) can be easily demonstrated.
You can use sXBL to convert source data in an appropriate format (I imagine
you'll find something appropriate at
http://www.service-architecture.com/xml/articles/finance_xml.html ) to its
representation. However, even without this ability to re-use known
semantics, the SVG representation can be more accessible, since each element
of the graph can be labelled with a title and description, which is then
available to AT's as a user interacts with the graph. (e.g. Vladimir
Bulatov's bump printer described in
http://www.svgopen.org/2004/papers/SVGOpen2004MakingGraphicsAccessible )
Even without a title/description, information can be better obtained from an
SVG document, than a bitmap (which is all canvas has, it just paints bits
onto a canvas, there's no state).
> Can SVG perform accessibly without leaning on CSS?
They're both rendering languages and completely orthogonal, in SVG the
semantics are in the rendering - and in CSS there are no semantics in the
rendering, there's nothing to lean on each other. CSS is actively harmful
to accessibility in SVG, you can't style a rendering language and maintain
accessibility (If you're not aware of the reasons why, you cansee the
problems the CSS cascade produces described in
http://jibbering.com/2002/8/text-mixup.svg )
Making SVG graphics accessible is not about CSS - CSS isn't about making
anything accessible, it just removes the problem of seperating the rendering
from the semantics.
Jim.