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

At 04:13 PM 2001-09-07 , Loretta Guarino Reid wrote:
>Let me present a hypothetical example, to see if that makes my question 
>clearer.
>
>Suppose I use SVG for a bar chart. The bar chart will contain some text 
>labeling values on the axes, at least. But the text alone will by no means 
>communicate the information in the bar chart.
>
>Would I attach a description to the entire bar chart? to the individual bars 
>in the chart? if I describe the bars in the chart, should the top-level 
>description duplicate the information about the values of the individual
bars?

>or just indicate that this is a bar chart plotting X against Y?
>
>It seems that I need to know something about the way this information will
be 
>presented to know how to author it properly.
>

AG::

It would seem you need to know how it will be processed, but that is not given
to you.  You can know a spread -- from voice browsing to being tiled onto a
PowerWall with fifty or a hundred other desktop screenfuls.  That's not that
much help.

You do know how it _has been_ processed.  So just tell them what you know.

(Note: that is going to become a mantra for what the schema or documentation
requirement is.  Everyone has the question you asked; but the answer is, you
don't know all the situations in which it has to be used, just tell them what
you [do] know.)

The application is not SVG, it is a spreadsheet.  The spreadsheet is using its
SVG device driver to draw the chart.  But the logic behind the chart is
spreadsheet logic, not SVG logic.  The SVG can have structured, typed XML in
its 'desc' element instances sufficient to hold the binding to the referenced
schema.  This will include encoded properties and relationships encoded in
X-Links with defined 'role' values or in the META section.

The XMLGL answer is to publish the schema for the spreadsheet, and link from
the items appearing in the SVG to the schema through RDDL or some equivalent
machine-followable means.  Then you can put dumb labels and if the user wants
to understand the relationships to generate alternate views, they access the
schema to learn the sense of the inter-fact relationships.

You could put a data description -- sort of a one-off schema -- in RDF
embedded
in the META element, but it is more likely that there is one schema that goes
with many charts and it makes sense to publish it once and reference it.

This level of backup is the absolute best for an all-out custom AT.

For production AT there probably are some modes that represent common modes of
operation for a give class of assitive function.  One might find it effective
to target pre-planned readout macros to these.  But we don't have that in hand
and we would have to generate more participation from the AT community to
develop answers worth your believing.

The answer to preparing stuff so that it can be presented in diverse ways
is to
do a good job of articulating what it _is_ and let those who handle it later
work from that.

We should work through some example charts.  The logical places to hang
descriptions are obvious from the structure of the quantitative story being
told, (but only to a math teacher).
You simply have to not have great gaps in scale between the stopping points
(where you document) in the incremental unfolding of the story.  No seven
league boots.  Then the user can sample or the AT can surface the orientation
resources as they need with the actual chunking that results from the
realities
of their specific delivery context.

This will start to be credible once we work some examples.

Speech is audio is narrow-band.  If you just make the same facts accessible,
you have not reached equivalent facilitation.  The person using speech as
their
primary mode of user interface needs to have the option to apply more
intelligence in a thick client further boiling down the information that you
applied in generating the chart.  For that to work, they need the full model
behind the facts.  Only then do we start talking about a level playing field. 
User-directed summarization is what we have to support to get equal usability
for professional work.  That is an interactively specified view.  No way for
you to know what it will be.

Loretta, I presume you have 'member' access and can look for example on the PF
list archives under "Coordinating Aural CSS" for more on this.  But we need to
develop this story in the open to the point that GL owns it.  See if you can
get a suitable "content model"-building work item chartered out of GL.  Or at
least a motion out of GL that it should be done, somehow.

The posterkid for this discussion is the transit schedule.  A tabulation of
the
schedule, a timetable, is a visual conceit.  It is a view optimized for visual
conditions.  An accessible timetable is a half a loaf.  You don't serve a
tabulation of the schedule by phoneBot.  You serve a trip planner, an
interactive dialog that lets you figure out what your options are for the trip
you want to take.  The optimization considerations for speech out of a screen
reader are not that different from those for the phoneBot version.  Better
each
audio-scale chunk of presentation should be a menu, a step in the incremental
problem-solving process, than just another chunk of table.

Like Wordsworth's "trailing wisps of glory" or whatever it was he said we came
from heaven, the SVG has to be infiltrated with hooks back into the world
model
prior to the visualization.  Because that is what you want to interpret,
really, as compared with the visual-optimized presentation.

Al

> Loretta
>

Received on Friday, 7 September 2001 18:01:42 UTC