- From: Eric Bohlman <ebohlman@netcom.com>
- Date: Wed, 8 Mar 2000 01:36:37 -0800 (PST)
- To: Jon Ferraiolo <jferraio@adobe.com>
- cc: donpark@docuverse.com, xml-dev@xml.org, www-svg@w3.org, "'Arnold, Curt'" <Curt.Arnold@hyprotech.com>
On Tue, 7 Mar 2000, Jon Ferraiolo wrote: > 1) By having character data only in <desc>, <title> and <text>, then really > dumb screen readers for the visually impaired which only vocalized > character data would tend to provide a more suitable aural rendering of an > SVG document, versus one attempted to vocalize all of the moveto, lineto, > curveto and coordinate data in a 'path' element This is a non-issue. The *overwhelming* majority of blind Web users use mainstream browsers (Lynx is a mainstream browser), not "really dumb" tools. BTW, a "screen reader" is a program that takes data from the *user interface presentation* and routes it to speech or Braille output; it's completely unaware of the internal representation that an application program uses to create its display. Misguided attempts at accessibility are patronizing as well as wasteful. Accessibility of SVG documents to blind users will come either from accessible interfaces provided by "mainstream" SVG display tools (in which case the internal representation is completely irrelevant) or from specialized SVG-interpreting tools (which can be assumed to fully parse the SVG and probably build a DOM out of it; there's no reason to make SVG hack-parse friendly on their account). Is this requirement really "an SVG document should display its textual content if loaded into a browser that supports only HTML"?
Received on Wednesday, 8 March 2000 04:36:49 UTC