W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > July to September 2000

Re: Call for Review: Accessibility Features of SVG (Scalable Ve ctor Graphics)

From: Dave J Woolley <DJW@bts.co.uk>
Date: Thu, 31 Aug 2000 11:17:26 +0100
Message-ID: <81E4A2BC03CED111845100104B62AFB582498C@stagecoach.bts.co.uk>
To: "'w3c-wai-eo@w3.org'" <w3c-wai-eo@w3.org>
	The fundamental flaw in the document is that it assumes that the
main use
	of SVG will be technical diagram production by people with a
commitment to
	accessibility.  In my view, the reality is that it will be used as
	an alternative to Shockwave Flash and HTML by people with no
interest in,
	or budget for, accessibility.  The result will be nodes in the web
	are inaccessible except through GUIs running the full SVG runtime
	including ECMAScript.

	Even the text in the result is likely to have an almost random
	order, as I believe that people will paste up the images using GUI
	in an order that bears little resemblance to the logical reading

	If these nodes had been written in HTML, there would be some
	from the medium to produce text that was extractable with simple
	in a vaguely logical order (although many of the people who will
	on SVG have been using bitmapped text.

	I think the net effect of SVG, if commercially successful, will be
	a drastic reduction in the accessibility of the majority of pages
	are now borderline.  On the other hand, in a free market, there is
	probably little that can be done to prevent this.

	Specific Points:

	Fig 1.1: The loss of quality is subjective, not real; someone with
	vision will see the enlarged bitmap more or less the same as someone
	good vision will see the smaller version.  (As I pointed out before,
	the lines are deliberately styled over-size, the thicker lines on
	pixellated version are actually easier to see with blurred vision.)

	Alternative Equivalents: Past precedent is that almost nobody
	alt text for images in HTML; even less are going to provide the more
	extensive alternative text described here.

	XML Plain Text:  The plain text reading order for, at a guess, 99%
	real SVG is likely to be a total mess.  It requires a real
commitment to
	accessibility, which I think is very rare, for anything else to be

	XML Style Sheets:  Only the most sophisticated users with
disabilities are
	going to be able to create custom style sheets; anyone who has only
	type access is not going to be able to do it at all.

	DOM:  Document Object Model automation tends to require commercial
browsers -
	Mozilla is about the only exception.  Commercial browsers are
designed for
	those who have money to spend and Mozilla is largely developed by
	interested in pushing the technology envelope for people like
	Enabling grass roots development of browsers suitable for
	markets requires simplicity in the input, so that they form
realistic one
	man spare time developments.  I think the whole of SVG may be too
	for one man development.

	Example 2.2:  There is an unmatched </g>.

	Simple shapes, re-use of components:  I thought these were standard
	of object type drawing packages.

	Section 4 - Positioning is Fundamental:  I don't agree.  In fact,
I'd argue
	that SVG is a lot more presentational than HTML (which is why
	home page designers will, unfortunately, switch to it - they want a
	presentational language), but there are precedents for diagramming
	which don't require detailed positioning, e.g. the venerable Unix

	Fonts:  The great problem with embeddable fonts is intellectual
	The current Microsoft solution involves locking the font to the web
	(which is a problem for non-web documents and intranet products).
	makes it non-trivial to recover the font, thus avoiding casual
	violations.  SVG's own font mechanism seems to provide at least the
	sub-set of the font in a very easily extractable and reverse

	The other problem with fonts is that you will still get people
	fonts (e.g. Symbol "m" for Greek mu).

	On an initial reading, one more or less has to use SVG native fonts
	for Indic scripts, but even Unicode TrueType fonts are rare for

	Accessible Animation:  the precedent with HTML is that when given
	opportunity of using scripting, designers are not content with using

	built in mechanisms.  The problem is that designers want to get the
	competitive edge by out animating the competition; they don't want
	consistency of behaviour that results from staying within the
	It's pretty clear that no-one is asking on the SVG lists about
	animation.  It could be that this is too obvious to ask about, but 
	experience on other lists is that nothing is that obvious to
	I think people are going to go straight to Javascript and not even 
	investigate the intrinsic alternative.


	--------------------------- DISCLAIMER
	Any views expressed in this message are those of the individual
	except where the sender specifically states them to be the views of

Received on Thursday, 31 August 2000 06:17:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:29:30 UTC