W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 1999

Re: How to describe Flowcharts, Schematics, etc

From: Steven McCaffrey <smccaffr@MAIL.NYSED.GOV>
Date: Tue, 17 Aug 1999 07:17:39 -0400
Message-Id: <s7b90cba.065@MAIL.NYSED.GOV>
To: karl.hebenstreit@gsa.gov, w3c-wai-ig@w3.org
Cc: Raman@adobe.com

Hello Karl, Charles, Len etal:

Let's take the March 1999 Quality Magazine review as an example of what I see as some software tools having some possibly marginally useful features, but, in my view, the emphasis, in terms of making charts and diagrams accessible to the blind, still misses the fundamental point.  
As an overall starting point, let me re-emphasize that the discussion is technically not how to make the graph or chart accessible, but how to make the *information* conveyed by such visual presentations accessible.  A flowchart is a presentation mechanism, not the underlying information itself.
"            AllClear version 4.5 makes it much easier to create charts from 
            text. It also features an easy-to-use tool for converting charts to  Web graphics formats."

Are the resulting web graphics understandable by screen readers?  My guess is no.  In my opinion, is not sufficient to mearly replace a two-dimensional arrangement of symbols with a linearly spoken sequence of symbols, be they semicolons and other special symbols(apparently in earlier versions of AllClear) or even some higher level syntax such as control flow words like "while" or "If...Then...".
Note that the main advantage of AllClear 4.5 seems to be the ability to type in text to draw the chart.  Humm, if the text has the same information, what is gained by drawing the chart at all?
The fundamental question I asked early in this thread is the one completely ignored by this, and probably other, charting programs as well.  The first question to ask when deciding how to make graphs and charts accessible to the blind is 
"What information am I trying to convey with this chart/diagram?"  These chart drawing programs, text entry or drag and drop interface, seem to have the drawing of the chart the end, and not the means.  In other words these programs assume the user is asking the question
"What would this process look like as a chart or diagram?"  A good question for a sighted person, but as a blind person, my question would be "Why do I want to know that?"  
Since something must be in the resulting chart that is not in the text description that gets mapped to the chart, I still think asking what that something is should be the critical question.
In a slightly different context, Dr. T.V. Raman has written clearly and concisely on the nature of the information access differences between vision and hearing.  In his article "AsTeR: AUDIO SYSTEM FOR TECHNICAL READINGS", 
appearing in  the November 1994 issue of Information Technology and Disabilities
(http://www.rit.edu/~easi/itd/itdv01n4/article2.html he writes:

"Visual communication is characterized by
the eye's ability to actively access parts of a two-dimensional 
display.  The reader is active, while the display is passive. 
This active-passive role is reversed by the temporal nature of
oral communication:  information flows actively past a passive
listener.  This prohibits multiple views - it is impossible to
first obtain a high-level view and then "look" at  details. 
These shortcomings become severe when presenting complex
mathematics orally."

Precisely.  I wish I could write with such clarity and precision.
It is my view that the same can be said when describing charts and graphs.
I think programs such as AllClear ignores the excellent point len made about separating structure from content (also a major theme of Dr. Raman's writing/work)so in short it is NotAtAllClear that such tools are the right way to go for making visually presented information accessible to the blind.
Personally, I would prefer we move in the direction Len suggested earlier:
">Yet another way, which goes even further in separating content from
>structure, would be to represent the abstract information (e.g.
>organization chart) as XML and use a  style sheet to translate that to
>graphics.  Then the RDF, and the logic programming, could apply directly to
>the abstract information.
>These would all make the diagrams more useful to everyone (and to machines)
>since they wouldn't just be pictures anymore: they would be information."


Steven McCaffrey
Information Technology Services

>>> <karl.hebenstreit@gsa.gov> 08/16 10:36 AM >>>

Has anyone worked with ALLClear?   This is a flowcharting tool I evaluated
some years ago that has a syntax for describing flowcharts. Semi-colons,
commas, and other punctuation marks denoted different flowchart symbols. If
this or some other scheme was adopted as a standard, then a
visuall-impaired person could generate flowcharts, as well as interpret
flowchart information!  Thanks, Len for providing the link to the latest
version of the software:

Karl Hebenstreit, Jr.
US General Services Administration
Center for Information Technology Accommodation

---------------------- Forwarded by Karl F. Hebenstreit Jr./MKC/CO/GSA/GOV
on 08/16/99 10:27 AM ---------------------------

From: <w3c-wai-ig@w3.org> AT internet on 08/11/99 10:51 AM

To:   w3c-wai-ig@w3.org AT INTERNET@ccMTA-GEMS-MTA-01 
cc:    (bcc: Karl F. Hebenstreit Jr./MKC/CO/GSA/GOV)

Subject:  How to describe Flowcharts, Schematics, etc

Most image on the web are decoration or icons with simple meanings like
"next page".  so ALT text and long descriptions are relatively

But some images convey information.  For example,

A simple linear sequence, like a flow chart with input going through a
series of processing stages to result in an output.

A tree diagram, like a  company's organization chart.

A more general diagram showing a bunch of interconnected objects, e.g. a
schematic diagram or an electronic circuit.

The most complex is a 3D machine, in motion if you want to make it even

Are there any guidelines on how to describe these diagrams?

For example, you could use lists and nested lists for linear sequences and
trees respectively.  Or you could use prose.  More general diagrams are,
well, a more general problem.   What techniques are best for what purposes
and audiences?  What's good wording, especially for prose decriptions?

I'm mainly thinking of speech output here, since that's what most blind
surfers will be using, rather than Braille or tactile graphics.

This is no doubt hard to encapsulate... at some point you just have to get
a skilled technical writer, especially for the prose versions...

Leonard R. Kasday, Ph.D.
Universal Design Engineer, Institute on Disabilities/UAP, and
Adjunct Professor, Electrical Engineering
Temple University

Ritter Hall Annex, Room 423, Philadelphia, PA 19122
(215) 204-2247 (voice)
(800) 750-7428 (TTY)
Received on Tuesday, 17 August 1999 07:21:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:05 UTC