- From: Dave J Woolley <DJW@bts.co.uk>
- Date: Thu, 31 Aug 2000 11:17:26 +0100
- 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