W3C home > Mailing lists > Public > wai-xtech@w3.org > September 2001

Re: SVG accessibility - title, description and what to do with it

From: Al Gilman <asgilman@iamdigex.net>
Date: Sun, 09 Sep 2001 09:39:13 -0400
Message-Id: <Version.32.20010909081037.041223c0@pop.iamdigex.net>
To: Loretta Guarino Reid <lguarino@adobe.com>, Charles McCathieNevile <charles@w3.org>
Cc: Loretta Guarino Reid <lguarino@adobe.com>, Ivan Herman <ivan@w3.org>, Marja-Riitta Koivunen <marja@w3.org>, WAI Cross-group list <wai-xtech@w3.org>, lguarino@adobe.com
At 06:59 AM 2001-09-09 , Loretta Guarino Reid wrote:
>Is this a fair summary? 


** summary


Don't write off a dump option.  There is always a usable dump into the
world of
DAISY books.

And there is more summary possible about what the authoring tool needs to
provide in terms of meta-stuff in the SVG to support full viewing flexibility
and intelligence when the mode is more interactive.

** details

* dump format

If you dump to hypertext, then the result is interactive.  There is no
non-interactive option on the table.  [yes, richer interaction is better for
some people.]

An exhaustive dump to hypertext is always possible and if the DAISY talking
book design is taken as the master pattern that one is dumping to, and one
that pattern semi-well, then  the result need not be confusing.  Of course if
the main plot of the graphical presentation is a cycle, as in the first

The role of User Environments in The Grid

Then you need to know what you are doing.  Here graph navigation, following
principal relationships in the plot-graph for the story depicted in the
graphic, encoded as hyperlinks in the hypertext, makes the story clearer than
just a tree or linear narrative alone.

This is a document design you can trust because it closely follows what is
known from field experience to work, and the differences were developed by
experts close to the consumers in the field.

Note that as I said this requires at least two planes of static hypertext, a
table of navigation which provides global orientation and the full-text

* support for interactive data browsing

A yet more interactive data browse is better for some people, as you note. 
nominal first path here is with a DOM and assistive technology leading the
formation dialog, the interactive decisions about what shows in interactive

Think of what you get with a DOM as data+knowledge.  The stuff on hand (in
program data space) in the application that writes the SVG consists of data
values and knowledge about those data values.  Range constraints,
and the like.

The chart contains a subset of the data.  It should logically contain, (which
permits machine followable links to) full knowledge about the data included. 
Every constraint (including relationships as formally constraint patterns)
pertained to the retained data as present in the data space of the active
application should be available to the view formulation process in a thick
client which may be dominated by AT algorithms.  Knowledge that genuinely does
not touch the data retained in the chart view is not required, but may be
efficiently included through the by-reference mechanism.

BUT, I have to repeat a warning.  There ain't a'gonna be any rule based on
selectors against the visual role alone such as "text on the bars" that
will be
valid as to when you show what.  "text on the bars" is used for too many
different underlying roles of label information.

I believe this is what Ivan is trying to say, too.

It's like italics and Braille.  In print, a variety of rhetorical roles lead
text to be italicized.  In Braille, some of these deserve italics, and some of
them don't.  So for repurposing to literate Braille (and Braille is so effects
poor that you had better generate literate stuff or it is truly painful to
read) one has to get behind the visual effect of italics to discover the
precise rhetorical role that was the reason for the italics before you can
truly know whether to italicize the text in the Braille edition.

The author encodes the structure of their quantitative story by the
of the graphics and the sense of the labels.  You can tell from the fact
that a
text label is a compatible numeric quantity and its orientation along an
invisible coordinate grid line that it is a sample value that is further
described by the scale laid out along the margin.  There is some type-matching
that goes into the cognitive processing that connects this text fragment in
layout with the scale fragment in the layout.  That cognitive alignment is in
the 3D virtual world evoked by the 3D bar chart, by the way, not in the 2D
the SVG draws.  This kind of "Oh, that is_a [stock price]" inference that the
visual user infers from alignment in the virtual world is some of what Ivan is
talking about one has to spell out or the extraction to a tree of topics in a
linear narrative will not be constructable by rote algorithm.


>And, of course, this all gets more complicated if the bar chart is just
>one object in a larger SVG file.


It gets simpler if you take a generic object view.  But of course XML doesn't
let you, so there is a whole hassle about how the meta-information for a
multilevel world such as a poster layout with embedded 3D scenes in it is
captured and shared in an XML file.  But this is a generic XML document
problem, not unique to graphics.  This part is complicated, not hard.

If you approach the design of a schemas and namespaces use plan to get the
information into XML with a clear idea in mind of the kind of world you are
constructing, where each object class carries its own content-ontology which
can be different from the ontology governing the space the object is embedded
in, then it is a small matter of programming.

A review of the logical flow through the X3D work is instructive.

What I am saying is that if you understand what good capability is, here, and
approach the dialect design with that as your objective, I believe you can do
it in XML, yea in something very like SVG 1.0 or SVG 1.0 + namespaces.  But
doesn't help you.  You have to know what you are after.

And the Ap that writes the SVG has to put the necessary knowledge backups _in_
or the assistive view extraction cannot get what it needs to get a literate
reading _out_ of the SVG data.


At 06:59 AM 2001-09-09 , Loretta Guarino Reid wrote:
>Part of what I wrestle with, in the bar graph example, is what to do
>with the text that is part of the rendered visual representation. Should
>that be included in the linearization? Unfortuneately, I think I get
>different answers if the text is the labels on the bars (Australia,
>New Zealand, etc.) or if the text is the caption for the table. I suspect
>we don't want the former, by default, but we do want the latter.
>And, of course, this all gets more complicated if the bar chart is just
>one object in a larger SVG file.
>The impression I'm getting, from this discussion, is that a user agent needs
>to provide interactive navigation for such structures, that an author
>should be prepared to have the user presented with only the top level
>description, as well as having the user navigate the structure
>dynamically, and that a full non-interactive linearization is likely to
>be confusing.
>Is this a fair summary? 
> Loretta
Received on Sunday, 9 September 2001 09:16:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:36 GMT