Re: Call for Review: Accessibility Features of SVG (Scalable Vec tor Graphics)

	This is a repeat, but hopefully formatted so
	that Outlook/Exchange don't massacre it.....

	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. 

	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

	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 08:20:20 UTC