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
which
	are inaccessible except through GUIs running the full SVG runtime
code,
	including ECMAScript.

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

	If these nodes had been written in HTML, there would be some
pressure
	from the medium to produce text that was extractable with simple
tools,
	in a vaguely logical order (although many of the people who will
jump
	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
which
	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
poor
	vision will see the enlarged bitmap more or less the same as someone
with
	good vision will see the smaller version.  (As I pointed out before,
unless
	the lines are deliberately styled over-size, the thicker lines on
the
	pixellated version are actually easier to see with blurred vision.)

	Alternative Equivalents: Past precedent is that almost nobody
provides
	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%
of
	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
true.

	XML Style Sheets:  Only the most sophisticated users with
disabilities are
	going to be able to create custom style sheets; anyone who has only
kiosk 
	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
those
	interested in pushing the technology envelope for people like
themselves.
	Enabling grass roots development of browsers suitable for
non-profitable
	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
complex
	for one man development.

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

	Simple shapes, re-use of components:  I thought these were standard
features
	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
commercial
	home page designers will, unfortunately, switch to it - they want a
	presentational language), but there are precedents for diagramming
languages
	which don't require detailed positioning, e.g. the venerable Unix
PIC.

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

	The other problem with fonts is that you will still get people
miscoding
	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
these.

	Accessible Animation:  the precedent with HTML is that when given
the
	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
the
	consistency of behaviour that results from staying within the
envelope.
	It's pretty clear that no-one is asking on the SVG lists about
intrinsic
	animation.  It could be that this is too obvious to ask about, but 
	experience on other lists is that nothing is that obvious to
everyone.
	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
sender,
	except where the sender specifically states them to be the views of
BTS.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:55:47 UTC