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

At 06:59 AM 2001-09-09 , Loretta Guarino Reid wrote:
>Is this a fair summary? 
>

AG::

** summary

Almost.

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
uses
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
graphic
in 

The role of User Environments in The Grid
<http://trace.wisc.edu/docs/ud4grid/#_Toc495220373>http://trace.wisc.edu/do
cs/ud4grid/#_Toc495220373

Then you need to know what you are doing.  Here graph navigation, following
the
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
version.

* support for interactive data browsing

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

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,
relationships
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)
that
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
combination
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
the
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
that
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.

LG-R::

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

AG::

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
modal,
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
XML
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.

Al


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 UTC