Re: SVG accessibility - yes, you need to know how it is to be used

At 04:13 PM 2001-09-07 , Loretta Guarino Reid wrote:
>It seems that I need to know something about the way this information will
be 
>presented to know how to author it properly.

AG::

I have left my earlier response below, because there is an "on the one hand --
on the other hand" relationship between the two arguments.

** summary 

Yes you need to know how the stuff in the assistive reinforcements of the SVG
has to be able to be used.

Things like text labels are natural language stuff.  We can't capture adequate
knowledge of their requirements in a constructive model (syntax, letters make
words make sentences make paragraphs, etc.)  To provide adequate specification
of the requirement, we do need to provide "must by usable in the following
way"
information.  The canonical statement of how it must be usable, however, is at
a topological level of abstraction.

** discussion

Let me offer one very painful example where we didn't quite get the
language in
the HTML 4 specification that we needed, and we have yet to fix it.

This has to do with the definition of the TITLE attribute in HTML.  Which
actually goes for SVG, too, although there is a subtle difference induced by
the different climate of "other attributes or property-giving subelement" in
the two languages.

To deliver what we need for automatic extraction of a page [or SVG document]
table of contents, the TITLE attribute should be something which, taken in
isolation, identifies the TITLEd thing, the conceptual object closely related
to the markup language element instance bearing this TITLE.  Because of the
use
of TITLE as a tooltip, designers operating in a GUI frame of interaction,
quite
commonly put supplementary information in the TITLE, and not "from the upper
left" identification of the topic.  

I am repeating myself.  Please see

<http://lists.w3.org/Archives/Public/wai-tech-comments/2001Jul/0001.html>ht
tp://lists.w3.org/Archives/Public/wai-tech-comments/2001Jul/0001.html

for a discussion of this outstanding problem in our accessibility
architecture.

The 'topological abstraction' bit is the phrase "in isolation" where it says
that the TITLE, to meet orientation requirements arising somewhere in the
spectrum of UI pixelcount-equivalent must be usable _in isolation_ to identify
the object.

This is the clause that many actual titles containing supplemental information
fail to meet.  So the Jaws behavior of only reading the TITLE as you tab
through breaks (as effective information mediation) when it hits these TITLEs
and I can't prove the TITLEs wrong by the spec, whether it be HTML 4.0 or
SVG. 
And furthermore, Phill and the myriad voiceless web authors whose
understanding
of the specification he spoke for have a good point: that the optimization
that
the TITLE provides if it is written in supplemental mode is a valid value
added
and so we can't take it away without incurring usability cost for somebody. 
Actually lots of somebodies, including in particular some people with certain
motor or cognitive disabilities affecting functions other than their vision.

So in the ideal world we would have an abstract use that elements in the
accessibility annotation infrastructure must be qualified to be used in.  This
is arrived at through the comparative analysis of too many and too specific
use
scenarios to put all of them in the requirements for the population of
information, although some of them can be preserved in the requirements
documentation for illustration (enhancing comprehensibility) and motivation.

We haven't accumulated enough stuff to have a good statement of those
requirements yet.  XMLGL is our outline of a rough draft. 

Al

--prior message

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 Monday, 10 September 2001 20:02:45 UTC